[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

SIPPING                                                       V. Gurbani
Internet-Draft                         Bell Laboratories, Alcatel-Lucent
Intended status: Informational                                 E. Burger
Expires: September 10, 2009                          This Space for Sale
                                                               T. Anjali
                                        Illinois Institute of Technology
                                                             H. Abdelnur
                                                               O. Festor
                                                                   INRIA
                                                           March 9, 2009


  The Common Log File (CLF) format for the Session Initiation Protocol
                                 (SIP)
                      draft-gurbani-sipping-clf-01

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 10, 2009.

Copyright Notice

   Copyright (c) 2009 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 in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights



Gurbani, et al.        Expires September 10, 2009               [Page 1]


Internet-Draft                   SIP CLF                      March 2009


   and restrictions with respect to this document.

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 trouble-shooting 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 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.  We propose a common log file format
   for SIP servers that can be used uniformly for proxies, registrars,
   redirect servers as well as back-to-back user agents.


































Gurbani, et al.        Expires September 10, 2009               [Page 2]


Internet-Draft                   SIP CLF                      March 2009


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Relationship between SIP CLF and Call Detail Record  . . . . .  6
   4.  CLF Format . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     4.1.  ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     4.2.  Data Elements  . . . . . . . . . . . . . . . . . . . . . .  7
     4.3.  Request CLF  . . . . . . . . . . . . . . . . . . . . . . .  9
     4.4.  Response CLF . . . . . . . . . . . . . . . . . . . . . . .  9
   5.  A CLF for SIP Servers  . . . . . . . . . . . . . . . . . . . . 10
   6.  Proxy Servers and B2BUA Correlation Directives . . . . . . . . 13
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 17
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 17
     10.2. Informative References . . . . . . . . . . . . . . . . . . 17
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
































Gurbani, et al.        Expires September 10, 2009               [Page 3]


Internet-Draft                   SIP CLF                      March 2009


1.  Introduction

   Well-known web servers such as Apache and 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.

   The Session Initiation Protocol [1](SIP) is an Internet multimedia
   session signaling protocol that is increasingly used for other
   services besides session establishment.  SIP does not have a CLF
   today.

   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:
   o  Allows for a common reference for interpreting the state of SIP
      transactions in SIP servers across multiple vendor implementations
      and open-source alternatives.
   o  Allows 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 [3].  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.
   o  Allows independent tool providers to craft tools and applications
      that interpret the CLF data to produce insightful trend analysis
      and detailed traffic reports.
   o  Allows for automatic testing of SIP equipment and establishing a
      concise and standardized diagnostic trail of a SIP session.

   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,



Gurbani, et al.        Expires September 10, 2009               [Page 4]


Internet-Draft                   SIP CLF                      March 2009


   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, and 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 wait at a proxy as it forks branches downstream or at a
   user agent server while it alerts the user.  RFC 3261 [1] instructs
   the server transaction to send a 1xx-class provisional response if a
   final response is delayed for more than 200 ms.  A SIP SLF 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 (UAS), it is
   beneficial to derive a CLF format that supports back-to-back user
   agent (B2BUA) behavior, which may vary considerably depending on the
   specific nature of the B2BUA.


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 [2].

   RFC 3261 [1] 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



Gurbani, et al.        Expires September 10, 2009               [Page 5]


Internet-Draft                   SIP CLF                      March 2009


   the role of a user agent server.


3.  Relationship between SIP CLF and Call Detail Record

   With the success of SIP in traditional telephony domains, it is
   tempting to think of the SIP CLF as a replacement for call logs and
   Call Detail Records (CDRs).  However, this is expressly not our
   intent.  The charging system of a telephone exchange produces a CDR.
   Insofar as a SIP entity is acting as a telephone exchange, it can
   continue producing CDR irrespective of whether it also produces a SIP
   CLF.

   A SIP CLF is a standardized text file format used by SIP Servers,
   proxies, and B2BUAs.  A SIP CLF is simply an easily digestible log of
   past and current transactions.  It contains enough information to
   allow humans and automata to derive relationships between discrete
   transactions handled at a SIP entity.  It is amenable to quick
   parsing (i.e., well-delimited fields) and it is platform and
   operating system neutral.


4.  CLF Format

   The inspiration for the SIP CLF format is the Apache CLF.  The
   structure of the Apache CLF, including the format string that appears
   in the Apache configuration file, is as follows.

             %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.








Gurbani, et al.        Expires September 10, 2009               [Page 6]


Internet-Draft                   SIP CLF                      March 2009


   bytes:  The content-length of the document transferred.


   Section 5 outlines the SIP CLF.  Section 6 contains additional
   logging data elements that correlate forked transactions in proxies
   or similar transactions at a B2BUA that require correlation.

   While based on the Apache CLF, the SIP CLF does not use the RFC 931
   [4] identification service.  RFC 931 and its successor, RFC 1413 [5],
   provide the identity of a user associated with a particular TCP
   connection.  Such a service does not work for SIP because SIP runs
   over multiple transports.  More importantly, in today's networks,
   firewalls often block access to port 113 (decimal), the port
   associated with the identification service, rendering it completely
   useless.

   While this document defines the log string in terms of parameter
   strings (the "%" tokens), this is done in order to facilitate the
   subsequent discussion only.  More specifically, these format strings
   allow us to describe the format of the SIP CLF file, they must not be
   used as log configuration strings for individual SIP servers.  The
   definitions in this document for a log file line are the only
   definition for SIP CLF records.

4.1.  ABNF

      NB: The ABNF below is not formal, nor is it completely closed-end.
      At this point, we would like to write the data elements down and
      produce the formal BNF corresponding to them in the next revision.

      sip-clf = request-clf / response-clf
      request-clf = %d %h %u %m %r %f %t %i "%c" %x %y [delim extension]
      response-clf = %d %x %y %s %m %t "%c" [delim extension]
      delim = "--"
      extension = to be defined (other headers) / message-body

      Notes:
      message-body is defined in RFC3261.
      %m in response-clf was added in individual submission -01
         because we need it to differentiate the response of a CANCEL
         from that of an INVITE.  Both CANCELs and INVITEs will have
         the same %x value.

4.2.  Data Elements







Gurbani, et al.        Expires September 10, 2009               [Page 7]


Internet-Draft                   SIP CLF                      March 2009


   date (%d):  Date and time of the request as the number of seconds
      since the Unix epoch.  [Note 1]

   remotehost (%h):  The DNS name or IP address of the upstream client.

   authuser (%u):  The user name by which the user has been
      authenticated.  If the user name is unknown or when a request is
      challenged, the value in this field MUST be "-" [Note 2].

   method (%m):  The name of the SIP method.  MUST appear in upper-case
      in the log file.

   request-uri (%r):  The Request-URI, including any URI parameters.

   from (%f):  The From URI, including the tag.  Whilst one may question
      the value of the From URI in light of RFC 4474 [6], the From URI,
      nonetheless, imparts some information.  For one, the From tag is
      important and, in the case of a REGISTER request, the From URI can
      provide information on whether this was a third-party registration
      or a first-party one [Note 3].

   to (%t):  The To URI, including the tag.

   callid (%i):  The Call-ID value.

   status (%s):  The SIP response status code returned upstream.

   contactlist (%c):  Contact URIs in the response, if any.  If there
      are no Contact URIs, the SIP Server MUST log a "-" for the
      contactlist.  If there are multiple URIs, the SIP Server MUST
      delimit the list of URIs by a commas (,) [Note 4].

   server transaction association code(%x):  The transaction identifier
      associated with the server transaction.  Implementations MAY reuse
      the server transaction identifier (the topmost branch-id of the
      incoming request, with or without the magic cookie), or they MAY
      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 will be
      explained in Section 6.

   client transaction association code (%y):  This field is used to
      associate client transactions with a server transaction for
      forking proxies or B2BUAs.  It is explained further in Section 6.






Gurbani, et al.        Expires September 10, 2009               [Page 8]


Internet-Draft                   SIP CLF                      March 2009


   [Note 1]  Do we need sub-second resolution?  A simple solution is to
             go date.mmm, where mmm is the time in milliseconds.
             Thoughts?
   [Note 2]  The realm is not specified here.  HTTP CLF does not specify
             it either, but that does not mean that we cannot do better.
             Should we?  Thoughts...
   [Note 3]  Go with addr-spec in ABNF here and handle the tag, which is
             actually a header parameter and not a URI parameter.
   [Note 4]  Dale pointed out that quotes to delimit Contact may not be
             adequate because name-addr can contain a quote.  Coming up
             with delimiters for Contact is as yet an open issue.

   If a field is not applicable to the event, or if the SIP Server does
   not know the value of the field, the SIP Server MUST use the field
   value "-", without the quotes.  If the field value in a current event
   is identical to a field value from a prior event with the same server
   transaction identifier, the SIP Server MAY use a "+", without the
   quotes, as the field value to indicate such repetition.  The SIP
   Server MUST NOT use a "+" for the date or server transaction fields.

4.3.  Request CLF

   SIP Servers generating a SIP CLF log for a SIP request MUST follow
   the format string in the following figure.  A SIP CLF log entry for a
   SIP request MUST have these 11 fields in the order listed below.  A
   SIP Server MAY add additional fields after these 12 fields.

           %d %h %u %m %r %f %t %i "%c" %x %y

4.4.  Response CLF

   SIP Servers generating a SIP CLF log for a response event MUST follow
   the format string in the following figure.  A SIP CLF log entry for a
   response event MUST have these five fields in the order listed below.
   The server transaction (%x) field MUST be present.  This allows the
   automata or observer monitoring the log file to correlate late
   responses with pending transactions.  This construct is also used in
   Section 6 to associate responses arriving on client transactions and
   responses being sent on a server transaction in case of a forking
   proxy or a B2BUA.

           %d %x %y %s %m %t "%c"


   The To header (%t) is part of the response CLF because it contains
   the tag associated with the recipient of the request; this tag, in
   turn, is used to identify a dialog.




Gurbani, et al.        Expires September 10, 2009               [Page 9]


Internet-Draft                   SIP CLF                      March 2009



      TODO: Should we just put the To-tag here instead of the whole URI?


5.  A CLF for SIP Servers

   A SIP CLF record MUST occupy one physical line in the log file.  A
   line is a string of octets terminated by a CRLF.

   A SIP CLF record MUST conform to the patterns described in
   Section 4.3 and Section 4.4.  A SIP CLF record may have other fields
   appended to the patterns described here.

   A SIP CLF record for SIP Servers MUST contain exactly one request CLF
   line (Section 4.3) and one or more corresponding response lines
   (Section 4.4).  A SIP CLF record for the ACK request MUST NOT contain
   any corresponding response lines (Section 4.4).

   Illustrative examples of the SIP CLF follow.  These examples use the
   <allOneLine> tag defined in RFC 4475 [7] to logically denote a single
   line.

   In the following example, Alice is registering herself with her
   domain's registrar and is challenged for HTTP Digest:

     <allOneLine>
     1230756550 192.168.1.2 - REGISTER sip:example.com
     sip:alice@example.com;tag=iu8u76 sip:alice@example.com
     8719u@example.com - hgt678h -
     </allOneLine>

     1230756550 hgt678h - 401 REGISTER sip:alice@example.com;tag=8hy -

   In this example, Alice has successfully authenticated herself with
   her registrar.  The information logged contains her authorized
   identity as well as the list of Contact URIs that were registered.
   Note that the last two fields are not populated because there is no
   need to maintain further state about this REGISTER transaction:













Gurbani, et al.        Expires September 10, 2009              [Page 10]


Internet-Draft                   SIP CLF                      March 2009


     <allOneLine>
     1230756560 192.168.1.2 alice REGISTER sip:example.com
     sip:alice@example.com;tag=iu8u76 sip:alice@example.com;tag=yh78
     8719u@example.com
     "<sip:alice@lab.example.com>;q=0.7;expires=7200,
     <sip:alice@home.example.net>;q=0.5;expires=3600"
     hgt679h -
     </allOneLine>

     <allOneLine>
     1230756550 hgt679h - 200 REGISTER +
     "<sip:alice@lab.example.com>;q=0.7;expires=7200,
     <sip:alice@home.example.net>;q=0.5;expires=3600"
     </allOneLine>


   The next example shows a log file entry from Alice's UAS when it
   received a MESSAGE request from Bob and responded to it using a 2xx-
   class response:


     <allOneLine>
     1230756560 192.168.1.10 - MESSAGE sip:alice@example.com
     sip:alice@example.com;tag=jki7 sip:bob@example.net
     7y16@example.net - 76gr56 -
     </allOneLine>

     1230756560 76gr56 - 200 MESSAGE sip:bob@example.net;tag=8uy -

   This example shows a log file entry from Bob's UAS that responded to
   a 3xx-class response to Alice's session invitation request.  Of
   interest here is the third line that contains an ACK request received
   by Bob's UAS for the INVITE transaction.  See that the %x field of
   both the log entries match, thereby confirming correlation.  Since
   this is an ACK request corresponding to an existing INVITE
   transaction, critical information like To, From, Call-ID, etc. remain
   the same.  Thus to save I/O and log file space, the implementation
   chose to abbreviate the repeated fields with the "+" entries.













Gurbani, et al.        Expires September 10, 2009              [Page 11]


Internet-Draft                   SIP CLF                      March 2009


     <allOneLine>
     1230756560 192.168.1.10 - INVITE sip:bob@example.net
     sip:alice@example.com;tag=iu8u76 sip:bob@example.net
     i98ju@example.com - y6y78u -
     </allOneLine>

     <allOneLine>
     1230756560 y6y78u - 302 INVITE sip:bob@example.net;tag=yh78
     "<sip:bob@home.example.net>"
     </allOneLine>

     1230756560 192.168.1.10 - ACK + + + + + y6y78u -

   The next few examples demonstrate the more complex scenarios
   corresponding to handling CANCELs and sending delayed responses
   upstream.

   In this example, Bob contacts Alice; Alice's UAS has sent a 180
   upstream but has not generated a final response yet.  Before Alice
   has a chance to pick up the phone, Bob hangs up causing a CANCEL to
   arrive at Alice's UAS.  Alice's UAS processes the CANCEL, sending a
   200 OK (CANCEL), followed by sending a 487 (INVITE) and receiving an
   ACK:

     <allOneLine>
     1230756560 192.168.1.10 - INVITE sip:bob@example.net
     sip:alice@example.com;tag=iu8u76 sip:bob@example.net
     i98ju@example.com "<sip:bob@home.example.net>" y6y78u -
     </allOneLine>

     1230756560 y6y78u - 100 INVITE sip:bob@example.net;tag=yh78 -
     1230756560 y6y78u - 180 INVITE + -
     1230756561 192.168.1.10 - CANCEL + + + + - y6y78u -
     1230756560 y6y78u - 200 CANCEL + -
     1230756561 y6y78u - 487 INVITE sip:bob@example.net;tag=yh78 -
     1230756561 192.168.1.10 - ACK + + + + + y6y78u -

   The following example demonstrates a session being queued and finally
   answered by the UAS:












Gurbani, et al.        Expires September 10, 2009              [Page 12]


Internet-Draft                   SIP CLF                      March 2009


     <allOneLine>
     1230756560 192.168.1.10 - INVITE sip:agent@acd.example.net
     sip:alice@example.com;tag=iu8u76 sip:agent@acd.example.net
     i98ju@example.com - z9hG4bk7yt6 -
     </allOneLine>
     <allOneLine>
     1230756560 z9hG4bk7yt6 - 100 INVITE
     sip:agent@acd.example.net;tag=oi8 -
     </allOneLine>
     1230756560 z9hG4bk7yt6 - 180 INVITE + -
     1230756561 z9hG4bk7yt6 - 182 INVITE + -
     1230756564 z9hG4bk7yt6 - 182 INVITE + -
     1230756565 z9hG4bk7yt6 - 183 INVITE + -
     1230756566 z9hG4bk7yt6 - 200 INVITE + -
     1230756566 192.168.1.10 - ACK + + + + - z9hG4bk7yt6 -

   Note that the CLF format is designed such that using the server
   transaction in a regular expression search will yield a filtered
   result containing all pertinent entries to that server transaction.
   This allows the human observer to sift through the file ex post facto
   to recreate the transaction state or to train anomaly detection
   automata with a pertinent data set.


6.  Proxy Servers and B2BUA Correlation Directives

   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.

   We present the correlation directives below.  They are best expressed
   through an example call flow described next.

   Let us assume that Bob is running a call-stateful proxy.  Alice
   decides to establish a session with Bob through his proxy.  Bob's
   proxy does a location lookup and decides to fork the request
   downstream to two destinations.  Of these two destinations, one
   generates a 500-class response while the other generates a 200-class
   response.  Bob's proxy sends an ACK on the branch corresponding to
   the 500-class response and sends the 200-class one upstream.  Since
   it is call stateful, it will receive an ACK and proxy it downstream.

   First, Bob's proxy receives a request from Alice.  Bob's proxy
   creates a server transaction in the log file and sends a 100



Gurbani, et al.        Expires September 10, 2009              [Page 13]


Internet-Draft                   SIP CLF                      March 2009


   upstream:

     <allOneLine>
     1230756560 192.168.1.10 - INVITE sip:bob@example.net
     sip:alice@example.com;tag=hy7 sip:bob@example.net
     7yhgt1@example.com - uyt67h FORK/-
     </allOneLine>

     1230756560 uyt67h - 100 INVITE + -

   Note the last column in the request CLF line: "FORK/-".  This entry
   is the client transaction association code (%y) that the SIP CLF uses
   to track client transactions.  The format of this field is
   "directive/client-transaction-id".  Directive is either "FORK" or
   "CLIENT".  The server transaction of a proxy or a B2BUA uses "FORK".
   The client transaction uses "CLIENT".  When a server transaction
   forks, and in this document we consider it forking even if the proxy
   forwards the request to a single downstream destination, the value of
   %y MUST be "FORK/-".

   The client-transaction-id portion of the %y field is an
   identification string unique to each client transaction sent
   downstream.  Implementations SHOULD reuse the branch-id value created
   for the client transaction, with our without the magic cookie.  The
   implementation MAY generate a unique identification string to serve
   as a client transaction identifier.  Such an identification string
   MUST be unique at that server.

   As each client transaction is created and activated, it will be
   reflected in the log file.  There is another idiosyncrasy that needs
   to be accommodated, however.  Because it may take some time for a
   downstream UAS to elicit a response once contacted, the proxy or
   B2BUA MUST insert a log file entry when the client transaction
   reaches the "Proceeding" state upon the receipt of a provisional
   response.  The next two lines demonstrate that a response each was
   elicited from two forked branches:

    <allOneLine>
    1230756563 - - INVITE sip:bob@home.example.net
    sip:alice@example.com;tag=hy7 sip:bob@example.net
    7yhgt1@example.com - uyt67h CLIENT/hb76
    </allOneLine>
    <allOneLine>
    1230756564 - - INVITE sip:bob@carphone.example.net
    sip:alice@example.com;tag=hy7 sip:bob@example.net
    7yhgt1@example.com - uyt67h CLIENT/hb77
    </allOneLine>




Gurbani, et al.        Expires September 10, 2009              [Page 14]


Internet-Draft                   SIP CLF                      March 2009


   Note that each log file entry for a client transaction contains the
   CLIENT code and the corresponding client-transaction-id value ("hb76"
   and "hb77" in the above example.)

   The forked branches return multiple provisional responses followed by
   a final response on each branch.

    1230756565 uyt67h hb76 100 INVITE sip:bob@example.net;tag=876v -
    1230756565 uyt67h hb77 100 INVITE sip:bob@example.net;tag=561t -
    1230756565 uyt67h hb76 180 INVITE sip:bob@example.net;tag=876v -
    1230756565 uyt67h hb77 180 INVITE sip:bob@example.net;tag=561t -
    1230756567 uyt67h hb77 182 INVITE sip:bob@example.net;tag=561t -
    1230756568 uyt67h hb76 500 INVITE sip:bob@example.net;tag=876v -
    <allOneLine>
    1230756568 uyt67h hb77 200 INVITE sip:bob@example.net;tag=561t
    "sip:bob@home.example.net"
    </allOneLine>

   Bob's proxy will aggregate these responses and sends the best
   response (200) upstream and sends an ACK to the branch that returned
   a 5xx-class response:

     <allOneLine>
     1230756569 uyt67h - 200 INVITE sip:bob@example.net;tag=561t
     "sip:bob@home.example.net"
     </allOneLine>
     <allOneLine>
     1230756569 + - ACK sip:bob@home.example.net + + + - uyt67h
     CLIENT/hb76
     </allOneLine>

   Because it is a stateful proxy, it receives an ACK from the upstream
   client.  It now has to create a client transaction to send this ACK
   downstream:

    <allOneLine>
    1230756570 192.168.1.10 - ACK sip:bob@home.example.net
    sip:alice@example.com;tag=hy7 sip:bob@example.net;tag=76y
    7yhgt1@example.com - t6y5 FORK/-
    </allOneLine>
    <allOneLine>
    1230756570 - - ACK sip:bob@home.example.net
    sip:alice@example.com;tag=hy7 sip:bob@example.net;tag=76y
    7yhgt1@example.com - t6y5 CLIENT/hb89
    </allOneLine>

   The SIP CLF format string includes the minimum set of headers that,
   we believe, lend themselves to trend analysis and serve as



Gurbani, et al.        Expires September 10, 2009              [Page 15]


Internet-Draft                   SIP CLF                      March 2009


   information that may be deemed useful.  The inclusion of the To and
   From tags and the Call-ID as part of the format string allows
   automata to correlate later transactions to earlier ones, while the
   addition of the correlation directives similarly allows automata to
   associate an outgoing transaction with an existing one.


7.  Security Considerations

   A log file by its nature reveals the 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.  In
   the worst case, public access to the SIP log file provides the same
   information that an adversary can gain using network sniffing tools
   (assuming that the SIP traffic is in clear text.)  If all SIP traffic
   on a network segment is encrypted, then special attention MUST be
   directed to the file and directory permissions associated with the
   log file to preserve privacy such that only a privileged user can
   access the contents of the log file.

   The SIP CLF format string includes the minimum set of headers that,
   we believe, 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 4.2.  However,
   where to draw a judicial line regarding the inclusion of non-
   mandatory headers can be challenging.  Clearly, the more information
   a SIP server 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
   tradeoffs should be taken in account when creating a format string
   that logs more header fields than the ones recommended by the CLF
   format string.

   We believe that a SIP CLF format will aid in network and situational
   security.  Such a format could be integrated into MITRE's Common
   Event Expression ( CEE [8]) system, which could monitor the SIP CLF
   log file to produce CEE events that are fed into a detection system
   using CEE's common log transport and syntax.  It is also possible to
   imagine a wrapper that takes data from a standard SIP CLF and turns
   it into an IDMEF-expressible syntax.  RFC 4765 [9] defines IDMEF,
   which are the data formats and exchange procedures for sharing
   information of interest to intrusion detection and response systems
   and to the management systems that may need to interact with them.

   Implementers need to pay particular attention to buffer handling when
   reading or writing log files.  SIP CLF entries can be unbounded in



Gurbani, et al.        Expires September 10, 2009              [Page 16]


Internet-Draft                   SIP CLF                      March 2009


   length.  It would be reasonable for a full body dump to be thousands
   of octets long.  This is of particular importance to CLF log parsers,
   as conforming SIP CLF log writers are free to add fields to the
   mandatory fields described in this document.


8.  IANA Considerations

   This document does not require any considerations from IANA.


9.  Acknowledgments

   A big debt of gratitude to Dale Worley for a very close read of the
   draft and many excellent suggestions to the text.  Hadriel Kaplan and
   Robert Sparks provided additional comments.


10.  References

10.1.  Normative References

   [1]  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.

   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

10.2.  Informative References

   [3]  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.

   [4]  St. Johns, M., "Authentication server", RFC 931, January 1985.

   [5]  St. Johns, M., "Identification Protocol", RFC 1413,
        February 1993.

   [6]  Peterson, J. and C. Jennings, "Enhancements for Authenticated
        Identity Management in the Session Initiation Protocol (SIP)",
        RFC 4474, August 2006.

   [7]  Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J., and H.



Gurbani, et al.        Expires September 10, 2009              [Page 17]


Internet-Draft                   SIP CLF                      March 2009


        Schulzrinne, "Session Initiation Protocol (SIP) Torture Test
        Messages", RFC 4475, May 2006.

   [8]  Mitre Corporation, "Common Event Expression",
        <http://cee.mitre.org/>.

   [9]  Debar, H., Curry, D., and B. Feinstein, "The Intrusion Detection
        Message Exchange Format (IDMEF)", RFC 4765, March 2007.


Authors' Addresses

   Vijay K. Gurbani
   Bell Laboratories, Alcatel-Lucent
   1960 Lucent Lane
   Naperville, IL  60566
   USA

   Email: vkg@alcatel-lucent.com


   Eric W. Burger
   This Space for Sale
   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: Humberto.Abdelnur@loria.fr





Gurbani, et al.        Expires September 10, 2009              [Page 18]


Internet-Draft                   SIP CLF                      March 2009


   Olivier Festor
   INRIA
   INRIA - Nancy Grant Est
   Campus Scientifique
   54506, Vandoeuvre-les-Nancy Cedex
   France

   Email: Olivier.Festor@loria.fr











































Gurbani, et al.        Expires September 10, 2009              [Page 19]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/