Internet DRAFT - draft-ietf-sipclf-problem-statement
draft-ietf-sipclf-problem-statement
SIPCLF V. Gurbani, Ed.
Internet-Draft Bell Laboratories, Alcatel-Lucent
Intended status: Standards Track E. Burger, Ed.
Expires: July 7, 2013 Georgetown University
T. Anjali
Illinois Institute of Technology
H. Abdelnur
O. Festor
INRIA
January 3, 2013
The Common Log Format (CLF) for the Session Initiation Protocol (SIP):
Framework and Information Model
draft-ietf-sipclf-problem-statement-13
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 (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, redirect servers as well as back-to-back user
agents.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
Gurbani, et al. Expires July 7, 2013 [Page 1]
Internet-Draft SIP CLF January 2013
material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 7, 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.
Gurbani, et al. Expires July 7, 2013 [Page 2]
Internet-Draft SIP CLF January 2013
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problem statement . . . . . . . . . . . . . . . . . . . . . . 5
4. What SIP CLF is and what it is not . . . . . . . . . . . . . . 6
5. Alternative approaches to SIP CLF . . . . . . . . . . . . . . 6
5.1. SIP CLF and Call Detail Records . . . . . . . . . . . . . 7
5.2. SIP CLF and packet capture tools . . . . . . . . . . . . . 7
5.3. SIP CLF and syslog . . . . . . . . . . . . . . . . . . . . 8
5.4. SIP CLF and IPFIX . . . . . . . . . . . . . . . . . . . . 9
6. Motivation and use cases . . . . . . . . . . . . . . . . . . . 9
7. Challenges in establishing a SIP CLF . . . . . . . . . . . . . 11
8. Information model . . . . . . . . . . . . . . . . . . . . . . 12
8.1. SIP CLF mandatory fields . . . . . . . . . . . . . . . . . 12
8.2. Mandatory fields and SIP entities . . . . . . . . . . . . 14
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. UAC registration . . . . . . . . . . . . . . . . . . . . . 16
9.2. Direct call between Alice and Bob . . . . . . . . . . . . 17
9.3. Single downstream branch call . . . . . . . . . . . . . . 19
9.4. Forked call . . . . . . . . . . . . . . . . . . . . . . . 24
10. Security Considerations . . . . . . . . . . . . . . . . . . . 32
11. Operational guidance . . . . . . . . . . . . . . . . . . . . . 34
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
14.1. Normative References . . . . . . . . . . . . . . . . . . . 35
14.2. Informative References . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
Gurbani, et al. Expires July 7, 2013 [Page 3]
Internet-Draft SIP CLF January 2013
1. 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.
2. 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 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 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.
Gurbani, et al. Expires July 7, 2013 [Page 4]
Internet-Draft SIP CLF January 2013
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 a 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
SIP CLF record and instead, allows other documents to define a
representation format. [I-D.ietf-sipclf-format] is an example of a
representation format that provides an UTF-8 based logging scheme.
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 criteria. 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
Gurbani, et al. Expires July 7, 2013 [Page 5]
Internet-Draft SIP CLF January 2013
platforms and operating environments where a SIP entity generating a
log file record may be found.
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.
And finally, the SIP CLF is not a tool for supporting lawful
intercept.
5. Alternative approaches to SIP CLF
The 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
Gurbani, et al. Expires July 7, 2013 [Page 6]
Internet-Draft SIP CLF January 2013
information model contained in this document can be used to develop
alternative representation formats when desired. Currently,
[I-D.ietf-sipclf-format] is an example of a representation format
that provides an UTF-8 based logging scheme that meets all the
requirements of Section 3.
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 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.
One, 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 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.
Two, 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 light- weight 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 VoIP
networks. Universities, research laboratories, and small-to-medium
size companies are deploying SIP-based VoIP solutions on networks
owned and managed by them. Much 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
Gurbani, et al. Expires July 7, 2013 [Page 7]
Internet-Draft SIP CLF January 2013
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:
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 require that the underlying libraries
related to packet capture be available for all platforms on which
a SIP server or a SIP client can execute on. Given the different
platforms that a SIP client or server runs on --- 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 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
that the SIP server or the SIP client can execute on. And finally,
Gurbani, et al. Expires July 7, 2013 [Page 8]
Internet-Draft SIP CLF January 2013
because of the frequency and size of SIP log messages, it is not
desirable to 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 IPFIX protcol [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.
Gurbani, et al. Expires July 7, 2013 [Page 9]
Internet-Draft SIP CLF January 2013
Note that tracing the request through a set of servers is
considerably less challenging if all the servers belong to the
same administrative domain.
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 trouble shooting 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.
Gurbani, et al. Expires July 7, 2013 [Page 10]
Internet-Draft SIP CLF January 2013
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.
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, 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 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 (UAS), it is
beneficial to derive a common log format that supports back-to-back
user agent (B2BUA) behavior, which may vary considerably depending on
Gurbani, et al. Expires July 7, 2013 [Page 11]
Internet-Draft SIP CLF January 2013
the specific nature of the B2BUA.
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, logging bodies requires understanding tradeoffs
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 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 on whether the SIP message is a request
or a response. The allowable values for this field are 'R' (for
Request) and 'r' (for response).
Gurbani, et al. Expires July 7, 2013 [Page 12]
Internet-Draft SIP CLF January 2013
Directionality - An indicator on 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).
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 RFC3261
[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
Gurbani, et al. Expires July 7, 2013 [Page 13]
Internet-Draft SIP CLF January 2013
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.
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, a 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 instance 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
Gurbani, et al. Expires July 7, 2013 [Page 14]
Internet-Draft SIP CLF January 2013
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
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 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. Expires July 7, 2013 [Page 15]
Internet-Draft SIP CLF January 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 asignment
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
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.
Gurbani, et al. Expires July 7, 2013 [Page 16]
Internet-Draft SIP CLF January 2013
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
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: -
Gurbani, et al. Expires July 7, 2013 [Page 17]
Internet-Draft SIP CLF January 2013
Client-Txn: c-1-xt6
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
Timestamp: 1275930746.120
Message Type: R
Directionality: s
Transport: udp
CSeq-Number: 32
CSeq-Method: ACK
Gurbani, et al. Expires July 7, 2013 [Page 18]
Internet-Draft SIP CLF January 2013
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
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. Expires July 7, 2013 [Page 19]
Internet-Draft SIP CLF January 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: -
In line 3 below, P1 has created a client transaction identification
Gurbani, et al. Expires July 7, 2013 [Page 20]
Internet-Draft SIP CLF January 2013
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
5 Timestamp: 1275930745.800
Message Type: r
Directionality: r
Transport: udp
CSeq-Number: 43
Gurbani, et al. Expires July 7, 2013 [Page 21]
Internet-Draft SIP CLF January 2013
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
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
Gurbani, et al. Expires July 7, 2013 [Page 22]
Internet-Draft SIP CLF January 2013
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
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
Gurbani, et al. Expires July 7, 2013 [Page 23]
Internet-Draft SIP CLF January 2013
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
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.
Gurbani, et al. Expires July 7, 2013 [Page 24]
Internet-Draft SIP CLF January 2013
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.
1 Timestamp: 1275930743.699
Message Type: R
Directionality: r
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: sip:bob@example.net
Gurbani, et al. Expires July 7, 2013 [Page 25]
Internet-Draft SIP CLF January 2013
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: -
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
Gurbani, et al. Expires July 7, 2013 [Page 26]
Internet-Draft SIP CLF January 2013
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
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
Gurbani, et al. Expires July 7, 2013 [Page 27]
Internet-Draft SIP CLF January 2013
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
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
Gurbani, et al. Expires July 7, 2013 [Page 28]
Internet-Draft SIP CLF January 2013
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
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. Expires July 7, 2013 [Page 29]
Internet-Draft SIP CLF January 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
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]
Gurbani, et al. Expires July 7, 2013 [Page 30]
Internet-Draft SIP CLF January 2013
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
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
Gurbani, et al. Expires July 7, 2013 [Page 31]
Internet-Draft SIP CLF January 2013
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.
Searching on "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
Gurbani, et al. Expires July 7, 2013 [Page 32]
Internet-Draft SIP CLF January 2013
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 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
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
Gurbani, et al. Expires July 7, 2013 [Page 33]
Internet-Draft SIP CLF January 2013
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 tradeoffs should be taken in account when logging
more fields than the ones recommended in Section 8.1.
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 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.
Gurbani, et al. Expires July 7, 2013 [Page 34]
Internet-Draft SIP CLF January 2013
12. IANA Considerations
This document does not require any considerations from IANA.
13. Acknowledgments
Members of the sipping, dispatch, ipfix and syslog working groups
provided invaluable input to the formulation of the draft. 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.
14. References
14.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.
14.2. Informative References
[I-D.ietf-sipclf-format]
Salgueiro, G., Gurbani, V., and A. Roach, "Format for the
Session Initiation Protocol (SIP) Common Log Format
(CLF)", draft-ietf-sipclf-format-11 (work in progress),
December 2012.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
Transport Layer Protocol", RFC 4253, January 2006.
Gurbani, et al. Expires July 7, 2013 [Page 35]
Internet-Draft SIP CLF January 2013
[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.
[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.
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
Gurbani, et al. Expires July 7, 2013 [Page 36]
Internet-Draft SIP CLF January 2013
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. Expires July 7, 2013 [Page 37]
