From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6872.txt | 2187 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 2187 insertions(+) create mode 100644 doc/rfc/rfc6872.txt (limited to 'doc/rfc/rfc6872.txt') diff --git a/doc/rfc/rfc6872.txt b/doc/rfc/rfc6872.txt new file mode 100644 index 0000000..a024890 --- /dev/null +++ b/doc/rfc/rfc6872.txt @@ -0,0 +1,2187 @@ + + + + + + +Internet Engineering Task Force (IETF) V. Gurbani, Ed. +Request for Comments: 6872 Bell Laboratories, Alcatel-Lucent +Category: Standards Track E. Burger, Ed. +ISSN: 2070-1721 Georgetown University + T. Anjali + Illinois Institute of Technology + H. Abdelnur + O. Festor + INRIA + February 2013 + + + The Common Log Format (CLF) for the Session Initiation Protocol (SIP): + Framework and Information Model + +Abstract + + Well-known web servers such as Apache and web proxies like Squid + support event logging using a common log format. The logs produced + using these de facto standard formats are invaluable to system + administrators for troubleshooting a server and tool writers to craft + tools that mine the log files and produce reports and trends. + Furthermore, these log files can also be used to train anomaly + detection systems and feed events into a security event management + system. The Session Initiation Protocol (SIP) does not have a common + log format, and, as a result, each server supports a distinct log + format that makes it unnecessarily complex to produce tools to do + trend analysis and security detection. This document describes a + framework, including requirements and analysis of existing + approaches, and specifies an information model for development of a + SIP common log file format that can be used uniformly by user agents, + proxies, registrars, and redirect servers as well as back-to-back + user agents. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6872. + + + + +Gurbani, et al. Standards Track [Page 1] + +RFC 6872 SIP CLF February 2013 + + +Copyright Notice + + Copyright (c) 2013 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 + 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 + 2. Terminology .....................................................4 + 3. Problem Statement ...............................................4 + 4. What SIP CLF Is and What It Is Not ..............................5 + 5. Alternative Approaches to SIP CLF ...............................5 + 5.1. SIP CLF and Call Detail Records ............................6 + 5.2. SIP CLF and Packet Capture Tools ...........................6 + 5.3. SIP CLF and Syslog .........................................7 + 5.4. SIP CLF and IPFIX ..........................................8 + 6. Motivation and Use Cases ........................................8 + 7. Challenges in Establishing a SIP CLF ...........................10 + 8. Information Model ..............................................11 + 8.1. SIP CLF Mandatory Fields ..................................11 + 8.2. Mandatory Fields and SIP Entities .........................13 + 9. Examples .......................................................14 + 9.1. UAC Registration ..........................................15 + 9.2. Direct Call between Alice and Bob .........................17 + 9.3. Single Downstream Branch Call .............................20 + 9.4. Forked Call ...............................................25 + 10. Security Considerations .......................................35 + 11. Operational Guidance ..........................................37 + 12. Acknowledgments ...............................................37 + 13. References ....................................................37 + 13.1. Normative References .....................................37 + 13.2. Informative References ...................................38 + + + + + + + + + +Gurbani, et al. Standards Track [Page 2] + +RFC 6872 SIP CLF February 2013 + + +1. Introduction + + Servers executing on Internet hosts produce log records as part of + their normal operations. Some log records are, in essence, a summary + of an application-layer protocol data unit (PDU) that captures, in + precise terms, an event that was processed by the server. These log + records serve many purposes including analysis and troubleshooting. + + Well-known web servers such as Apache and web proxies like Squid + support event logging using a Common Log Format (CLF), the common + structure for logging requests and responses serviced by the web + server. It can be argued that a good part of the success of Apache + has been its CLF because it allowed third parties to produce tools + that analyzed the data and generated traffic reports and trends. The + Apache CLF has been so successful that not only did it become the de + facto standard in producing logging data for web servers but also + many commercial web servers can be configured to produce logs in this + format. An example of the Apache CLF is depicted next: + + %h %l %u %t \"%r\" %s %b + remotehost rfc931 authuser [date] request status bytes + + remotehost: Remote hostname (or IP number if DNS hostname is not + available or if DNSLookup is Off. + + rfc931: The remote logname of the user. + + authuser: The username by which the user has authenticated + himself. + + [date]: Date and time of the request. + + request: The request line exactly as it came from the client. + + status: The HTTP status code returned to the client. + + bytes: The content-length of the document transferred. + + The inspiration for the SIP CLF is the Apache CLF. However, the + state machinery for an HTTP transaction is much simpler than that of + the SIP transaction (as evidenced in Section 7). The SIP CLF needs + to do considerably more. + + This document outlines the problem statement that argues for a SIP + CLF. In addition, it provides an information model pertaining to the + minimum set of SIP headers and fields that must be logged. This + document does not prescribe a specific representation format for the + + + + +Gurbani, et al. Standards Track [Page 3] + +RFC 6872 SIP CLF February 2013 + + + SIP CLF record and, instead, allows other documents to define a + representation format. [RFC6873] is an example of a representation + format that provides a UTF-8-based logging scheme. + +2. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + + RFC 3261 [RFC3261] defines additional terms used in this document + that are specific to the SIP domain such as "proxy"; "registrar"; + "redirect server"; "user agent server" or "UAS"; "user agent client" + or "UAC"; "back-to-back user agent" or "B2BUA"; "dialog"; + "transaction"; "server transaction". + + This document uses the term "SIP server" that is defined to include + the following SIP entities: user agent server, registrar, redirect + server, a SIP proxy in the role of user agent server, and a B2BUA in + the role of a user agent server. + +3. Problem Statement + + The Session Initiation Protocol (SIP) [RFC3261] is an Internet + multimedia session signaling protocol. A typical deployment of SIP + in an enterprise will consist of SIP entities from multiple vendors. + Each SIP entity produces logs using a proprietary format. The result + of multiplicity of the log file formats is the inability of the + support staff to easily trace a call from one entity to another or + even to craft common tools that will perform trend analysis, + debugging and troubleshooting problems uniformly across the SIP + entities from multiple vendors. + + Furthermore, the log file must be easily accessible by command-line + tools for simple text processing. This allows ad hoc queries against + the elements in the log file to retrieve a log record. Furthermore, + the log file must be in a format that allows for rapid searches of a + particular log record (or records). Because of the large number of + records expected in the log file, the records must be in a format + that allows for rapid scanning and ease of skipping records that do + not match a search criterion. Finally, the generation of the log + file must not impose undue burden on the SIP implementation in the + form of additional libraries that may not be uniformly available on + different platforms and operating environments where a SIP entity + generating a log file record may be found. + + + + + + +Gurbani, et al. Standards Track [Page 4] + +RFC 6872 SIP CLF February 2013 + + + SIP does not currently have a common log format, and this document + serves to provide the rationale to establish a SIP CLF and identifies + the required minimal information that must appear in any SIP CLF + record. + +4. What SIP CLF Is and What It Is Not + + The SIP CLF is a standardized manner of producing a log file. This + format can be used by SIP clients, SIP servers, proxies, and B2BUAs. + The SIP CLF is simply an easily digestible log of currently occurring + events and past transactions. It contains enough information to + allow humans and automata to derive relationships between discrete + transactions handled at a SIP entity or to search for a certain + dialog or a related set of transactions. + + The SIP CLF is amenable to quick parsing (i.e., well-delimited + fields), and it is platform and operating system neutral. + + Due to the structure imposed by delimited fields, the SIP CLF is + amenable to easy parsing and lends itself well to creating other + innovative tools such as logfile parsers and trend analytic engines. + + The SIP CLF is not a billing tool. It is not expected that + enterprises will bill customers based on SIP CLF. The SIP CLF + records events at the signaling layer only and does not attempt to + correlate the veracity of these events with the media layer. Thus, + it cannot be used to trigger customer billing. + + The SIP CLF is not a quality of service (QoS) measurement tool. If + QoS is defined as measuring the mean opinion score (MOS) of the + received media, then SIP CLF does not aid in this task since it does + not summarize events at the media layer. + + Finally, the SIP CLF is not a tool for supporting lawful intercept. + +5. Alternative Approaches to SIP CLF + + The sipclf working group discussed four alternative approaches to + determine whether they fill the requirements of what is desired of a + SIP CLF outlined in Section 3. We conclude that while every scheme + discussed below comes with its advantages, its disadvantages may + preclude it from being used as a SIP CLF. However, we stress that + the information model contained in this document can be used to + develop alternative representation formats when desired. Currently, + [RFC6873] is an example of a representation format that provides a + UTF-8-based logging scheme that meets all the requirements of Section + 3. + + + + +Gurbani, et al. Standards Track [Page 5] + +RFC 6872 SIP CLF February 2013 + + +5.1. SIP CLF and Call Detail Records + + Call Detail Records (CDRs) are used in operator networks widely and + with the adoption of SIP, standardization bodies such as the Third + Generation Partnership Project (3GPP) have subsequently defined SIP- + related CDRs as well. Today, CDRs are used to implement the + functionality approximated by SIP CLF; however, there are important + differences. + + First, SIP CLF operates natively at the transaction layer and + maintains enough information in the information elements being logged + that dialog-related data can be subsequently derived from the + transaction logs. Thus, esoteric SIP fields and parameters like the + To header (including tags), the From header (including tags), the + Command Sequence (CSeq) number, etc., are logged in SIP CLF. By + contrast, a CDR is used mostly for charging and thus saves + information to facilitate that very aspect. A CDR will most + certainly log the public user identification of a party requesting a + service (which may not correspond to the From header) and the public + user identification of the party called party (which may not + correspond to the To header). Furthermore, the sequence numbers + maintained by the CDR may not correspond to the SIP CSeq header. + Thus, it will be hard to piece together the state of a dialog through + a sequence of CDR records. + + Second, a CDR record will, in all probability, be generated at a SIP + entity performing some form of proxy-like functionality of a B2BUA + providing some service. By contrast, SIP CLF is lightweight enough + that it can be generated by a canonical SIP user agent server and + user agent client as well, including those that execute on resource + constrained devices (mobile phones). + + Finally, SIP is also being deployed outside of operator-managed Voice + over IP (VoIP) networks. Universities, research laboratories, and + small-to medium-sized companies are deploying SIP-based VoIP + solutions on networks owned and managed by them. Many of the latter + constituencies will not have an interest in generating CDRs, but they + will like to have a concise representation of the messages being + handled by the SIP entities in a common format. + +5.2. SIP CLF and Packet Capture Tools + + Wireshark and tcpdump are popular raw packet capture tools. + Wireshark even contains filters that can understand SIP at the + protocol level and break down a captured message into its individual + header components. While packet capture tools are appropriate to + capture and view discrete SIP messages, they do not suffice to serve + in the same capacity as SIP CLF for the following reasons: + + + +Gurbani, et al. Standards Track [Page 6] + +RFC 6872 SIP CLF February 2013 + + + o Using packet capturing tools will not eliminate the need for + agreeing to a common set of fields to represent a SIP CLF record. + This common understanding is important for interoperability to + allow one implementation to read a log file written by a different + implementation. + + o The packet capture from these tools is not easily searchable by + simple command-line tools for text processing. + + o Using packet capture tools requires that the underlying libraries + related to packet capture be available for all platforms on which + a SIP server or a SIP client can execute. Given the different + platforms on which a SIP client or server runs --- mobile, fixed + host, tablet, etc. --- this may become an inhibiting factor when + compared to the SIP client or server producing a SIP CLF record + natively (the SIP client or server has already parsed the SIP + message for operation on it; therefore, it seems reasonable to + have it write the parsed tokens out to persistent store in an + agreed upon format). + + o If SIP messages are exchanged over a secure transport (TLS) + packet, capture tools will be unable to decrypt them and render + them as individual SIP headers. + + o Using such tools and related packet capture libraries may imposes + a dependency on a third-party library. + +5.3. SIP CLF and Syslog + + The syslog protocol [RFC5424] conveys event notification messages + from an originator to a collector. While the syslog protocol + provides a packet format and transport mechanism, it does not + describe any storage format for syslog messages. Pragmatically, + while the syslog protocol itself does not describe a storage format, + the collector will write the arriving messages into a disk file. A + new problem arises due to the general nature of syslog: the disk file + will contain log messages from many originators, not just SIP + entities. This imposes an additional burden of discarding all + extraneous records when analyzing the disk file for SIP CLF records + of interest. SIP CLF records are best stored in a log file that is + easily searchable by command-line tools. + + Other drawbacks of using syslog include the unavailability of the + collector under certain scenarios (a mobile SIP phone may be unable + to find a collector to which it should send the messages), and the + need to have syslog-specific libraries available for each platform on + which the SIP server or the SIP client can execute. Finally, because + of the frequency and size of SIP log messages, it is not desirable to + + + +Gurbani, et al. Standards Track [Page 7] + +RFC 6872 SIP CLF February 2013 + + + send every SIP CLF log message to the collector. Instead, a + judicious use of syslog could be that only certain events -- those + that are pertinent from a network situational awareness perspective, + or those that include a periodic statistical summary of the messages + processed -- are sent to the collector. + +5.4. SIP CLF and IPFIX + + The IP Flow Information Export (IPFIX) protocol [RFC5101] allows + network administrators to aggregate IP packets characterized by some + commonality (similar packet header fields, one or more + characteristics of the packet itself) into a flow that can be + subsequently collected and sent to other elements for analysis and + monitoring. However, IPFIX is not a logging format and does not + produce a log file that can be examined by ad hoc text processing + tools. + +6. Motivation and Use Cases + + As SIP becomes pervasive in multiple business domains and ubiquitous + in academic and research environments, it is beneficial to establish + a CLF for the following reasons: + + Common reference for interpreting events: In a laboratory + environment or an enterprise service offering, there will + typically be SIP entities from multiple vendors participating in + routing requests. Absent a common log format, each entity will + produce output records in a native format, making it hard to + establish commonality for tools that operate on the log file. + + Writing common tools: A common log format allows independent tool + providers to craft tools and applications that interpret the CLF + data to produce insightful trend analysis and detailed traffic + reports. The format should be such that it retains the ability to + be read by humans and processed using traditional Unix text + processing tools. + + Session correlation across diverse processing elements: In + operational SIP networks, a request will typically be processed by + more than one SIP server. A SIP CLF will allow the network + operator to trace the progression of the request (or a set of + requests) as they traverse through the different servers to + establish a concise diagnostic trail of a SIP session. + + Note that tracing the request through a set of servers is + considerably less challenging if all the servers belong to + the same administrative domain. + + + + +Gurbani, et al. Standards Track [Page 8] + +RFC 6872 SIP CLF February 2013 + + + Message correlation across transactions: A SIP CLF can enable a + quick lookup of all messages that comprise a transaction (e.g., + "Find all messages corresponding to server transaction X, + including all forked branches."). + + Message correlation across dialogs: A SIP CLF can correlate + transactions that comprise a dialog (e.g., "Find all messages for + dialog created by Call-ID C, From tag F and To tag T."). + + Trend analysis: A SIP CLF allows an administrator to collect data + and spot patterns or trends in the information (e.g., "What is the + domain where the most sessions are routed to between 9:00 AM and + 1:00 PM?"). + + Train anomaly detection systems: A SIP CLF will allow for the + training of anomaly detection systems that once trained can + monitor the CLF file to trigger an alarm on the subsequent + deviations from accepted patterns in the data set. Currently, + anomaly detection systems monitor the network and parse raw + packets that comprise a SIP message -- a process that is + unsuitable for anomaly detection systems [rieck2008]. With all + the necessary event data at their disposal, network operations + managers and information technology operation managers are in a + much better position to correlate, aggregate, and prioritize log + data to maintain situational awareness. + + Testing: A SIP CLF allows for automatic testing of SIP equipment by + writing tools that can parse a SIP CLF file to ensure behavior of + a device under test. + + Troubleshooting: A SIP CLF can enable cursory troubleshooting of a + SIP entity (e.g., "How long did it take to generate a final + response for the INVITE associated with Call-ID X?"). + + Offline analysis: A SIP CLF allows for offline analysis of the data + gathered. Once a SIP CLF file has been generated, it can be + transported (subject to the security considerations in Section 10) + to a host with appropriate computing resources to perform + subsequent analysis. + + Real-time monitoring: A SIP CLF allows administrators to visually + notice the events occurring at a SIP entity in real-time providing + accurate situational awareness. + + + + + + + + +Gurbani, et al. Standards Track [Page 9] + +RFC 6872 SIP CLF February 2013 + + +7. Challenges in Establishing a SIP CLF + + Establishing a CLF for SIP is a challenging task. The behavior of a + SIP entity is more complex when compared to the equivalent HTTP + entity. + + Base protocol services such as parallel or serial forking elicit + multiple final responses. Ensuing delays between sending a request + and receiving a final response all add complexity when considering + what fields should comprise a CLF and in what manner. Furthermore, + unlike HTTP, SIP groups multiple discrete transactions into a dialog, + and these transactions may arrive at a varying inter-arrival rate at + a proxy. For example, the BYE transaction usually arrives much after + the corresponding INVITE transaction was received, serviced, and + expunged from the transaction list. Nonetheless, it is advantageous + to relate these transactions such that automata or a human monitoring + the log file can construct a set consisting of related transactions. + + ACK requests in SIP need careful consideration as well. In SIP, an + ACK is a special method that is associated with an INVITE only. It + does not require a response; furthermore, if it is acknowledging a + non-2xx response, then the ACK is considered part of the original + INVITE transaction. If it is acknowledging a 2xx-class response, + then the ACK is a separate transaction consisting of a request only + (i.e., there is not a response for an ACK request). CANCEL is + another method that is tied to an INVITE transaction, but unlike ACK, + the CANCEL request elicits a final response. + + While most requests elicit a response immediately, the INVITE request + in SIP can remain in a pending state at a proxy as it forks branches + downstream or at a user agent server while it alerts the user. + [RFC3261] instructs the server transaction to send a 1xx-class + provisional response if a final response is delayed for more than 200 + ms. A SIP CLF log file needs to include such provisional responses + because they help train automata associated with anomaly detection + systems and provide some positive feedback for a human observer + monitoring the log file. + + Finally, beyond supporting native SIP actors such as proxies, + registrars, redirect servers, and user agent servers (UASs), it is + beneficial to derive a common log format that supports B2BUA + behavior, which may vary considerably depending on the specific + nature of the B2BUA. + + + + + + + + +Gurbani, et al. Standards Track [Page 10] + +RFC 6872 SIP CLF February 2013 + + +8. Information Model + + This document defines the mandatory fields that MUST occur in a SIP + CLF record. The maximum size (in number of bytes) for a SIP CLF + field is 4096 bytes. This limit is the same regardless of whether + the SIP CLF field is a meta-field (see "Timestamp" and + "Directionality" defined below) or a normal SIP header. If the body + of the SIP message is to be logged, it MUST conform to this limit as + well. + + SIP bodies may contain characters that do not form a valid UTF-8 + sequence. As such, the logging of bodies requires understanding + trade-offs with respect to a specific logging format to determine if + the body can be logged as is or some encoding will be required. The + specific syntax and semantics used to log SIP bodies MUST be defined + by the specific representation format document used to generate the + SIP CLF record. + + The information model supports extensibility by providing the + capability to log "optional fields". Optional fields are those SIP + header fields (or field components) that are not mandatory (see + Section 8.1 for the mandatory field list). Optional fields may + contain SIP headers or other elements present in a SIP message (for + example, the Reason-Phrase element from the Status-Line production + rule in RFC 3261 [RFC3261]). Optional fields may also contain + additional information that a particular vendor desires to log. The + specific syntax and semantics to be accorded to optional fields MUST + be defined by the specific representation format used to generate the + SIP CLF record. + +8.1. SIP CLF Mandatory Fields + + The following SIP CLF fields are defined as the minimal information + that MUST appear in any SIP CLF record: + + Timestamp: Date and time of the request or response represented as + the number of seconds and milliseconds since the Unix epoch. + + Message type: An indicator of whether the SIP message is a request + or a response. The allowable values for this field are 'R' (for + Request) and 'r' (for response). + + Directionality: An indicator of whether the SIP message is received + by the SIP entity or sent by the SIP entity. The allowable values + for this field are 's' (for message sent) and 'r' (for message + received). + + + + + +Gurbani, et al. Standards Track [Page 11] + +RFC 6872 SIP CLF February 2013 + + + Transport: The transport over which a SIP message is sent or + received. The allowable values for the transport are governed by + the "transport" production rule in Section 25.1 of RFC 3261 + [RFC3261]. + + Source-address: The IPv4 or IPv6 address of the sender of the SIP + message. + + Source-port: The source port number of the sender of the SIP + message. + + Destination-address: The IPv4 or IPv6 address of the recipient of + the SIP message. + + Destination-port: The port number of the recipient of the SIP + message. + + From: The From URI. For the sake of brevity, URI parameters should + not be logged. + + From tag: The tag parameter of the From header. + + To: The To URI. For the sake of brevity, URI parameters should not + be logged. + + To tag: The tag parameter of the To header. Note that the tag + parameter will be absent in the initial request that forms a + dialog. + + Callid: The Call-ID. + + CSeq-Method: The method from the CSeq header. + + CSeq-Number: The number from the CSeq header. + + R-URI: The Request-URI, including any URI parameters. + + Status: The SIP response status code. + + SIP proxies may fork, creating several client transactions that + correlate to a single server transaction. Responses arriving on + these client transactions or new requests (CANCEL, ACK) sent on the + client transaction need log file entries that correlate with a server + transaction. Similarly, a B2BUA may create one or more client + transactions in response to an incoming request. These transactions + will require correlation as well. The last two information model + elements provide this correlation. + + + + +Gurbani, et al. Standards Track [Page 12] + +RFC 6872 SIP CLF February 2013 + + + Server-Txn: Server transaction identification code - the transaction + identifier associated with the server transaction. + Implementations can reuse the server transaction identifier (the + topmost branch-id of the incoming request, with or without the + magic cookie), or they could generate a unique identification + string for a server transaction (this identifier needs to be + locally unique to the server only). This identifier is used to + correlate ACKs and CANCELs to an INVITE transaction; it is also + used to aid in forking as explained later in this section. (See + Section 9 for usage.) + + Client-Txn: Client transaction identification code - this field is + used to associate client transactions with a server transaction + for forking proxies or B2BUAs. Upon forking, implementations can + reuse the value they inserted into the topmost Via header's branch + parameter, or they can generate a unique identification string for + the client transaction. (See Section 9 for usage.) + + This information model applies to all SIP entities --- a UAC, UAS, + proxy, B2BUA, registrar, and redirect server. The SIP CLF fields + prescribed for a proxy are equally applicable to the B2BUA. + Similarly, the SIP CLF fields prescribed for a UAS are equally + applicable to registrars and redirect servers. + + The next section specifies the individual SIP CLF information model + elements that form a log record for specific instances of a SIP + entity. It is understood that a SIP CLF record is extensible using + extension mechanisms appropriate to the specific representation used + to generate the SIP CLF record. This document, however, does not + prescribe a specific representation format, and it limits the + discussion to the mandatory data elements described above. + +8.2. Mandatory Fields and SIP Entities + + Each SIP CLF record must contain all the mandatory information model + elements outlined in Section 8.1. This document does not specify a + representation of a logging format; it is expected that other + documents will do so. + + An element may not always have an appropriate value to provide for + one of these fields, for example, the R-URI field is not applicable + when logging a response, the Status field is not applicable when + logging a request, the To tag is not known when a request is first + sent out, etc. As all the mandatory fields are required to appear in + the SIP CLF record, the representation document MUST define how to + indicate a field that is not applicable in the context that the SIP + + + + + +Gurbani, et al. Standards Track [Page 13] + +RFC 6872 SIP CLF February 2013 + + + CLF record was generated. Similarly, to handle parsing errors in a + field, the representation document MUST define a means to indicate + that a field cannot be parsed. + + The Client-Txn field is always applicable to a UAC. The Server-Txn + field does not apply to a UAC unless the element is also acting as a + UAS, and the message associated to this log record corresponds to a + message handled by that UAS. For instance, a proxy forwarding a + request will populate both the Client-Txn and Server-Txn fields in + the record corresponding to the forwarded request. + + The Server-Txn field is always applicable to a UAS. The Client-Txn + field does not apply to a UAS unless the element is also acting as a + UAC, and the message associated to this log record corresponds to a + message handled by that UAC. For instance, a proxy forwarding a + response will populate both the Server-Txn and Client-Txn fields in + the record corresponding to the forwarded response. However, a proxy + would only populate the Client-Txn field when creating a log record + corresponding to a request. + +9. Examples + + The examples use only the mandatory data elements defined in Section + 8.1. Extension elements are not considered and neither are SIP + bodies. When a given mandatory field is not applicable to a SIP + entity, we use the horizontal dash ("-") to represent it. + + There are five principals in the examples below. They are the + following: Alice, the initiator of requests. Alice's user agent uses + IPv4 address 198.51.100.1, port 5060. P1 is a proxy that Alice's + request traverse on their way to Bob, the recipient of the requests. + P1 also acts as a registrar to Alice. P1 uses an IPv4 address of + 198.51.100.10, port 5060. Bob has two instances of his user agent + running on different hosts. The first instance uses an IPv4 address + of 203.0.113.1, port 5060 and the second instance uses an IPv6 + address of 2001:db8::9, port 5060. P2 is a proxy responsible for + Bob's domain. Table 1 summarizes these addresses. + + + + + + + + + + + + + + +Gurbani, et al. Standards Track [Page 14] + +RFC 6872 SIP CLF February 2013 + + + +-------------------+--------------------+-------------------+ + | Principal | IP:port | Host/Domain name | + +-------------------+--------------------+-------------------+ + | Alice | 198.51.100.1:5060 | alice.example.com | + | P1 | 198.51.100.10:5060 | p1.example.com | + | P2 | 203.0.113.200:5060 | p2.example.net | + | Bob UA instance 1 | 203.0.113.1:5060 | bob1.example.net | + | Bob UA instance 2 | [2001:db8::9]:5060 | bob2.example.net | + +-------------------+--------------------+-------------------+ + + Principal to IP Address Assignment + + Table 1 + + Illustrative examples of SIP CLF follow. + +9.1. UAC Registration + + Alice sends a registration registrar P1 and receives a 2xx-class + response. The register requests causes Alice's UAC to produce a log + record shown below. + + Timestamp: 1275930743.699 + Message Type: R + Directionality: s + Transport: udp + CSeq-Number: 1 + CSeq-Method: REGISTER + R-URI: sip:example.com + Destination-address: 198.51.100.10 + Destination-port: 5060 + Source-address: 198.51.100.1 + Source-port: 5060 + To: sip:example.com + To tag: - + From: sip:alice@example.com + From tag: 76yhh + Call-ID: f81-d4-f6@example.com + Status: - + Server-Txn: - + Client-Txn: c-tr-1 + + + + + + + + + + +Gurbani, et al. Standards Track [Page 15] + +RFC 6872 SIP CLF February 2013 + + + After some time, Alice's UAC will receive a response from the + registrar. The response causes Alice's agent to produce a log record + shown below. + + Timestamp: 1275930744.100 + Message Type: r + Directionality: r + Transport: udp + CSeq-Number: 1 + CSeq-Method: REGISTER + R-URI: - + Destination-address: 198.51.100.1 + Destination-port: 5060 + Source-address: 198.51.100.10 + Source-port: 5060 + To: sip:example.com + To tag: reg-1-xtr + From: sip:alice@example.com + From tag: 76yhh + Call-ID: f81-d4-f6@example.com + Status: 100 + Server-Txn: - + Client-Txn: c-tr-1 + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gurbani, et al. Standards Track [Page 16] + +RFC 6872 SIP CLF February 2013 + + +9.2. Direct Call between Alice and Bob + + In this example, Alice sends a session initiation request directly to + Bob's agent (instance 1). Bob's agent accepts the session + invitation. We first present the SIP CLF logging from the vantage + point of Alice's UAC. In line 1, Alice's user agent sends out the + INVITE. Shortly, it receives a "180 Ringing" (line 2), followed by a + "200 OK" response (line 3). Upon the receipt of the 2xx-class + response, Alice's user agent sends out an ACK request (line 4). + + Timestamp: 1275930743.699 + Message Type: R + Directionality: s + Transport: udp + CSeq-Number: 32 + CSeq-Method: INVITE + R-URI: sip:bob@bob1.example.net + Destination-address: 203.0.113.1 + Destination-port: 5060 + Source-address: 198.51.100.1 + Source-port: 5060 + To: sip:bob@bob1.example.net + To tag: - + From: sip:alice@example.com + From tag: 76yhh + Call-ID: f82-d4-f7@example.com + Status: - + Server-Txn: - + Client-Txn: c-1-xt6 + + + + + + + + + + + + + + + + + + + + + + +Gurbani, et al. Standards Track [Page 17] + +RFC 6872 SIP CLF February 2013 + + + Timestamp: 1275930745.002 + Message Type: r + Directionality: r + Transport: udp + CSeq-Number: 32 + CSeq-Method: INVITE + R-URI: - + Destination-address: 198.51.100.1 + Destination-port: 5060 + Source-address: 203.0.113.1 + Source-port: 5060 + To: sip:bob@example.net + To tag: b-in6-iu + From: sip:alice@example.com + From tag: 76yhh + Call-ID: f82-d4-f7@example.com + Status: 180 + Server-Txn: - + Client-Txn: c-1-xt6 + + Timestamp: 1275930746.100 + Message Type: r + Directionality: r + Transport: udp + CSeq-Number: 32 + CSeq-Method: INVITE + R-URI: - + Destination-address: 198.51.100.1 + Destination-port: 5060 + Source-address: 203.0.113.1 + Source-port: 5060 + To: sip:bob@example.net + To tag: b-in6-iu + From: sip:alice@example.com + From tag: 76yhh + Call-ID: f82-d4-f7@example.com + Status: 200 + Server-Txn: - + Client-Txn: c-1-xt6 + + + + + + + + + + + + +Gurbani, et al. Standards Track [Page 18] + +RFC 6872 SIP CLF February 2013 + + + Timestamp: 1275930746.120 + Message Type: R + Directionality: s + Transport: udp + CSeq-Number: 32 + CSeq-Method: ACK + R-URI: sip:bob@bob1.example.net + Destination-address: 203.0.113.1 + Destination-port: 5060 + Source-address: 198.51.100.1 + Source-port: 5060 + To: sip:bob@example.net + To tag: b-in6-iu + From: sip:alice@example.com + From tag: 76yhh + Call-ID: f82-d4-f7@example.com + Status: - + Server-Txn: - + Client-Txn: c-1-xt6 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gurbani, et al. Standards Track [Page 19] + +RFC 6872 SIP CLF February 2013 + + +9.3. Single Downstream Branch Call + + In this example, Alice sends a session invitation request to Bob + through proxy P1, which inserts a Record-Route header causing + subsequent requests between Alice and Bob to traverse the proxy. The + SIP CLF log records appears from the vantage point of P1. The line + numbers below refer to Figure 1. + + Alice P1 Bob + +---INV--------->| | Line 1 + | | | + |<---------100---+ | Line 2 + | | | + | +---INV-------->| Line 3 + | | | + | |<--------100---+ Line 4 + | | | + | |<--------180---+ Line 5 + | | | + |<---------180---+ | Line 6 + | | | + | |<--------200---+ Line 7 + | | | + |<---------200---+ | Line 8 + | | | + +---ACK--------->| | Line 9 + | | | + | |---ACK-------->| Line 10 + + Figure 1: Simple Proxy-Aided Call Flow + + + + + + + + + + + + + + + + + + + + + +Gurbani, et al. Standards Track [Page 20] + +RFC 6872 SIP CLF February 2013 + + + 1 Timestamp: 1275930743.699 + Message Type: R + Directionality: r + Transport: udp + CSeq-Number: 43 + CSeq-Method: INVITE + R-URI: sip:bob@example.net + Destination-address: 198.51.100.10 + Destination-port: 5060 + Source-address: 198.51.100.1 + Source-port: 5060 + To: sip:bob@example.net + To tag: - + From: sip:alice@example.com + From tag: al-1 + Call-ID: tr-87h@example.com + Status: - + Server-Txn: s-x-tr + Client-Txn: - + + Note that, at this point, P1 has created a server transaction + identification code and populated the SIP CLF field Server-Txn with + it. P1 has not yet created a client transaction identification code; + thus, Client-Txn contains a "-". + + 2 Timestamp: 1275930744.001 + Message Type: r + Directionality: s + Transport: udp + CSeq-Number: 43 + CSeq-Method: INVITE + R-URI: - + Destination-address: 198.51.100.1 + Destination-port: 5060 + Source-address: 198.51.100.10 + Source-port: 5060 + To: sip:bob@example.net + To tag: - + From: sip:alice@example.com + From tag: al-1 + Call-ID: tr-87h@example.com + Status: 100 + Server-Txn: s-x-tr + Client-Txn: - + + + + + + + +Gurbani, et al. Standards Track [Page 21] + +RFC 6872 SIP CLF February 2013 + + + In line 3 below, P1 has created a client transaction identification + code for the downstream branch and populated the SIP CLF field + Client-Txn. + + 3 Timestamp: 1275930744.998 + Message Type: R + Directionality: s + Transport: udp + CSeq-Number: 43 + CSeq-Method: INVITE + R-URI: sip:bob@bob1.example.net + Destination-address: 203.0.113.1 + Destination-port: 5060 + Source-address: 198.51.100.10 + Source-port: 5060 + To: sip:bob@example.net + To tag: - + From: sip:alice@example.com + From tag: al-1 + Call-ID: tr-87h@example.com + Status: - + Server-Txn: s-x-tr + Client-Txn: c-x-tr + + 4 Timestamp: 1275930745.200 + Message Type: r + Directionality: r + Transport: udp + CSeq-Number: 43 + CSeq-Method: INVITE + R-URI: - + Destination-address: 198.51.100.10 + Destination-port: 5060 + Source-address: 203.0.113.1 + Source-port: 5060 + To: sip:bob@example.net + To tag: b1-1 + From: sip:alice@example.com + From tag: al-1 + Call-ID: tr-87h@example.com + Status: 100 + Server-Txn: s-x-tr + Client-Txn: c-x-tr + + + + + + + + +Gurbani, et al. Standards Track [Page 22] + +RFC 6872 SIP CLF February 2013 + + + 5 Timestamp: 1275930745.800 + Message Type: r + Directionality: r + Transport: udp + CSeq-Number: 43 + CSeq-Method: INVITE + R-URI: - + Destination-address: 198.51.100.10 + Destination-port: 5060 + Source-address: 203.0.113.1 + Source-port: 5060 + To: sip:bob@example.net + To tag: b1-1 + From: sip:alice@example.com + From tag: al-1 + Call-ID: tr-87h@example.com + Status: 180 + Server-Txn: s-x-tr + Client-Txn: c-x-tr + + 6 Timestamp: 1275930746.009 + Message Type: r + Directionality: s + Transport: udp + CSeq-Number: 43 + CSeq-Method: INVITE + R-URI: - + Destination-address: 198.51.100.1 + Destination-port: 5060 + Source-address: 198.51.100.10 + Source-port: 5060 + To: sip:bob@example.net + To tag: b1-1 + From: sip:alice@example.com + From tag: al-1 + Call-ID: tr-87h@example.com + Status: 180 + Server-Txn: s-x-tr + Client-Txn: c-x-tr + + + + + + + + + + + + +Gurbani, et al. Standards Track [Page 23] + +RFC 6872 SIP CLF February 2013 + + + 7 Timestamp: 1275930747.120 + Message Type: r + Directionality: r + Transport: udp + CSeq-Number: 43 + CSeq-Method: INVITE + R-URI: - + Destination-address: 198.51.100.10 + Destination-port: 5060 + Source-address: 203.0.113.1 + Source-port: 5060 + To: sip:bob@example.net + To tag: b1-1 + From: sip:alice@example.com + From tag: al-1 + Call-ID: tr-87h@example.com + Status: 200 + Server-Txn: s-x-tr + Client-Txn: c-x-tr + + 8 Timestamp: 1275930747.300 + Message Type: r + Directionality: s + Transport: udp + CSeq-Number: 43 + CSeq-Method: INVITE + R-URI: - + Destination-address: 198.51.100.1 + Destination-port: 5060 + Source-address: 198.51.100.10 + Source-port: 5060 + To: sip:bob@example.net + To tag: b1-1 + From: sip:alice@example.com + From tag: al-1 + Call-ID: tr-87h@example.com + Status: 200 + Server-Txn: s-x-tr + Client-Txn: c-x-tr + + + + + + + + + + + + +Gurbani, et al. Standards Track [Page 24] + +RFC 6872 SIP CLF February 2013 + + + 9 Timestamp: 1275930749.100 + Message Type: R + Directionality: r + Transport: udp + CSeq-Number: 43 + CSeq-Method: ACK + R-URI: sip:bob@example.net + Destination-address: 198.51.100.10 + Destination-port: 5060 + Source-address: 198.51.100.1 + Source-port: 5060 + To: sip:bob@example.net + To tag: b1-1 + From: sip:alice@example.com + From tag: al-1 + Call-ID: tr-87h@example.com + Status: - + Server-Txn: s-x-tr + Client-Txn: c-x-tr + + 10 Timestamp: 1275930749.100 + Message Type: R + Directionality: s + Transport: udp + CSeq-Number: 43 + CSeq-Method: ACK + R-URI: sip:bob@bob1.example.net + Destination-address: 203.0.113.1 + Destination-port: 5060 + Source-address: 198.51.100.10 + Source-port: 5060 + To: sip:bob@example.net + To tag: b1-1 + From: sip:alice@example.com + From tag: al-1 + Call-ID: tr-87h@example.com + Status: - + Server-Txn: s-x-tr + Client-Txn: c-x-tr + +9.4. Forked Call + + In this example, Alice sends a session invitation to Bob's proxy, P2. + P2 forks the session invitation request to two registered endpoints + corresponding to Bob's address-of-record. Both endpoints respond + with provisional responses. Shortly thereafter, one of Bob's user + agent instances accepts the call, causing P2 to send a CANCEL request + to the second user agent. P2 does not Record-Route; therefore, the + + + +Gurbani, et al. Standards Track [Page 25] + +RFC 6872 SIP CLF February 2013 + + + subsequent ACK request from Alice to Bob's user agent does not + traverse through P2 (and is not shown below). + + Figure 2 depicts the call flow. + Bob Bob + Alice P2 (Instance 1) (Instance 2) + +---INV--->| | | Line 1 + | | | | + |<---100---+ | | Line 2 + | | | | + | +---INV--->| | Line 3 + | | | | + | +---INV----+-------->| Line 4 + | | | | + | |<---100---+ | Line 5 + | | | | + | |<---------+---100---+ Line 6 + | | | | + | |<---180---+---------+ Line 7 + | | | | + |<---180---+ | | Line 8 + | | | | + | |<---180---+ | Line 9 + | | | | + |<---180---+ | | Line 10 + | | | | + | |<---200---+ | Line 11 + | | | | + |<---200---+ | | Line 12 + | | | | + | +---CANCEL-+-------->| Line 13 + | | | | + | |<---------+---487---+ Line 14 + | | | | + | +---ACK----+-------->| Line 15 + | | | | + | |<---------+---200---+ Line 16 + + Figure 2: Forked Call Flow + + The SIP CLF log appears from the vantage point of P2. The fields + logged are shown below; the line numbers refer to Figure 2. + + + + + + + + + +Gurbani, et al. Standards Track [Page 26] + +RFC 6872 SIP CLF February 2013 + + + 1 Timestamp: 1275930743.699 + Message Type: R + Directionality: r + Transport: udp + CSeq-Number: 43 + CSeq-Method: INVITE + R-URI: sip:bob@example.net + Destination-address: 203.0.113.200 + Destination-port: 5060 + Source-address: 198.51.100.1 + Source-port: 5060 + To: sip:bob@example.net + To tag: - + From: sip:alice@example.com + From tag: a1-1 + Call-ID: tr-88h@example.com + Status: - + Server-Txn: s-1-tr + Client-Txn: - + + 2 Timestamp: 1275930744.001 + Message Type: r + Directionality: s + Transport: udp + CSeq-Number: 43 + CSeq-Method: INVITE + R-URI: - + Destination-address: 198.51.100.1 + Destination-port: 5060 + Source-address: 203.0.113.200 + Source-port: 5060 + To: sip:bob@example.net + To tag: - + From: sip:alice@example.com + From tag: a1-1 + Call-ID: tr-88h@example.com + Status: 100 + Server-Txn: s-1-tr + Client-Txn: - + + + + + + + + + + + + +Gurbani, et al. Standards Track [Page 27] + +RFC 6872 SIP CLF February 2013 + + + 3 Timestamp: 1275930744.998 + Message Type: R + Directionality: s + Transport: udp + CSeq-Number: 43 + CSeq-Method: INVITE + R-URI: sip:bob@bob1.example.net + Destination-address: 203.0.113.1 + Destination-port: 5060 + Source-address: 203.0.113.200 + Source-port: 5060 + To: sip:bob@example.net + To tag: - + From: sip:alice@example.com + From tag: a1-1 + Call-ID: tr-88h@example.com + Status: - + Server-Txn: s-1-tr + Client-Txn: c-1-tr + + 4 Timestamp: 1275930745.500 + Message Type: R + Directionality: s + Transport: udp + CSeq-Number: 43 + CSeq-Method: INVITE + R-URI: sip:bob@bob2.example.net + Destination-address: [2001:db8::9] + Destination-port: 5060 + Source-address: 203.0.113.200 + Source-port: 5060 + To: sip:bob@example.net + To tag: - + From: sip:alice@example.com + From tag: a1-1 + Call-ID: tr-88h@example.com + Status: - + Server-Txn: s-1-tr + Client-Txn: c-2-tr + + + + + + + + + + + + +Gurbani, et al. Standards Track [Page 28] + +RFC 6872 SIP CLF February 2013 + + + 5 Timestamp: 1275930745.800 + Message Type: r + Directionality: r + Transport: udp + CSeq-Number: 43 + CSeq-Method: INVITE + R-URI: - + Destination-address: 203.0.113.200 + Destination-port: 5060 + Source-address: 203.0.113.1 + Source-port: 5060 + To: sip:bob@example.net + To tag: b1=-1 + From: sip:alice@example.com + From tag: a1-1 + Call-ID: tr-88h@example.com 100 + Status: 100 + Server-Txn: s-1-tr + Client-Txn: c-1-tr + + 6 Timestamp: 1275930746.100 + Message Type: r + Directionality: r + Transport: udp + CSeq-Number: 43 + CSeq-Method: INVITE + R-URI: - + Destination-address: 203.0.113.200 + Destination-port: udp + Source-address: [2001:db8::9] + Source-port: 5060 + To: sip:bob@example.net + To tag: b2-2 + From: sip:alice@example.com + From tag: a1-1 + Call-ID: tr-88h@example.com + Status: 100 + Server-Txn: s-1-tr + Client-Txn: c-2-tr + + + + + + + + + + + + +Gurbani, et al. Standards Track [Page 29] + +RFC 6872 SIP CLF February 2013 + + + 7 Timestamp: 1275930746.700 + Message Type: r + Directionality: r + Transport: udp + CSeq-Number: 43 + CSeq-Method: INVITE + R-URI: - + Destination-address: 203.0.113.200 + Destination-port: udp + Source-address: [2001:db8::9] + Source-port: 5060 + To: sip:bob@example.net + To tag: b2-2 + From: sip:alice@example.com + From tag: a1-1 + Call-ID: tr-88h@example.com + Status: 180 + Server-Txn: s-1-tr + Client-Txn: c-2-tr + + 8 Timestamp: 1275930746.990 + Message Type: r + Directionality: s + Transport: udp + CSeq-Number: 43 + CSeq-Method: INVITE + R-URI: - + Destination-address: 198.51.100.1 + Destination-port: 5060 + Source-address: 203.0.113.200 + Source-port: 5060 + To: sip:bob@example.net + To tag: b2-2 + From: sip:alice@example.com + From tag: a1-1 + Call-ID: tr-88h@example.com + Status: 180 + Server-Txn: s-1-tr + Client-Txn: c-2-tr + + + + + + + + + + + + +Gurbani, et al. Standards Track [Page 30] + +RFC 6872 SIP CLF February 2013 + + + 9 Timestamp: 1275930747.100 + Message Type: r + Directionality: r + Transport: udp + CSeq-Number: 43 + CSeq-Method: INVITE + R-URI: - + Destination-address: 203.0.113.200 + Destination-port: 5060 + Source-address: 203.0.113.1 + Source-port: 5060 + To: sip:bob@example.net + To tag: b1-1 + From: sip:alice@example.com + From tag: a1-1 + Call-ID: tr-88h@example.com 100 + Status: 180 + Server-Txn: s-1-tr + Client-Txn: c-1-tr + + 10 Timestamp: 1275930747.300 + Message Type: r + Directionality: s + Transport: udp + CSeq-Number: 43 + CSeq-Method: INVITE + R-URI: - + Destination-address: 198.51.100.1 + Destination-port: 5060 + Source-address: 203.0.113.200 + Source-port: 5060 + To: sip:bob@example.net + To tag: b1-1 + From: sip:alice@example.com + From tag: a1-1 + Call-ID: tr-88h@example.com + Status: 180 + Server-Txn: s-1-tr + Client-Txn: c-2-tr + + + + + + + + + + + + +Gurbani, et al. Standards Track [Page 31] + +RFC 6872 SIP CLF February 2013 + + + 11 Timestamp: 1275930747.800 + Message Type: r + Directionality: r + Transport: udp + CSeq-Number: 43 + CSeq-Method: INVITE + R-URI: - + Destination-address: 203.0.113.200 + Destination-port: 5060 + Source-address: 203.0.113.1 + Source-port: 5060 + To: sip:bob@example.net + To tag: b1-1 + From: sip:alice@example.com + From tag: a1-1 + Call-ID: tr-88h@example.com 100 + Status: 200 + Server-Txn: s-1-tr + Client-Txn: c-1-tr + + 12 Timestamp: 1275930748.000 + Message Type: r + Directionality: s + Transport: udp + CSeq-Number: 43 + CSeq-Method: INVITE + R-URI: - + Destination-address: 198.51.100.1 + Destination-port: 5060 + Source-address: 203.0.113.200 + Source-port: 5060 + To: sip:bob@example.net + To tag: b1-1 + From: sip:alice@example.com + From tag: a1-1 + Call-ID: tr-88h@example.com + Status: 200 + Server-Txn: s-1-tr + Client-Txn: c-1-tr + + + + + + + + + + + + +Gurbani, et al. Standards Track [Page 32] + +RFC 6872 SIP CLF February 2013 + + + 13 Timestamp: 1275930748.201 + Message Type: R + Directionality: s + Transport: udp + CSeq-Number: 43 + CSeq-Method: CANCEL + R-URI: sip:bob@bob2.example.net + Destination-address: [2001:db8::9] + Destination-port: 5060 + Source-address: 203.0.113.200 + Source-port: 5060 + To: sip:bob@example.net + To tag: b2-2 + From: sip:alice@example.com + From tag: a1-1 + Call-ID: tr-88h@example.com + Status: - + Server-Txn: s-1-tr + Client-Txn: c-2-tr + + 14 Timestamp: 1275930748.300 + Message Type: r + Directionality: r + Transport: udp + CSeq-Number: 43 + CSeq-Method: INVITE + R-URI: - + Destination-address: 203.0.113.200 + Destination-port: udp + Source-address: [2001:db8::9] + Source-port: 5060 + To: sip:bob@example.net + To tag: b2-2 + From: sip:alice@example.com + From tag: a1-1 + Call-ID: tr-88h@example.com + Status: 487 + Server-Txn: s-1-tr + Client-Txn: c-2-tr + + + + + + + + + + + + +Gurbani, et al. Standards Track [Page 33] + +RFC 6872 SIP CLF February 2013 + + + 15 Timestamp: 1275930748.355 + Message Type: R + Directionality: s + Transport: udp + CSeq-Number: 43 + CSeq-Method: ACK + R-URI: sip:bob@bob2.example.net + Destination-address: [2001:db8::9] + Destination-port: 5060 + Source-address: 203.0.113.200 + Source-port: 5060 + To: sip:bob@example.net + To tag: b2-2 + From: sip:alice@example.com + From tag: a1-1 + Call-ID: tr-88h@example.com + Status: - + Server-Txn: s-1-tr + Client-Txn: c-2-tr + + 16 Timestamp: 1275930748.698 + Message Type: r + Directionality: r + Transport: udp + CSeq-Number: 43 + CSeq-Method: CANCEL + R-URI: - + Destination-address: 203.0.113.200 + Destination-port: udp + Source-address: [2001:db8::9] + Source-port: 5060 + To: sip:bob@example.net + To tag: b2-2 + From: sip:alice@example.com + From tag: a1-1 + Call-ID: tr-88h@example.com + Status: 200 + Server-Txn: s-1-tr + Client-Txn: c-2-tr + + The above SIP CLF log makes it easy to search for a specific + transaction or a state of the session. Searching for the string + "c-1-tr" on the log records will readily yield the information that + an INVITE was sent to sip:bob@bob1.example.com, it elicited a 100 + followed by a 180 and then a 200. Because the ACK request in this + case would be exchanged end-to-end, this element does not see (and + therefore will not log) the ACK. + + + + +Gurbani, et al. Standards Track [Page 34] + +RFC 6872 SIP CLF February 2013 + + + Searching for "c-2-tr" yields a more complex scenario of sending an + INVITE to sip:bob@bob2.example.net, receiving 100 and 180. However, + the log makes it apparent that the request to + sip:bob@bob2.example.net was subsequently CANCEL'ed before a final + response was generated, and that the pending INVITE returned a 487. + The ACK to the final non-2xx response and a 200 to the CANCEL request + complete the exchange on that branch. + +10. Security Considerations + + A log file by its nature reveals both the state of the entity + producing it and the nature of the information being logged. To the + extent that this state should not be publicly accessible and that the + information is to be considered private, appropriate file and + directory permissions attached to the log file SHOULD be used. It is + outside the scope of this document to specify how to protect the log + file while it is stored on disk; however, certain precautions can be + taken. Operators SHOULD consider using common administrative + features such as disk encryption and securing log files [schneier-1]. + Operators SHOULD also consider hardening the machine on which the log + file is stored by restricting physical access to the host as well as + restricting access to the file itself. Depending on the specific + operating system and environment, the file and directory permissions + SHOULD be set to be most restrictive such that the file is not + publicly readable and writable and the directory where the file is + stored is not publicly accessible. + + The following threats may be considered for the log file while it is + stored: + + o An attacker may gain access to view the log file, or may + surreptitiously make a copy of the log file for later viewing. + + o An attacker who is unable to eavesdrop on real-time SIP traffic on + the network, but, nonetheless, can access the log file, is able to + easily mount replay attack or other attacks that result from + channel eavesdropping. Encrypting SIP traffic does not help here + because the SIP entity generating the log file would have + decrypted the message for processing and subsequent logging. + + o An attacker may delete parts of --- or indeed, the whole --- file. + + Public access to the SIP log file creates more of a privacy leak when + compared to an adversary eavesdropping cleartext SIP traffic on the + network. If all SIP traffic on a network segment is encrypted, then + as noted above, special attention must be directed to the file and + directory permissions associated with the log file to preserve + + + + +Gurbani, et al. Standards Track [Page 35] + +RFC 6872 SIP CLF February 2013 + + + privacy such that only a privileged user can access the contents of + the log file. + + Transporting SIP CLF files across the network pose special challenges + as well. The following threats may be considered for transferring + log files or while transferring individual log records: + + o An attacker may view the records; + + o An attacker may modify the records in transit or insert previously + captured records into the stream; + + o An attacker may remove records in transit, or may stage a man-in- + the-middle attack to deliver a partially or entirely falsified log + file. + + It is also outside the scope of this document to specify protection + methods for log files or log records that are being transferred + between hosts; however, certain precautions can be taken. Operators + SHOULD require mutual authentication, channel confidentiality, and + channel integrity while transferring the log file. The use of a + secure shell transport layer protocol [RFC4253] or TLS [RFC5246] + accomplishes this. + + Even with such care, sensitive information can be leaked during or + after the transfer. SIP CLF fields like IP addresses and URIs + contain potentially sensitive information. Before transferring the + log file across domains, operators SHOULD ensure that any fields that + contain sensitive information are appropriately anonymized or + obfuscated. A specification for a format that describes which fields + are obfuscated and with what characteristics (e.g., what correlations + still work) is needed to allow interoperable but privacy-friendly + exchange of SIP CLF between administrative domains. Such a + specification is not attempted here, but is for further study. + + The SIP CLF represents the minimum fields that lend themselves to + trend analysis and serve as information that may be deemed useful. + Other formats can be defined that include more headers (and the body) + from Section 8.1. However, where to draw a judicial line regarding + the inclusion of non-mandatory headers can be challenging. Clearly, + the more information a SIP entity logs, the longer time the logging + process will take, the more disk space the log entry will consume, + and the more potentially sensitive information could be breached. + Therefore, adequate trade-offs should be taken in account when + logging more fields than the ones recommended in Section 8.1. + + + + + + +Gurbani, et al. Standards Track [Page 36] + +RFC 6872 SIP CLF February 2013 + + + Implementers need to pay particular attention to buffer handling when + reading or writing log files. SIP CLF entries can be unbounded in + length. It would be reasonable for a full dump of a SIP message to + be thousands of octets long. This is of particular importance to CLF + log parsers, as a SIP CLF log writers may add one or more extension + fields to the message to be logged. + +11. Operational Guidance + + SIP CLF log files will take up a substantial amount of disk space + depending on traffic volume at a processing entity and the amount of + information being logged. As such, any organization using SIP CLF + should establish operational procedures for file rollovers and + periodic retrieval of logs before rollover as appropriate to the + needs of the organization. + + Listing such operational guidelines in this document is out of scope + for this work. + +12. Acknowledgments + + Members of the sipping, dispatch, ipfix, and syslog working groups + provided invaluable input to the formulation of the document. These + include Benoit Claise, Spencer Dawkins, John Elwell, David + Harrington, Christer Holmberg, Hadriel Kaplan, Atsushi Kobayashi, + Jiri Kuthan, Scott Lawrence, Chris Lonvick, Peter Musgrave, Simon + Perreault, Adam Roach, Dan Romascanu, Robert Sparks, Brian Trammell, + Dale Worley, Theo Zourzouvillys, and others that we have undoubtedly, + but inadvertently, missed. + + Rainer Gerhards, David Harrington, Cullen Jennings, and Gonzalo + Salgueiro helped tremendously in discussions related to arriving at + the beginnings of an information model. + +13. References + +13.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, + A., Peterson, J., Sparks, R., Handley, M., and E. + Schooler, "SIP: Session Initiation Protocol", RFC 3261, + June 2002. + + + + + + +Gurbani, et al. Standards Track [Page 37] + +RFC 6872 SIP CLF February 2013 + + +13.2. Informative References + + [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) + Transport Layer Protocol", RFC 4253, January 2006. + + [RFC5101] Claise, B., "Specification of the IP Flow Information + Export (IPFIX) Protocol for the Exchange of IP Traffic + Flow Information", RFC 5101, January 2008. + + [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.2", RFC 5246, August 2008. + + [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. + + [RFC6873] Salgueiro, G., Gurbani, V., and A. B. Roach, "Format for + the Session Initiation Protocol (SIP) Common Log Format + (CLF)", RFC 6873, February 2013. + + [rieck2008] + Rieck, K., Wahl, S., Laskov, P., Domschitz, P., and K-R. + Muller, "A Self-learning System for Detection of Anomalous + SIP Messages", Principles, Systems and Applications of IP + Telecommunications Services and Security for Next + Generation Networks (IPTComm), LNCS 5310, pp. 90-106, + 2008. + + [schneier-1] + Schneier, B. and J. Kelsey, "Secure audit logs to support + computer forensics", ACM Transactions on Information and + System Security (TISSEC), 2(2), pp. 159,176, May 1999. + + + + + + + + + + + + + + + + + + + + + +Gurbani, et al. Standards Track [Page 38] + +RFC 6872 SIP CLF February 2013 + + +Authors' Addresses + + Vijay K. Gurbani (editor) + Bell Laboratories, Alcatel-Lucent + 1960 Lucent Lane + Naperville, IL 60566 + USA + + EMail: vkg@bell-labs.com + + + Eric W. Burger (editor) + Georgetown University + USA + + EMail: eburger@standardstrack.com + URI: http://www.standardstrack.com + + + Tricha Anjali + Illinois Institute of Technology + 316 Siegel Hall + Chicago, IL 60616 + USA + + EMail: tricha@ece.iit.edu + + + Humberto Abdelnur + INRIA + INRIA - Nancy Grant Est + Campus Scientifique + 54506, Vandoeuvre-les-Nancy Cedex + France + + EMail: humbol@gmail.com + + + Olivier Festor + INRIA + INRIA - Nancy Grant Est + Campus Scientifique + 54506, Vandoeuvre-les-Nancy Cedex + France + + EMail: Olivier.Festor@loria.fr + + + + + +Gurbani, et al. Standards Track [Page 39] + -- cgit v1.2.3