GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6872

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6872.txt · Last modified: 2013/02/14 21:53 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki