Network Working Group S. Niccolini Internet-Draft NEC Intended status: Informational B. Claise Expires: February 18, 2011 Cisco Systems Inc. B. Trammell ETH Zurich H. Kaplan Acme Packet August 17, 2010 A Common Log Format for SIP using IPFIX Files draft-niccolini-sipclf-ipfix-04 Abstract This draft defines a log file format conforming to the information model defined in the SIP-CLF problem statement based upon the IPFIX File Format. It details the creation and interpretation of these files, and provides examples based on common SIP situations. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on February 18, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect Niccolini, et al. Expires February 18, 2011 [Page 1] Internet-Draft SIPCLF - IPFIX August 2010 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Introduction to IPFIX . . . . . . . . . . . . . . . . . . 3 1.2. Encoding and Limits . . . . . . . . . . . . . . . . . . . 4 2. Information Elements for SIPCLF . . . . . . . . . . . . . . . 4 3. Recommended Templates for SIPCLF . . . . . . . . . . . . . . . 9 4. IPFIX File Format for SIPCLF . . . . . . . . . . . . . . . . . 11 4.1. Logging Large SIP Bodies . . . . . . . . . . . . . . . . . 11 4.2. Supporting fast searches of SIPCLF log files . . . . . . . 13 5. Efficiency Analysis . . . . . . . . . . . . . . . . . . . . . 13 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. Base Template Export . . . . . . . . . . . . . . . . . . . 13 6.2. UAC registration . . . . . . . . . . . . . . . . . . . . . 14 6.3. Direct Call . . . . . . . . . . . . . . . . . . . . . . . 16 6.4. Single Downstream Branch Call . . . . . . . . . . . . . . 16 6.5. Forked Call . . . . . . . . . . . . . . . . . . . . . . . 17 6.6. Torture Tests . . . . . . . . . . . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19 10.2. Informative References . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Niccolini, et al. Expires February 18, 2011 [Page 2] Internet-Draft SIPCLF - IPFIX August 2010 1. Introduction The SIPCLF WG is chartered to produce a format suitable for logging at any SIP element. The charter explicitly addresses the need to search, merge and summarize log records from one or more possibly diverse elements as well as the need to correlate messages from multiple elements. An additional consideration to be taken into account when defining the file format is the extensibility of SIP. SIPCLF is additionally chartered to identify the fields to appear in a log record and provide one or more formats for encoding those fields. As the IPFIX File format [RFC5655] meets these requirements, SIPCLF is presently considering an IPFIX File-based binary logging format, in addition to an ASCII text-based format. This document describes the IPFIX format. Specifically, this document defines new Information Elements for the SIPCLF IPFIX file format (based on the data model detailed in [I-D.ietf-sipclf-problem-statement]), proposes common IPFIX Templates for this data model, uses these templates to define a format, and presents examples of an IPFIX File logging format for SIPCLF. For this purpose examples were taken from [I-D.ietf-sipclf-problem-statement], and torture tests to demonstrate the applicability of the format to uncommon situations from [RFC4475]. 1.1. Introduction to IPFIX IPFIX (IP Flow Export Protocol) [RFC5101] is an IETF Proposed Standard protocol for the export of network traffic information. In addition to a transport-agnostic unidirectional export protocol, it defines a simple encapsulation into files [RFC5655] which expands its applicability into logging and file storage. Originally designed for flows, its flexible and extensible data model lends itself readily to any situation involving events occurring on a network. The central unit of or storage in IPFIX is the Message. An IPFIX Message is composed of a header and one or more Sets. The header contains metadata about the message such as its length and when it was exported; see section 3.1 of [RFC5101] for details. Each Set is prefixed by a header containing an ID, which identifies the type of the set's contents; and the length of the set; this is detailed in section 3.3 of [RFC5101]. The ID of the set refers to a Template describing each Record within the Set. A Template is an ordered list of Information Elements drawn from a registry covering many fields relevant to network traffic export. New Information Elements may be added to the IANA registry to cover new applications, and may also be defined on the fly as Niccolini, et al. Expires February 18, 2011 [Page 3] Internet-Draft SIPCLF - IPFIX August 2010 enterprise-specific Information Elements, scoped to private registries within an SMI Private Enterprise Number. Templates are exported inline, alongside data, within IPFIX Sets identified by special Set IDs. In this way, an IPFIX Message stream is self-describing with minimal overhead in situations where the number of records is much greater than the number of record types. This is a feature of the SIPCLF data model, and indicates the applicability of IPFIX to SIPCLF logging. 1.2. Encoding and Limits Each Information Element specifies a data type, covering most primitives (e.g. signed and unsigned integers, floats, booleans, strings) as well as some network-specific types (addresses, timestamps). All types other than strings and octet arrays are stored in network byte order. Within a Template, an Information Element may be specified to have a fixed length or a variable length; if the latter, the field in the Record has a length prefix of one or three bytes. One-byte prefixes represent lengths from 0 to 254; three byte prefixes are encoded as 255 followed by an unsigned16 in network byte order and can represent lengths from 0 to 65535. Typically, strings are stored with variable length, so IPFIX string fields can be thought of as length-prefixed (or "Pascal") strings. Two advantages of this encoding are that each variable-length field in IPFIX can be skipped with one or two comparisons (depending on the length representation), and that the framing itself is immune to misformatted strings (e.g., with embedded NULs). Although IPFIX variable length Information Elements can represent single values up to 65535 bytes long, there is an additional length limit imposed by the Message format itself. Each Message has an unsigned 16-bit length in its header; this length includes the length of the header itself as well as any set headers, to facilitate easy framing and deframing of messages. Since the header is 16 bytes, and the set header 4 bytes, the minimum per-message overhead (a message with one set containing only one record) is 20 bytes, leading to a record limit of 65515 bytes. A record containing a single variable- length element with 3-byte length encoding therefore has a content limit of 65512 bytes. The implications this has for SIPCLF are discussed in Section 4.1. 2. Information Elements for SIPCLF This section formally defines information elements for SIPCLF based on the data model proposed in [I-D.ietf-sipclf-problem-statement]. Niccolini, et al. Expires February 18, 2011 [Page 4] Internet-Draft SIPCLF - IPFIX August 2010 The IANA IPFIX Information Elements registry available at http://www.iana.org/assignments/ipfix/ipfix.xhtml defines a number of Information Elements useful to SIPCLF. These concern traditional flow key and timing information, and appear in the table below: +--------------------------+--------+-------------------------------+ | Name | Number | /Description | +--------------------------+--------+-------------------------------+ | observationTimeSeconds | 322 | Timestamp | | | | of the request or response | | | | represented as the number of | | | | seconds since the Unix epoch. | | | | Used when second-level | | | | precision is adequate. | | observationTimeMilli- | 323 | | | seconds | | Timestamp of the request or | | | | response represented as the | | | | number of milliseconds since | | | | the Unix epoch. Used when | | | | millisecond-level precision | | | | is required. | | sourceIPv4Address | 8 | The IPv4 | | | | address of the source of the | | | | SIP message | | sourceIPv6Address | 27 | The IPv6 | | | | address of the source of the | | | | SIP message | | sourceTransportPort | 7 | The source port | | | | number of source of the SIP | | | | message | | destinationIPv4Address | 12 | The IPv4 | | | | address of the destination of | | | | the SIP message | | destinationIPv6Address | 28 | The IPv6 | | | | address of the destination of | | | | the SIP message | | destinationTransportPort | 11 | The destination | | | | port number for the SIP | | | | message | | protocolIdentifier | 4 | The type of | | | | transport for the SIP message | | | | (UDP vs. TCP vs. SCTP) | +--------------------------+--------+-------------------------------+ In addition, we define the following Information Elements to represent the SIP-specific mandatory fields defined in [I-D.ietf-sipclf-problem-statement], many themselves taken from [RFC3261]. As these are not yet registered with IANA, but required Niccolini, et al. Expires February 18, 2011 [Page 5] Internet-Draft SIPCLF - IPFIX August 2010 to support experimental implementation during the development of this representation, these are provisionally located within the number space assigned to Private Enterprise Number (PEN), here registered within the private enterprise number 35566, which belongs to one of the authors of this draft. It is intended that these Information Elements be registered within the IANA number space, should this draft become a Proposed Standard. +----------------------+------------+-------------------------------+ | Name | PEN/Number | /Description | +----------------------+------------+-------------------------------+ | sipObservationType | 35566/419 | The observation | | | | type of this log entry. | | | | Denotes whether the entry was | | | | corresponds to a SIP message | | | | received, sent, or merely | | | | seen by a passive observer, | | | | as per the sipObservationType | | | | subregistry defined below. | | sipMethod | 35566/402 | The SIP method | | | | from the CSeq header, as per | | | | the sipMethod subregistry | | | | defined below. | | sipFromURI | 35566/404 | The From URI | | sipFromTag | 35566/405 | The From header | | | | field tag parameter value | | sipToURI | 35566/406 | The To URI. | | sipToTag | 35566/407 | The To header field | | | | tag parameter value, if | | | | present | | sipCallId | 35566/408 | The Call-ID header | | | | field value | | sipSequenceNumber | 35566/409 | The sequence | | | | number from the CSeq header. | | sipRequestURI | 35566/403 | The Request URI, | | | | including any parameters. | | sipResponseStatus | 35566/412 | The SIP response | | | | code returned upstream. The | | | | presence of this Information | | | | Element marks a record as | | | | describing a SIP response. | | sipServerTransaction | 35566/413 | The transaction | | | | identifier associated with | | | | the server transaction | | sipClientTransaction | 35566/414 | The transaction | | | | identifier associated with | | | | the server transaction | +----------------------+------------+-------------------------------+ Niccolini, et al. Expires February 18, 2011 [Page 6] Internet-Draft SIPCLF - IPFIX August 2010 The sipObservationType IE encodes whether the device logging the entry was the sender or received of the message. It can take the following four values: +--------+----------+-----------------------------------------------+ | Number | Name | Description | +--------+----------+-----------------------------------------------+ | 0 | unknown | The logging process does not specify the | | | | observation type. | | 1 | receiver | This entry was logged by the receiver of the | | | | message. | | 2 | sender | This entry was logged by the sender of the | | | | message. | | 3 | passive | This entry was logged by a passive observer | | | | of the message, e.g. a passive metering | | | | process parsing the SIP message from a | | | | sniffed packet stream. | +--------+----------+-----------------------------------------------+ The sipMethod IE encodes the supported methods from [RFC3261] as integers, by the order in which they appear in the IANA SIP Parameters Methods registry at http://www.iana.org/assignments/sip-parameters: +--------+-----------+----------------------------------------------+ | Number | Method | Notes | +--------+-----------+----------------------------------------------+ | 0 | Unknown | The logging process did not recognize the | | | | SIP method. | | 1 | ACK | defined in RFC3261 | | 2 | BYE | defined in RFC3261 | | 3 | CANCEL | defined in RFC3261 | | 4 | INFO | defined in RFC2976 | | 5 | INVITE | defined in RFC3261 | | 6 | MESSAGE | defined in RFC3428 | | 7 | NOTIFY | defined in RFC3265 | | 8 | OPTIONS | defined in RFC3261 | | 9 | PRACK | defined in RFC3262 | | 10 | PUBLISH | defined in RFC3903 | | 11 | REFER | defined in RFC3515 | | 12 | REGISTER | defined in RFC3261 | | 13 | SUBSCRIBE | defined in RFC3265 | | 14 | UPDATE | defined in RFC3311 | +--------+-----------+----------------------------------------------+ The following Information Elements are defined to represent additional SIP fields which have been identified as potentially useful by the SIPCLF working group. Niccolini, et al. Expires February 18, 2011 [Page 7] Internet-Draft SIPCLF - IPFIX August 2010 +---------------------+-----------+---------------------------------+ | Name | PEN/Numbe | /Description | | | r | | +---------------------+-----------+---------------------------------+ | sipAuthUsername | 35566/401 | The SIP user name by | | | | which the user has been | | | | authenticated | | sipContactURI | 35566/410 | The Contact URI, | | | | possibly multiple | | sipPaiURI | 35566/411 | The | | | | P-Asserted-Identity URI | | sipSessionId | 35566/415 | A 128-bit session | | | | identifier, as in | | | | [I-D.kaplan-dispatch-session-id | | | | ] | | sipBodySection | 35566/416 | Section of a SIP | | | | body. If a | | | | sipBodySectionOffset is | | | | present, this section begins | | | | that many octets into the SIP | | | | body; otherwise, the section | | | | begins with the start of the | | | | SIP body. | | sipBodySectionOffse | 35566/417 | Offset of the | | t | | original SIP body, in octets, | | | | from which the sipBodySection | | | | in this record was taken. | | sipBodyLength | 35566/418 | Total length of | | | | the SIP body. | +---------------------+-----------+---------------------------------+ Bringing this all together, the additional Information Elements required by SIPCLF, in textual IE specification format [I-D.trammell-ipfix-text-iespec] is as follows; IE numbers appear in parentheses, IPFIX types in angle brackets, and sizes ("v" for variable-length) in square brackets: Niccolini, et al. Expires February 18, 2011 [Page 8] Internet-Draft SIPCLF - IPFIX August 2010 sipAuthUsername(35566/401)[v] sipMethod(35566/402)[1] sipRequestURI(35566/403)[v] sipFromURI(35566/404)[v] sipFromTag(35566/405)[v] sipToURI(35566/406)[v] sipToTag(35566/407)[v] sipCallId(35566/408)[v] sipSequenceNumber(35566/409)[4] sipContactURI(35566/410)[v] sipPaiURI(35566/411)[v] sipResponseStatus(35566/412)[2] sipServerTransaction(35566/413)[v] sipClientTransaction(35566/414)[v] sipSessionId(35566/415)[16] sipBodySection(35566/416)[v] sipBodySectionOffset(35566/417)[8] sipBodyLength(35566/418)[8] sipObservationType(35566/419)[8] Figure 1: Information Model 3. Recommended Templates for SIPCLF The following Templates are defined as recommended Templates for SIPCLF request and response messages. These are base templates, containing only mandatory Information Elements. Request and Response Templates MUST contain at lease the Information Elements defined here. Optional Information Elements MAY be added to them, and the IPv4 addresses within these Templates MUST be replaced with IPv6 addresses for logging IPv6 transport of SIP messages. A sipServerTransaction Information Element SHOULD be added for all messages logged by a User Agent Server, and a sipClientTransaction Information Element SHOULD be added for all messages logged by a User Agent Client. These templates follow the recommended fields for request and response logging in [I-D.ietf-sipclf-problem-statement], and are defined using the representation in [I-D.trammell-ipfix-text-iespec]. Niccolini, et al. Expires February 18, 2011 [Page 9] Internet-Draft SIPCLF - IPFIX August 2010 observationTimeMilliseconds(323)[8] sipSequenceNumber(35566/409)[4] sourceIPv4Address(8)[4] destinationIPv4Address(12)[4] sourceTransportPort(7)[2] destinationTransportPort(11)[2] protocolIdentifier(4)[1] sipMethod(35566/402)[1] sipObservationType(35566/419)[1] sipRequestURI(35566/403)[v] sipToURI(35566/406)[v] sipToTag(35566/407)[v] sipFromURI(35566/404)[v] sipFromTag(35566/405)[v] sipCallId(35566/408)[v] Figure 2: Base Request Template (IPv4) observationTimeMilliseconds(323)[8] sipSequenceNumber(35566/409)[4] sourceIPv4Address(8)[4] destinationIPv4Address(12)[4] sourceTransportPort(7)[2] destinationTransportPort(11)[2] sipResponseStatus(35566/412)[2] protocolIdentifier(4)[1] sipMethod(35566/402)[1] sipObservationType(35566/419)[1] sipToURI(35566/406)[v] sipToTag(35566/407)[v] sipFromURI(35566/404)[v] sipFromTag(35566/405)[v] sipCallId(35566/408)[v] Figure 3: Base Response Template (IPv4) Note that the Information Elements in these templates are ordered to place the fixed-length elements before the variable-length ones, which speeds random access to fixed-length elements. Elements are also kept in native alignment within records. However, since element order within a record is unimportant in IPFIX, any ordering of the mandatory Information Elements within a record MUST be accepted as a valid SIPCLF record for that record type. The record type is determined by the presence of the sipResponseStatus field. If present in the Template, the Template describes a response record. If absent, it describes a request Niccolini, et al. Expires February 18, 2011 [Page 10] Internet-Draft SIPCLF - IPFIX August 2010 record. 4. IPFIX File Format for SIPCLF Now that we have defined Information Elements to support the SIPCLF Data Model and recommended Templates to define the records, we combine this data model to the IPFIX File format to define the SIPCLF format over IPFIX. The IPFIX File format is defined in [RFC5655] as a serialized set of IPFIX Messages containing Data Records organized in Sets defined by Templates; these are in turn defined in the IPFIX Protocol specification [RFC5101]. The file format is designed to facilitate interoperability, flexibility, and reusability among a wide variety of storage, processing, and analysis tools. A SIPCLF-IPFIX file is then defined as an IPFIX File as in [RFC5655] containing Templates containing at least the Information Elements defined in the recommended Templates above, followed by Data Sets containing records defined by those Templates. The Template mechanism provided by IPFIX allows some flexibility here. A SIPCLF-IPFIX file writer MAY include other Information Elements in the Templates it uses for SIP logging (for example, to add additional information such as in the list of optional Information Elements, above), and MAY include Templates and records described by them which do not contain SIPCLF information; these latter records MAY be ignored by SIPCLF file readers. Some specific considerations for SIPCLF-IPFIX files are detailed in the subsections below. 4.1. Logging Large SIP Bodies As noted in Section 1.2, the IPFIX Message format places a practical limit of 65515 bytes of content per Message. Some SIPCLF fields, particularly the SIP Body, may contain more than 65515 bytes of information. There are two ways to address this. First, for applications where the requirements do not include full body export, the body can be truncated. This specification provides the sipBodySection and sipBodyLength Information Elements to represent this. Here, the first N bytes of the body would be exported in the variable-length sipBodySection Information Element, and the total length of the SIP body in the sipBodyLength Information Element. A template for requests received at a UAS is shown in Figure 4. Niccolini, et al. Expires February 18, 2011 [Page 11] Internet-Draft SIPCLF - IPFIX August 2010 observationTimeMilliseconds(323)[8] sipSequenceNumber(35566/409)[4] sipBodyLength(35566/418)[4] sourceIPv4Address(8)[4] destinationIPv4Address(12)[4] sourceTransportPort(7)[2] destinationTransportPort(11)[2] protocolIdentifier(4)[1] sipMethod(35566/402)[1] sipObservationType(35566/419)[1] sipRequestURI(35566/403)[v] sipToURI(35566/406)[v] sipToTag(35566/407)[v] sipFromURI(35566/404)[v] sipFromTag(35566/405)[v] sipCallId(35566/408)[v] sipServerTransaction(35566/413)[v] sipBodySection(35566/416)[v] Figure 4: Template for Request Record with Partial Body at UAS For exporting large complete SIP bodies, a second continuation template is necessary, as in figure Figure 5. In this case, a record containing the first 64k (minus the length of the other fields) is exported using a template similar to the partial body template above. Then additional sections of the SIP body at subsequent specified offsets into the SIP body are exported in continuation records in subsequent messages. The SIP message whose body is continued is uniquely identified by the 5-tuple flow key and the observation time. This template allows the export of up to 65487 bytes of body per IPFIX message (65515 message payload - 25 fixed fields - 3 sipBodySection length). observationTimeMilliseconds(323)[8] sipBodyOffset(35566/417)[4] sourceIPv4Address(8)[4] destinationIPv4Address(12)[4] sourceTransportPort(7)[2] destinationTransportPort(11)[2] protocolIdentifier(4)[1] sipBodySection(35566/416)[v] Figure 5: Template for Request Record Body Continuation Niccolini, et al. Expires February 18, 2011 [Page 12] Internet-Draft SIPCLF - IPFIX August 2010 4.2. Supporting fast searches of SIPCLF log files The order of fields in an IPFIX data record is semantically unimportant, since the Template defines where each field in the record is. However, note that in all the Templates defined to this point, we have placed fixed-length fields before variable length fields. This increases the efficiency of both Message export and decoding, since each fixed length field as well as the first variable-length field have fixed offsets into the Message. Random access to a field within a record (i.e., for comparison purposes during a sequential scan) is therefore constant-time for fixed-length fields, and requires one or two comparisons per subsequent field for variable-length fields. However, since Sets encode the length of the Set, not of the records therein, and each Set may contain multiple records, a Set containing records with variable-length fields must be sequentially searched in order to find the beginning of the next Message. This situation can be improved by exporting only one Record per Set: in this case, the Set length equals the Record length minus the constant Set header length (4), reducing the number of comparisons needed for skipping records. 5. Efficiency Analysis [TODO] 6. Examples This section presents several views of an example IPFIX-based SIPCLF log, in order to increase understanding of what IPFIX would mean for SIPCLF. We present both binary and textual forms. The tools to generate this section are based upon the open-source ripfix [ripfix] implementation of IPFIX, maintained by one of the authors of this draft. Here we show the log entries generated by the situations in sections 9.1 through 9.4 of [I-D.ietf-sipclf-problem-statement]. 6.1. Base Template Export A SIPCLF log file is, as described above just an IPFIX File with SIPCLF Templates. As Templates are themselves exported in IPFIX Messages, and a File is simply composed of a stream of Messages, first, we can export a Message containing only Templates describing Niccolini, et al. Expires February 18, 2011 [Page 13] Internet-Draft SIPCLF - IPFIX August 2010 the record formats we will use in subsequent examples. These Templates are as shown in Figure 2 and Figure 3. Exporting these Templates results in the following IPFIX message, illustrated as an annotated hexdump in Figure 6. 0000: 00 0a 00 ec 4c 62 7f e8 00 00 00 00 00 00 30 39 ....Lb........09 [ IPFIX message header, length 236 ] 0010: 00 02 00 dc .... [ Template set (ID 2) header, length 220 ] 0014: 01 01 00 10 .... [ Template ID 257, count 16 IEs ] 0018: 01 43 00 08 81 99 00 04 .C...... 0020: 00 00 8a ee 00 08 00 04 00 0c 00 04 00 07 00 02 ................ 0030: 00 0b 00 02 00 04 00 01 81 92 00 01 00 00 8a ee ................ 0040: 81 93 ff ff 00 00 8a ee 81 96 ff ff 00 00 8a ee ................ 0050: 81 97 ff ff 00 00 8a ee 81 94 ff ff 00 00 8a ee ................ 0060: 81 95 ff ff 00 00 8a ee 81 98 ff ff 00 00 8a ee ................ 0070: 81 9e ff ff 00 00 8a ee 81 9d ff ff 00 00 8a ee ................ [ Base request template content (ID 257) ] 0080: 01 02 00 10 .... [ Template ID 258, count 16 IEs ] 0084: 01 43 00 08 81 99 00 04 00 00 8a ee .C.......... 0090: 00 08 00 04 00 0c 00 04 00 07 00 02 00 0b 00 02 ................ 00a0: 81 9c 00 02 00 00 8a ee 00 04 00 01 81 92 00 01 ................ 00b0: 00 00 8a ee 81 96 ff ff 00 00 8a ee 81 97 ff ff ................ 00c0: 00 00 8a ee 81 94 ff ff 00 00 8a ee 81 95 ff ff ................ 00d0: 00 00 8a ee 81 98 ff ff 00 00 8a ee 81 9e ff ff ................ 00e0: 00 00 8a ee 81 9d ff ff 00 00 8a ee ............ [ Base response template content (ID 258) ] Figure 6: Base template message export 6.2. UAC registration Having exported templates, now we create a simple SIPCLF-IPFIX log message representing a UAC registration as seen from the UAC, corresponding to example 9.1 in [I-D.ietf-sipclf-problem-statement]. This message contains two records, including the UAS registration request, and the response received. This is shown in the annotated hexdump in Figure 7. Niccolini, et al. Expires February 18, 2011 [Page 14] Internet-Draft SIPCLF - IPFIX August 2010 0000: 00 0a 00 d8 4c 62 8f 37 00 00 00 00 00 00 30 39 ....Lb.7......09 [ IPFIX message header, length 218 ] 0010: 01 01 00 6b ...k [ Data set (ID 257) header, length 107 ] 0014: 00 00 01 29 13 66 13 93 00 00 00 01 ...).f...... 0020: c6 33 64 0a c6 33 64 01 13 c4 13 c4 11 0c 02 0f .3d..3d......... 0030: 73 69 70 3a 65 78 61 6d 70 6c 65 2e 63 6f 6d 00 sip:example.com. 0040: 00 15 73 69 70 3a 61 6c 69 63 65 40 65 78 61 6d ..sip:alice@exam 0050: 70 6c 65 2e 63 6f 6d 05 37 36 79 68 68 15 66 38 ple.com.76yhh.f8 0060: 31 2d 64 34 2d 66 36 40 65 78 61 6d 70 6c 65 2e 1-d4-f6@example. 0070: 63 6f 6d 06 63 2d 74 72 2d 31 00 com.c-tr-1. [ Request record content ] 007b: 01 02 00 5d ...] [ Data set (ID 258) header, length 93 ] 007f: 00 . 0080: 00 01 29 13 66 15 24 00 00 00 01 c6 33 64 01 c6 ..).f.$.....3d.. 0090: 33 64 0a 13 c4 13 c4 00 c8 11 0c 01 00 00 15 73 3d.............s 00a0: 69 70 3a 61 6c 69 63 65 40 65 78 61 6d 70 6c 65 ip:alice@example 00b0: 2e 63 6f 6d 05 37 36 79 68 68 15 66 38 31 2d 64 .com.76yhh.f81-d 00c0: 34 2d 66 36 40 65 78 61 6d 70 6c 65 2e 63 6f 6d 4-f6@example.com 00d0: 06 63 2d 74 72 2d 31 00 .c-tr-1. [ Response record content ] Figure 7: Message containing two log entries for UAC registration While this demonstrates the binary nature of the SIPCLF-IPFIX format, and shows the content framing for this message, it is not readable for illustration purposes. In Figure 8, as in all subsequent examples, we run the message through the rfdump tool provided with ripfix to provide a more human-readable view. Note that the sipMethod and sipObservationType are encoded according to the registries in Section 2. Niccolini, et al. Expires February 18, 2011 [Page 15] Internet-Draft SIPCLF - IPFIX August 2010 ==== message sequence 0 in domain 12345 at 2010-08-11 11:53:27 UTC ==== ---- record 12345/257 ---- observationTimeMilliseconds => 2010-06-07 17:12:23 UTC sipSequenceNumber => 1 sourceIPv4Address => 198.51.100.10 destinationIPv4Address => 198.51.100.1 sourceTransportPort => 5060 destinationTransportPort => 5060 protocolIdentifier => 17 sipMethod => 12 sipObservationType => 2 sipRequestURI => sip:example.com sipToURI => sipToTag => sipFromURI => sip:alice@example.com sipFromTag => 76yhh sipCallId => f81-d4-f6@example.com sipClientTransaction => c-tr-1 sipServerTransaction => ---- record 12345/258 ---- observationTimeMilliseconds => 2010-06-07 17:12:24 UTC sipSequenceNumber => 1 sourceIPv4Address => 198.51.100.1 destinationIPv4Address => 198.51.100.10 sourceTransportPort => 5060 destinationTransportPort => 5060 sipResponseStatus => 200 protocolIdentifier => 17 sipMethod => 12 sipObservationType => 1 sipToURI => sipToTag => sipFromURI => sip:alice@example.com sipFromTag => 76yhh sipCallId => f81-d4-f6@example.com sipClientTransaction => c-tr-1 sipServerTransaction => Figure 8: Message containing two log entries for UAC registration 6.3. Direct Call [TODO: from section 9.2] 6.4. Single Downstream Branch Call [TODO: from section 9.3] Niccolini, et al. Expires February 18, 2011 [Page 16] Internet-Draft SIPCLF - IPFIX August 2010 6.5. Forked Call [TODO: from section 9.4] 6.6. Torture Tests To demonstrate that the SIPCLF-IPFIX file format can handle other than simple situations, here we show how log entries from selected SIP torture tests given in [RFC4475]. Note that this demonstrates only that there is nothing inherent to the logging format that precludes handling these cases; implementors of logging using SIPCLF- IPFIX must still take care that the SIP-specific side of the implementation handles these torture tests correctly. Each of these tests displays a resulting record with templates defined in Section 6.1 and values for unspecified fields taken from Section 6.2. The torture test in section 3.1.1.2 tests the handling of unusual characters. Assuming that the SIP parser is able to handle this message, the resulting log entry in rfdump format is shown in Figure 9 (hand-edited to fit long lines within Internet-Draft limits). Note that the unknown SIP method is logged as such (method 0 = Unknown). ==== message sequence 0 in domain 12345 at 2010-08-12 07:44:33 UTC ==== ---- record 12345/257 ---- observationTimeMilliseconds => 2010-08-12 07:44:33 UTC sipSequenceNumber => 139122385 sourceIPv4Address => 198.51.100.10 destinationIPv4Address => 198.51.100.1 sourceTransportPort => 5060 destinationTransportPort => 5060 protocolIdentifier => 17 sipMethod => 0 sipObservationType => 1 sipRequestURI => sip:1_unusual.URI~(to-be!sure)&isn't+it$/crazy?,/ ;;*:&it+has=1,weird!*pas$wo~d_too.(doesn't-it)@example.com sipToURI => sip:1_unusual.URI~(to-be!sure)&isn't+it$/crazy?,/ ;;*@example.com sipToTag => sipFromURI => sip:mundane@example.com sipFromTag => _token~1'+`*%!-. sipCallId => intmeth.word%ZK-!.*_+'@word`~)(><:\/"][?}{ sipClientTransaction => sipServerTransaction => Figure 9: Message containing wide variety of characters The torture test in section 3.1.1.4 tests the handling of embedded Niccolini, et al. Expires February 18, 2011 [Page 17] Internet-Draft SIPCLF - IPFIX August 2010 NULs in strings. Since IPFIX uses length-prefixing for variable length strings, this does not present a problem for logging. The resulting record rfdump format in Figure 10. Here, hex escaping shows that the NUL is properly embedded in the string. ==== message sequence 0 in domain 12345 at 2010-08-11 13:01:05 UTC ==== ---- record 12345/257 ---- observationTimeMilliseconds => 2010-08-11 13:01:05 UTC sipSequenceNumber => 14398234 sourceIPv4Address => 198.51.100.10 destinationIPv4Address => 198.51.100.1 sourceTransportPort => 5060 destinationTransportPort => 5060 protocolIdentifier => 17 sipMethod => 12 sipObservationType => 2 sipRequestURI => sip:example.com sipToURI => sip:null-\x00-null@example.com sipToTag => sipFromURI => sip:null-\x00-null@example.com sipFromTag => 839923423 sipCallId => escnull.39203ndfvkjdasfkq3w4otrq0adsfdfnavd sipClientTransaction => sipServerTransaction => Figure 10: Message containing NULs in URIs The sipToURI portion of the record is shown in Figure 11 as an annotated hexdump. Note the length byte at the beginning of the string, and the NUL embedded inside. 003f: 1b . [ varlen record, length 27 ] 0040: 73 69 70 3a 6e 75 6c 6c 2d 00 2d 6e 75 6c 6c 40 sip:null-.-null@ [ note NUL here ^^ ] 0050: 65 78 61 6d 70 6c 65 2e 63 6f 6d example.com Figure 11: Message containing NULs in URIs [TODO multipart body in 3.1.1.11] 7. Security Considerations [TODO] Niccolini, et al. Expires February 18, 2011 [Page 18] Internet-Draft SIPCLF - IPFIX August 2010 8. IANA Considerations [TODO: add new SIP IEs to, create new SIP Method registry, or add numbering to existing registry.] 9. Acknowledgments Cullen Jennings has provided insightful discussions, specific comments and much needed corrections. Nico d'Heureuse helped with the RFC 3665 examples. 10. References 10.1. Normative References [RFC5101] Claise, B., "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information", RFC 5101, January 2008. [RFC5655] Trammell, B., Boschi, E., Mark, L., Zseby, T., and A. Wagner, "Specification of the IP Flow Information Export (IPFIX) File Format", RFC 5655, October 2009. 10.2. Informative References [I-D.ietf-sipclf-problem-statement] Gurbani, V., Burger, E., Anjali, T., Abdelnur, H., and O. Festor, "The Common Log Format (CLF) for the Session Initiation Protocol (SIP)", draft-ietf-sipclf-problem-statement-03 (work in progress), June 2010. [I-D.kaplan-dispatch-session-id] Kaplan, H., "A Session Identifier for the Session Initiation Protocol (SIP)", draft-kaplan-dispatch-session-id-02 (work in progress), July 2010. [I-D.trammell-ipfix-text-iespec] Trammell, B., "A Lightweight Textual Format for IPFIX Information Models and Templates", draft-trammell-ipfix-text-iespec-01 (work in progress), August 2010. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Niccolini, et al. Expires February 18, 2011 [Page 19] Internet-Draft SIPCLF - IPFIX August 2010 Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3665] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and K. Summers, "Session Initiation Protocol (SIP) Basic Call Flow Examples", BCP 75, RFC 3665, December 2003. [RFC4475] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J., and H. Schulzrinne, "Session Initiation Protocol (SIP) Torture Test Messages", RFC 4475, May 2006. [ripfix] Trammell, B., "ripfix: IPFIX for Ruby", available at http://ripfix.rubyforge.org/. Authors' Addresses Saverio Niccolini NEC Laboratories Europe, NEC Europe Ltd. Kurfuersten-Anlage 36 Heidelberg 69115 Germany Phone: +49 (0) 6221 4342 118 Email: niccolini@neclab.eu URI: http://www.neclab.eu Benoit Claise Cisco Systems Inc. De Kleetlaan 6a b1 Diegem, 1813 Belgium Phone: +32 2 704 5622 Fax: Email: bclaise@cisco.com URI: Brian Trammell ETH Zurich Gloriastrasse 35 8092 Zurich Switzerland Email: trammell@tik.ee.ethz.ch Niccolini, et al. Expires February 18, 2011 [Page 20] Internet-Draft SIPCLF - IPFIX August 2010 Hadriel Kaplan Acme Packet 71 Third Ave. Burlington, MA 01803 USA Phone: Email: hkaplan@acmepacket.com Niccolini, et al. Expires February 18, 2011 [Page 21]