SIPCLF V. Gurbani, Ed.
Internet-Draft Bell Laboratories, Alcatel-Lucent
Intended status: Informational E. Burger, Ed.
Expires: December 31, 2010 This space for sale
T. Anjali
Illinois Institute of Technology
H. Abdelnur
O. Festor
INRIA
June 29, 2010
The Common Log Format (CLF) for the Session Initiation Protocol (SIP)
draft-ietf-sipclf-problem-statement-03
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 by proxies, registrars,
redirect servers as well as back-to-back user agents.
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.
Gurbani, et al. Expires December 31, 2010 [Page 1]
Internet-Draft SIP CLF June 2010
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 31, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
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 BSD License.
Gurbani, et al. Expires December 31, 2010 [Page 2]
Internet-Draft SIP CLF June 2010
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problem statement . . . . . . . . . . . . . . . . . . . . . . 4
4. What SIP CLF is and what it is not . . . . . . . . . . . . . . 4
5. Alternative approaches to SIP CLF . . . . . . . . . . . . . . 5
5.1. SIP CLF and CDRs . . . . . . . . . . . . . . . . . . . . . 5
5.2. SIP CLF and Wireshark packet capture . . . . . . . . . . . 6
6. Motivation and use cases . . . . . . . . . . . . . . . . . . . 6
7. Challenges in establishing a SIP CLF . . . . . . . . . . . . . 8
8. Data model . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. SIP CLF mandatory fields . . . . . . . . . . . . . . . . . 9
8.2. Mandatory fields and SIP entities . . . . . . . . . . . . 11
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. UAC registeration . . . . . . . . . . . . . . . . . . . . 13
9.2. Direct call between Alice and Bob . . . . . . . . . . . . 14
9.3. Single downstream branch call . . . . . . . . . . . . . . 15
9.4. Forked call . . . . . . . . . . . . . . . . . . . . . . . 18
10. Security Considerations . . . . . . . . . . . . . . . . . . . 22
11. Operational guidance . . . . . . . . . . . . . . . . . . . . . 24
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
14. Bit-exact archive for SIP CLF records . . . . . . . . . . . . 24
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
15.1. Normative References . . . . . . . . . . . . . . . . . . . 27
15.2. Informative References . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
Gurbani, et al. Expires December 31, 2010 [Page 3]
Internet-Draft SIP CLF June 2010
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. A log record is, 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 December 31, 2010 [Page 4]
Internet-Draft SIP CLF June 2010
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.
3. Problem statement
The Session Initiation Protocol [RFC3261](SIP) is an Internet
multimedia session signaling protocol that is increasingly used for
other services besides session establishment. A typical deployment
of SIP in an enterprise will consist of SIP entities from multiple
vendors. Currently, if these entities are capable of producing a log
file of the transactions being handled by them, the log files are
produced in 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 of multiple vendors.
SIP does not currently have a CLF 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.
Gurbani, et al. Expires December 31, 2010 [Page 5]
Internet-Draft SIP CLF June 2010
Note: The exact form of the "concise command" is left unspecified
until the working group agrees to one or more formats for encoding
the fields.
The SIP CLF is amenable to quick parsing (i.e., well-delimited
fields) and it is platform and operating system neutral.
The SIP CLF is amenable to easy parsing and lends itself well to
creating other innovative tools.
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.
5. Alternative approaches to SIP CLF
It is perhaps tempting to consider other approaches --- which though
not standardized, are in wide enough use in networks today --- to
determine whether or not a SIP CLF would benefit a SIP network
consisting of multi-vendor products. The two existing approaches
that approximate what SIP CLF does are Call Detail Records (CDRs) and
Wireshark packet sniffing.
5.1. SIP CLF and CDRs
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
Gurbani, et al. Expires December 31, 2010 [Page 6]
Internet-Draft SIP CLF June 2010
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 Wireshark packet capture
Wireshark is a popular raw packet capture tool. It contains filters
that can understand SIP at the protocol level and break down a
captured message into its individual header components. While
Wireshark is appropriate to capture and view discrete SIP messages,
it does not suffice to serve in the same capacity as SIP CLF for two
reasons.
First, all SIP entities that need to save SIP CLF records would
require a Wireshark library for different operating systems and
configurations to link into. Second, and more importantly, if the
SIP messages are exchanged over a TLS-oriented transport, Wireshark
will be unable to decrypt them and render them as individual SIP
headers.
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:
Gurbani, et al. Expires December 31, 2010 [Page 7]
Internet-Draft SIP CLF June 2010
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 CLF 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 CLF format allows independent tool providers
to craft tools and applications that interpret the CLF data to
produce insightful trend analysis and detailed traffic reports.
The format should be such that it retains the ability to be read
by humans and processed using traditional Unix text processing
tools.
Session correlation across diverse processing elements: In
operational SIP networks, a request will typically be processed by
more than one SIP server. A SIP CLF will allow the network
operator to trace the progression of the request (or a set of
requests) as they traverse through the different servers to
establish a concise diagnostic trail of a SIP session.
Note that tracing the request through a set of servers is
considerably less challenging if all the servers belong to the
same administrative domain.
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
12: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
Gurbani, et al. Expires December 31, 2010 [Page 8]
Internet-Draft SIP CLF June 2010
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.
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
Gurbani, et al. Expires December 31, 2010 [Page 9]
Internet-Draft SIP CLF June 2010
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 pend at a proxy as it forks branches downstream or at a
user agent server while it alerts the user. RFC 3261 [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 CLF format that supports back-to-back user
agent (B2BUA) behavior, which may vary considerably depending on the
specific nature of the B2BUA.
8. Data model
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.
Size of the SIP CLF record - The total number of bytes that comprise
the SIP CLF record.
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).
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).
Source:port:xport - The DNS name or IP address of the upstream
client, including the port number and the transport over which the
SIP message was received. The port number must be separated from
the DNS name or IP address by a single ':'. The transport must be
separated from the port by a single ':'. The allowable values for
the transport are governed by the "transport" production rule in
Gurbani, et al. Expires December 31, 2010 [Page 10]
Internet-Draft SIP CLF June 2010
Section 25.1 of RFC3261 [RFC3261].
Destination:port:xport - The DNS name or IP address of the
downstream server, including the port number. The port number
must be separated from the DNS name or IP address by a single ':'.
The transport must be separated from the port by a single ':'.
The allowable values for the transport are governed by the
"transport" production rule in Section 25.1 of RFC3261 [RFC3261].
From - The From URI, including the tag. Whilst one may question the
value of the From URI in light of RFC4744 [RFC4474], 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.
To - The To URI, including tag.
Callid - The Call-ID.
CSeq - The CSeq header.
R-URI - The Request-URI, including any URI parameters.
Status - The SIP response status code.
SIP Proxies may fork, creating several client transactions that
correlate to a single server transaction. Responses arriving on
these client transactions, or new requests (CANCEL, ACK) sent on the
client transaction need log file entries that correlate with a server
transaction. Similarly, a B2BUA may create one or more client
transactions in response to an incoming request. These transactions
will require correlation as well. The last two data 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.)
Gurbani, et al. Expires December 31, 2010 [Page 11]
Internet-Draft SIP CLF June 2010
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.)
Finally, the SIP CLF should be extensible such that future SIP
methods, headers and bodies can be represented as well. Besides the
mandatory fields listed above, any other SIP header that needs to be
logged will appear as an ordered pair of header field name and value.
This data model applies to all SIP entities --- a UAC, UAS, Proxy, a
B2BUA, registrar and redirect server. Note that a B2BUA is a
degenerate case of a proxy and as such the SIP CLF field layout
format prescribed for a proxy is equally applicable to the B2BUA.
Similarly, registrars and redirect servers are a degenerate case of a
UAS, and as such the SIP CLF field layout prescribed for a UAS is
equally applicable to registrars and redirect servers.
The next section specifies the individual SIP CLF data model elements
that form a log record for specific instance of a SIP entity. We
limit our specification to using the minimum data model elements. 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 consist of all the mandatory data 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. Each SIP CLF record MUST contain the mandatory
elements in the order shown below:
Record size, Timestamp, Message type, Directionality, CSeq,
R-URI, Destination:port:xport, Source:port:xport, To, From,
Call-ID, Status, Server-Txn, Client-Txn
Table 1 summarizes how the mandatory fields are logged by a UAC, UAS,
or UAC-half, UAS-half of a SIP proxy and B2BUA. In the table below:
Gurbani, et al. Expires December 31, 2010 [Page 12]
Internet-Draft SIP CLF June 2010
R: implies that the field is logged when a request is handled by that
SIP entity.
r: implies that the field is logged when a response is handled by
that SIP entity.
-: implies that the field is not applicable to that SIP entity.
+------------------------+-----+-----+----------+----------+
| | UAC | UAS | UAS-half | UAC-half |
+------------------------+-----+-----+----------+----------+
| Timestamp | R,r | R,r | R,r | R,r |
| SIP CLF record size | R,r | R,r | R,r | R,r |
| Message type | R,r | R,r | R,r | R,r |
| Directionality | R,r | R,r | R,r | R,r |
| CSeq | R,r | R,r | R,r | R,r |
| R-URI | R | R | R | R |
| Destination:port:xport | R,r | R,r | R,r | R,r |
| Source:port:xport | R,r | R,r | R,r | R,r |
| To | R,r | R,r | R,r | R,r |
| From | R,r | R,r | R,r | R,r |
| Call-ID | R,r | R,r | R,r | R,r |
| Status | r | r | r | r |
| Server-Txn | - | R,r | R,r | R,r |
| Client-Txn | R,r | - | r | R,r |
+------------------------+-----+-----+----------+----------+
SIP CLF fields logged per entity
Table 1
9. Examples
The examples use only the mandatory data elements defined in
Section 8.1. Extension elements are not considered. The examples
below use the template defined in Section 8.2 when logging a SIP CLF
record. When a given mandatory field is not applicable to a SIP
entity as determined by Table 1, we use the horizontal dash ("-") to
represent it. The CSeq header field is represented by Method-Number
(e.g., INVITE-32). Each field is separated from its neighbors using
a single white space.
It is important to note that the syntax for the examples in this
section is for illustration purposes only, and is not a specific
representation of a logging format. It is expected that one or more
documents will outline specific formats for logging.
Gurbani, et al. Expires December 31, 2010 [Page 13]
Internet-Draft SIP CLF June 2010
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 2
summarizes these addresses.
+-------------------+--------------------+-------------------+
| 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 2
Illustrative examples of SIP CLF follow. These examples use the
<allOneLine> tag defined in [RFC4475] to logically denote a single
line.
9.1. UAC registeration
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. The mandatory data model elements correspond to
those listed in Table 1.
<allOneLine>
1275930743.699 R s REGISTER-1 sip:example.com
198.51.100.10:5060:udp 198.51.100.1:5060:udp
sip:example.com sip:alice@example.com;tag=76yhh
f81-d4-f6@example.com - - c-tr-1
</allOneLine>
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. The mandatory data elements correspond to those listed
in Table 1.
Gurbani, et al. Expires December 31, 2010 [Page 14]
Internet-Draft SIP CLF June 2010
<allOneLine>
173 1275930744.100 r r REGISTER-1 - 198.51.100.1:5060:udp
198.51.100.10:5060:udp sip:example.com;tag=reg-1xtr
sip:alice@example.com;tag=76yhh f81-d4-f6@example.com
200 - c-tr-1
<allOneLine>
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 Alice's UAC
point of view. 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).
<allOneLine>
183 1275930743.699 R s INVITE-32 sip:bob@bob1.example.net
203.0.113.1:5060:udp 198.51.100.1:5060:udp
sip:bob@example.net sip:alice@example.com;tag=76yhh
f82-d4-f7@example.com - - c-1-xt6
</allOneLine>
<allOneLine>
175 1275930745.002 r r INVITE-32 - 198.51.100.1:5060:udp
203.0.113.1:5060:udp sip:bob@example.net;tag=b-in6-iu
sip:alice@example.com;tag=76yhh f82-d4-f7@example.com
180 - c-1-xt6
<allOneLine>
<allOneLine>
175 1275930746.100 r r INVITE-32 - 198.51.100.1:5060:udp
203.0.113.1:5060:udp sip:bob@example.net;tag=b-in6-iu
sip:alice@example.com;tag=76yhh f82-d4-f7@example.com
200 - c-1-xt6
<allOneLine>
<allOneLine>
193 1275930746.120 R s ACK-32 sip:bob@bob1.example.net
203.0.113.1:5060:udp 198.51.100.1:5060:udp
sip:bob@example.net;tag=b-in6-iu
sip:alice@example.com;tag=76yhh f82-d4-f7@example.com
- - c-1-xt6
<allOneLine>
Gurbani, et al. Expires December 31, 2010 [Page 15]
Internet-Draft SIP CLF June 2010
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 correspond to the viewpoint of P1. The log
records are presented one per logical line and the line numbers 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
<allOneLine>
1 175 1275930743.699 R r INVITE-43 sip:bob@example.net
198.51.100.10:5060:udp 198.51.100.1:5060:udp
sip:bob@example.net sip:alice@example.com;tag=al-1
tr-87h@example.com - s-x-tr -
</allOneLine>
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 "-".
Gurbani, et al. Expires December 31, 2010 [Page 16]
Internet-Draft SIP CLF June 2010
<allOneLine>
2 159 1275930744.001 r s INVITE-43 - 198.51.100.1:5060:udp
198.51.100.10:5060:udp sip:bob@example.net
sip:alice@example.com;tag=al-1 tr-87h@example.com
100 s-x-tr -
</allOneLine>
<allOneLine>
3 184 1275930744.998 R s INVITE-43 sip:bob@bob1.example.net
203.0.113.1:5060:udp 198.51.100.10:5060:udp
sip:bob@example.net sip:alice@example.com;tag=al-1
tr-87h@example.com - s-x-tr c-x-tr
</allOneLine>
In line 3 above, P1 has created a client transaction identification
code for the downstream branch and populated the SIP CLF field
Client-Txn.
Gurbani, et al. Expires December 31, 2010 [Page 17]
Internet-Draft SIP CLF June 2010
<allOneLine>
4 172 1275930745.200 r r INVITE-43 - 198.51.100.10:5060:udp
203.0.113.1:5060:udp sip:bob@example.net;tag=b1-1
sip:alice@example.com;tag=al-1 tr-87h@example.com
100 s-x-tr c-x-tr
</allOneLine>
<allOneLine>
5 172 1275930745.800 r r INVITE-43 - 198.51.100.10:5060:udp
203.0.113.1:5060:udp sip:bob@example.net;tag=b1-1
sip:alice@example.com;tag=al-1 tr-87h@example.com
180 s-x-tr c-x-tr
</allOneLine>
<allOneLine>
6 173 1275930746.009 r s INVITE-43 - 198.51.100.1:5060:udp
198.51.100.10:5060:udp sip:bob@example.net;tag=b1-1
sip:alice@example.com;tag=al-1 tr-87h@example.com 180
s-x-tr c-x-tr
</allOneLine>
<allOneLine>
7 172 1275930747.120 r r INVITE-43 - 198.51.100.10:5060:udp
203.0.113.1:5060:udp sip:bob@example.net;tag=b1-1
sip:alice@example.com;tag=al-1 tr-87h@example.com 200
s-x-tr c-x-tr
</allOneLine>
<allOneLine>
8 173 1275930747.300 r s INVITE-43 - 198.51.100.1:5060:udp
198.51.100.10:5060:udp sip:bob@example.net;tag=b1-1
sip:alice@example.com;tag=al-1 tr-87h@example.com 200
s-x-tr c-x-tr
</allOneLine>
<allOneLine>
9 186 1275930749.100 R r ACK-43 sip:bob@example.net
198.51.100.10:5060:udp 198.51.100.1:5060:udp
sip:bob@example.net;tag=b1-1 sip:alice@example.com;tag=al-1
tr-87h@example.com - s-x-tr c-x-tr
</allOneLine>
<allOneLine>
10 185 1275930749.100 R s ACK-43 sip:bob@example.net
203.0.113.1:5060:udp 198.51.100.10:5060:udp
sip:bob@example.net;tag=b1-1 sip:alice@example.com;tag=al-1
tr-87h@example.com - s-x-tr c-x-tr
</allOneLine>
Gurbani, et al. Expires December 31, 2010 [Page 18]
Internet-Draft SIP CLF June 2010
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. The SIP CLF log records correspond
to the viewpoint of P2. The log records are presented one per
logical line and the line numbers refer to Figure 2.
Gurbani, et al. Expires December 31, 2010 [Page 19]
Internet-Draft SIP CLF June 2010
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
<allOneLine>
1 175 1275930743.699 R r INVITE-43 sip:bob@example.net
203.0.113.200:5060:udp 198.51.100.1:5060:udp
sip:bob@example.net sip:alice@example.com;tag=a1-1
tr-88h@example.com - s-1-tr -
</allOneLine>
<allOneLine>
2 159 1275930744.001 r s INVITE-43 - 198.51.100.1:5060:udp
203.0.113.200:5060:udp sip:bob@example.net
Gurbani, et al. Expires December 31, 2010 [Page 20]
Internet-Draft SIP CLF June 2010
sip:alice@example.com;tag=a1-1
tr-88h@example.com 100 s-1-tr -
</allOneLine>
<allOneLine>
3 1275930744.998 R s INVITE-43 sip:bob@bob1.example.net
203.0.113.1:5060:udp 203.0.113.200:5060:udp
sip:bob@example.net sip:alice@example.com;tag=a1-1
tr-88h@example.com - s-1-tr c-1-tr
</allOneLine>
<allOneLine>
4 186 1275930745.500 R s INVITE-43 sip:bob@bob2.example.net
[2001:db8::9]:5060:udp 203.0.113.200:5060:udp
sip:bob@example.net sip:alice@example.com;tag=a1-1
tr-88h@example.com - s-1-tr c-2-tr
</allOneLine>
<allOneLine>
5 172 1275930745.800 r r INVITE-43 - 203.0.113.200:5060:udp
203.0.113.1:5060:udp sip:bob@example.net;tag=b1-1
sip:alice@example.com;tag=a1-1
tr-88h@example.com 100 s-1-tr c-1-tr
</allOneLine>
<allOneLine>
6 174 1275930746.100 r r INVITE-43 - 203.0.113.200:5060:udp
[2001:db8::9]:5060:udp sip:bob@example.net;tag=b2-2
sip:alice@example.com;tag=a1-1
tr-88h@example.com 100 s-1-tr c-2-tr
</allOneLine>
<allOneLine>
7 174 1275930746.700 r r INVITE-43 - 203.0.113.200:5060:udp
[2001:db8::9]:5060:udp sip:bob@example.net;tag=b2-2
sip:alice@example.com;tag=a1-1
tr-88h@example.com 180 s-1-tr c-2-tr
</allOneLine>
<allOneLine>
8 170 1275930746.990 r s INVITE-43 - 198.51.100.1:5060:udp
203.0.113.200:5060:udp sip:bob@example.net;b2-2
sip:alice@example.com;tag=a1-1
tr-88h@example.com 180 s-1-tr c-2-tr
<allOneLine>
<allOneLine>
9 170 1275930747.100 r r INVITE-43 203.0.113.200:5060:udp
Gurbani, et al. Expires December 31, 2010 [Page 21]
Internet-Draft SIP CLF June 2010
203.0.113.1:5060:udp sip:bob@example.net;tag=b1-1
sip:alice@example.com;tag=a1-1
tr-88h@example.com 180 s-1-tr c-1-tr
</allOneLine>
<allOneLine>
10 173 1275930747.300 r s INVITE-43 - 198.51.100.1:5060:udp
203.0.113.200:5060:udp sip:bob@example.net;tag=b1-1
sip:alice@example.com;tag=a1-1
tr-88h@example.com 180 s-1-tr c-1-tr
</allOneLine>
<allOneLine>
11 172 1275930747.800 r r INVITE-43 - 203.0.113.200:5060:udp
203.0.113.1:5060:udp sip:bob@example.net;tag=b1-1
sip:alice@example.com;tag=a1-1
tr-88h@example.com 200 s-1-tr c-1-tr
</allOneLine>
<allOneLine>
12 173 1275930748.000 r s INVITE-43 - 198.51.100.1:5060:udp
203.0.113.200:5060:udp sip:bob@example.net;tag=b1-1
sip:alice@example.com;tag=a1-1
tr-88h@example.com 200 s-1-tr c-1-tr
</allOneLine>
<allOneLine>
13 191 1275930748.201 R s CANCEL-43 sip:bob@bob2.example.net
[2001:db8::9]:5060:udp 203.0.113.200:5060:udp
sip:bob@example.net;b2-2 sip:alice@example.com;tag=a1-1
tr-88h@example.com - s-1-tr c-2-tr
</allOneLine>
<allOneLine>
14 170 1275930748.991 r r INVITE-43 - 203.0.113.200:5060:udp
[2001:db8::9]:5060:udp sip:bob@example.net;b2-2
sip:alice@example.com;tag=a1-1 tr-88h@example.com
487 s-1-tr c-2-tr
</allOneLine>
<allOneLine>
15 188 1275930749.455 R s ACK-43 sip:bob@bob2.example.net
[2001:db8::9]:5060:udp 203.0.113.200:5060:udp
sip:bob@example.net;b2-2 sip:alice@example.com;tag=a1-1
tr-88h@example.com - s-1-tr c-2-tr
</allOneLine>
<allOneLine>
Gurbani, et al. Expires December 31, 2010 [Page 22]
Internet-Draft SIP CLF June 2010
16 170 1275930750.001 r r CANCEL-43 - 203.0.113.200:5060:udp
[2001:db8::9]:5060:udp sip:bob@example.net;b2-2
sip:alice@example.com;tag=a1-1
tr-88h@example.com 200 s-1-tr c-2-tr
</allOneLine>
The above SIP CLF log makes it easy to search for a specific
transaction or a state of the session. Section 14 contains a bit-
exact archive of all the SIP CLF logs in this document. On a Linux/
Unix system, a command of "grep c-1-tr" on the logs in the archive
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. The absence of the ACK request signifies that the ACK
was exchanged end-to-end.
A command of "grep 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. 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 may mount a replay attack by modifying existing
records in the log file or inserting new records;
o An attacker may delete parts of --- or indeed, the whole --- file.
It is outside the scope of this document to specify how to protect
the log file while it is stored on disk. However, operators may
consider using common administrative features such as disk encryption
and securing log files [schneier-1]. Operators may also consider
hardening the machine on which the log files are stored by
restricting physical access to the host as well as restricting access
to the files themselves.
Gurbani, et al. Expires December 31, 2010 [Page 23]
Internet-Draft SIP CLF June 2010
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 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, operators may consider using common security
protocols described in [RFC3552] to transfer log files or individual
records. Alternatively, the log file may be transferred through bulk
methods that also guarantees integrity, or at least detects and
alerts to modification attempts.
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.
Gurbani, et al. Expires December 31, 2010 [Page 24]
Internet-Draft SIP CLF June 2010
11. Operational guidance
SIP CLF log files will take up substantive amount of disk space
depending on traffic volume at a processing entity and the amount of
information being logged. As such, any enterprise using SIP CLF
should establish operational procedures for file rollovers as
appropriate to the needs of the organization.
Listing such operational guidelines in this document is out of scope
for this work.
NOTE: Preliminary volume analysis was presented to the working group
mailing list during the Anaheim IETF (please see
http://www.ietf.org/mail-archive/web/sip-clf/current/msg00123.html
for the analysis.) An open question is whether the working group
thinks that this analysis should be put in this document.
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, 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 a data model.
14. Bit-exact archive for SIP CLF records
The following text block is a base64 encoded archive of all the SIP
CLF records present in this document. To recover the unencoded file,
the text of this document may be passed as input to the following
perl script (the output should be redirected to a file).
Gurbani, et al. Expires December 31, 2010 [Page 25]
Internet-Draft SIP CLF June 2010
#!/usr/bin/perl
use strict;
my $bdata = "";
use MIME::Base64;
while(<>)
{
if (/-- BEGIN MESSAGE ARCHIVE --/ .. /-- END MESSAGE ARCHIVE --/)
{
if ( m/^\s*[^\s]+\s*$/)
{
$bdata = $bdata . $_;
}
}
}
print decode_base64($bdata);
-- BEGIN MESSAGE ARCHIVE --
MTcyIDEyNzU5MzA3NDMuNjk5IFIgcyBSRUdJU1RFUi0xIHNpcDpleGFtcGxlLmNvbSAx
OTguNTEuMTAwLjEwOjUwNjA6dWRwIDE5OC41MS4xMDAuMTo1MDYwOnVkcCBzaXA6ZXhh
bXBsZS5jb20gc2lwOmFsaWNlQGV4YW1wbGUuY29tO3RhZz03NnloaCBmODEtZDQtZjZA
ZXhhbXBsZS5jb20gLSAtIGMtdHItMQoxNzMgMTI3NTkzMDc0NC4xMDAgciByIFJFR0lT
VEVSLTEgLSAxOTguNTEuMTAwLjE6NTA2MDp1ZHAgMTk4LjUxLjEwMC4xMDo1MDYwOnVk
cCBzaXA6ZXhhbXBsZS5jb207dGFnPXJlZy0xeHRyIHNpcDphbGljZUBleGFtcGxlLmNv
bTt0YWc9NzZ5aGggZjgxLWQ0LWY2QGV4YW1wbGUuY29tIDIwMCAtIGMtdHItMQoxODMg
MTI3NTkzMDc0My42OTkgUiBzIElOVklURS0zMiBzaXA6Ym9iQGJvYjEuZXhhbXBsZS5u
ZXQgMjAzLjAuMTEzLjE6NTA2MDp1ZHAgMTk4LjUxLjEwMC4xOjUwNjA6dWRwIHNpcDpi
b2JAZXhhbXBsZS5uZXQgc2lwOmFsaWNlQGV4YW1wbGUuY29tO3RhZz03NnloaCBmODIt
ZDQtZjdAZXhhbXBsZS5jb20gLSAtIGMtMS14dDYKMTc1IDEyNzU5MzA3NDUuMDAyIHIg
ciBJTlZJVEUtMzIgLSAxOTguNTEuMTAwLjE6NTA2MDp1ZHAgMjAzLjAuMTEzLjE6NTA2
MDp1ZHAgc2lwOmJvYkBleGFtcGxlLm5ldDt0YWc9Yi1pbjYtaXUgc2lwOmFsaWNlQGV4
YW1wbGUuY29tO3RhZz03NnloaCBmODItZDQtZjdAZXhhbXBsZS5jb20gMTgwIC0gYy0x
LXh0NgoxNzUgMTI3NTkzMDc0Ni4xMDAgciByIElOVklURS0zMiAtIDE5OC41MS4xMDAu
MTo1MDYwOnVkcCAyMDMuMC4xMTMuMTo1MDYwOnVkcCBzaXA6Ym9iQGV4YW1wbGUubmV0
O3RhZz1iLWluNi1pdSBzaXA6YWxpY2VAZXhhbXBsZS5jb207dGFnPTc2eWhoIGY4Mi1k
NC1mN0BleGFtcGxlLmNvbSAyMDAgLSBjLTEteHQ2CjE5MyAxMjc1OTMwNzQ2LjEyMCBS
IHMgQUNLLTMyIHNpcDpib2JAYm9iMS5leGFtcGxlLm5ldCAyMDMuMC4xMTMuMTo1MDYw
OnVkcCAxOTguNTEuMTAwLjE6NTA2MDp1ZHAgc2lwOmJvYkBleGFtcGxlLm5ldDt0YWc9
Yi1pbjYtaXUgc2lwOmFsaWNlQGV4YW1wbGUuY29tO3RhZz03NnloaCBmODItZDQtZjdA
ZXhhbXBsZS5jb20gLSAtIGMtMS14dDYKMTc1IDEyNzU5MzA3NDMuNjk5IFIgciBJTlZJ
VEUtNDMgc2lwOmJvYkBleGFtcGxlLm5ldCAxOTguNTEuMTAwLjEwOjUwNjA6dWRwIDE5
OC41MS4xMDAuMTo1MDYwOnVkcCBzaXA6Ym9iQGV4YW1wbGUubmV0IHNpcDphbGljZUBl
eGFtcGxlLmNvbTt0YWc9YWwtMSB0ci04N2hAZXhhbXBsZS5jb20gLSBzLXgtdHIgLQox
NTkgMTI3NTkzMDc0NC4wMDEgciBzIElOVklURS00MyAtIDE5OC41MS4xMDAuMTo1MDYw
OnVkcCAxOTguNTEuMTAwLjEwOjUwNjA6dWRwIHNpcDpib2JAZXhhbXBsZS5uZXQgc2lw
OmFsaWNlQGV4YW1wbGUuY29tO3RhZz1hbC0xIHRyLTg3aEBleGFtcGxlLmNvbSAxMDAg
cy14LXRyIC0KMTg0IDEyNzU5MzA3NDQuOTk4IFIgcyBJTlZJVEUtNDMgc2lwOmJvYkBi
b2IxLmV4YW1wbGUubmV0IDIwMy4wLjExMy4xOjUwNjA6dWRwIDE5OC41MS4xMDAuMTA6
Gurbani, et al. Expires December 31, 2010 [Page 26]
Internet-Draft SIP CLF June 2010
NTA2MDp1ZHAgc2lwOmJvYkBleGFtcGxlLm5ldCBzaXA6YWxpY2VAZXhhbXBsZS5jb207
dGFnPWFsLTEgdHItODdoQGV4YW1wbGUuY29tIC0gcy14LXRyIGMteC10cgoxNzIgMTI3
NTkzMDc0NS4yMDAgciByIElOVklURS00MyAtIDE5OC41MS4xMDAuMTA6NTA2MDp1ZHAg
MjAzLjAuMTEzLjE6NTA2MDp1ZHAgc2lwOmJvYkBleGFtcGxlLm5ldDt0YWc9YjEtMSBz
aXA6YWxpY2VAZXhhbXBsZS5jb207dGFnPWFsLTEgdHItODdoQGV4YW1wbGUuY29tIDEw
MCBzLXgtdHIgYy14LXRyCjE3MiAxMjc1OTMwNzQ1LjgwMCByIHIgSU5WSVRFLTQzIC0g
MTk4LjUxLjEwMC4xMDo1MDYwOnVkcCAyMDMuMC4xMTMuMTo1MDYwOnVkcCBzaXA6Ym9i
QGV4YW1wbGUubmV0O3RhZz1iMS0xIHNpcDphbGljZUBleGFtcGxlLmNvbTt0YWc9YWwt
MSB0ci04N2hAZXhhbXBsZS5jb20gMTgwIHMteC10ciBjLXgtdHIKMTczIDEyNzU5MzA3
NDYuMDA5IHIgcyBJTlZJVEUtNDMgLSAxOTguNTEuMTAwLjE6NTA2MDp1ZHAgMTk4LjUx
LjEwMC4xMDo1MDYwOnVkcCBzaXA6Ym9iQGV4YW1wbGUubmV0O3RhZz1iMS0xIHNpcDph
bGljZUBleGFtcGxlLmNvbTt0YWc9YWwtMSB0ci04N2hAZXhhbXBsZS5jb20gMTgwIHMt
eC10ciBjLXgtdHIKMTcyIDEyNzU5MzA3NDcuMTIwIHIgciBJTlZJVEUtNDMgLSAxOTgu
NTEuMTAwLjEwOjUwNjA6dWRwIDIwMy4wLjExMy4xOjUwNjA6dWRwIHNpcDpib2JAZXhh
bXBsZS5uZXQ7dGFnPWIxLTEgc2lwOmFsaWNlQGV4YW1wbGUuY29tO3RhZz1hbC0xIHRy
LTg3aEBleGFtcGxlLmNvbSAyMDAgcy14LXRyIGMteC10cgoxNzMgMTI3NTkzMDc0Ny4z
MDAgciBzIElOVklURS00MyAtIDE5OC41MS4xMDAuMTo1MDYwOnVkcCAxOTguNTEuMTAw
LjEwOjUwNjA6dWRwIHNpcDpib2JAZXhhbXBsZS5uZXQ7dGFnPWIxLTEgc2lwOmFsaWNl
QGV4YW1wbGUuY29tO3RhZz1hbC0xIHRyLTg3aEBleGFtcGxlLmNvbSAyMDAgcy14LXRy
IGMteC10cgoxODYgMTI3NTkzMDc0OS4xMDAgUiByIEFDSy00MyBzaXA6Ym9iQGV4YW1w
bGUubmV0IDE5OC41MS4xMDAuMTA6NTA2MDp1ZHAgMTk4LjUxLjEwMC4xOjUwNjA6dWRw
IHNpcDpib2JAZXhhbXBsZS5uZXQ7dGFnPWIxLTEgc2lwOmFsaWNlQGV4YW1wbGUuY29t
O3RhZz1hbC0xIHRyLTg3aEBleGFtcGxlLmNvbSAtIHMteC10ciBjLXgtdHIKMTg1IDEy
NzU5MzA3NDkuMTAwIFIgcyBBQ0stNDMgc2lwOmJvYkBleGFtcGxlLm5ldCAyMDMuMC4x
MTMuMTo1MDYwOnVkcCAxOTguNTEuMTAwLjEwOjUwNjA6dWRwIHNpcDpib2JAZXhhbXBs
ZS5uZXQ7dGFnPWIxLTEgc2lwOmFsaWNlQGV4YW1wbGUuY29tO3RhZz1hbC0xIHRyLTg3
aEBleGFtcGxlLmNvbSAtIHMteC10ciBjLXgtdHIKMTc1IDEyNzU5MzA3NDMuNjk5IFIg
ciBJTlZJVEUtNDMgc2lwOmJvYkBleGFtcGxlLm5ldCAyMDMuMC4xMTMuMjAwOjUwNjA6
dWRwIDE5OC41MS4xMDAuMTo1MDYwOnVkcCBzaXA6Ym9iQGV4YW1wbGUubmV0IHNpcDph
bGljZUBleGFtcGxlLmNvbTt0YWc9YTEtMSB0ci04OGhAZXhhbXBsZS5jb20gLSBzLTEt
dHIgLQoxNTkgMTI3NTkzMDc0NC4wMDEgciBzIElOVklURS00MyAtIDE5OC41MS4xMDAu
MTo1MDYwOnVkcCAyMDMuMC4xMTMuMjAwOjUwNjA6dWRwIHNpcDpib2JAZXhhbXBsZS5u
ZXQgc2lwOmFsaWNlQGV4YW1wbGUuY29tO3RhZz1hMS0xIHRyLTg4aEBleGFtcGxlLmNv
bSAxMDAgcy0xLXRyIC0KMTg0IDEyNzU5MzA3NDQuOTk4IFIgcyBJTlZJVEUtNDMgc2lw
OmJvYkBib2IxLmV4YW1wbGUubmV0IDIwMy4wLjExMy4xOjUwNjA6dWRwIDIwMy4wLjEx
My4yMDA6NTA2MDp1ZHAgc2lwOmJvYkBleGFtcGxlLm5ldCBzaXA6YWxpY2VAZXhhbXBs
ZS5jb207dGFnPWExLTEgdHItODhoQGV4YW1wbGUuY29tIC0gcy0xLXRyIGMtMS10cgox
ODYgMTI3NTkzMDc0NS41MDAgUiBzIElOVklURS00MyBzaXA6Ym9iQGJvYjIuZXhhbXBs
ZS5uZXQgWzIwMDE6ZGI4Ojo5XTo1MDYwOnVkcCAyMDMuMC4xMTMuMjAwOjUwNjA6dWRw
IHNpcDpib2JAZXhhbXBsZS5uZXQgc2lwOmFsaWNlQGV4YW1wbGUuY29tO3RhZz1hMS0x
IHRyLTg4aEBleGFtcGxlLmNvbSAtIHMtMS10ciBjLTItdHIKMTcyIDEyNzU5MzA3NDUu
ODAwIHIgciBJTlZJVEUtNDMgLSAyMDMuMC4xMTMuMjAwOjUwNjA6dWRwIDIwMy4wLjEx
My4xOjUwNjA6dWRwIHNpcDpib2JAZXhhbXBsZS5uZXQ7dGFnPWIxLTEgc2lwOmFsaWNl
QGV4YW1wbGUuY29tO3RhZz1hMS0xIHRyLTg4aEBleGFtcGxlLmNvbSAxMDAgcy0xLXRy
IGMtMS10cgoxNzQgMTI3NTkzMDc0Ni4xMDAgciByIElOVklURS00MyAtIDIwMy4wLjEx
My4yMDA6NTA2MDp1ZHAgWzIwMDE6ZGI4Ojo5XTo1MDYwOnVkcCBzaXA6Ym9iQGV4YW1w
bGUubmV0O3RhZz1iMi0yIHNpcDphbGljZUBleGFtcGxlLmNvbTt0YWc9YTEtMSB0ci04
OGhAZXhhbXBsZS5jb20gMTAwIHMtMS10ciBjLTItdHIKMTc0IDEyNzU5MzA3NDYuNzAw
Gurbani, et al. Expires December 31, 2010 [Page 27]
Internet-Draft SIP CLF June 2010
IHIgciBJTlZJVEUtNDMgLSAyMDMuMC4xMTMuMjAwOjUwNjA6dWRwIFsyMDAxOmRiODo6
OV06NTA2MDp1ZHAgc2lwOmJvYkBleGFtcGxlLm5ldDt0YWc9YjItMiBzaXA6YWxpY2VA
ZXhhbXBsZS5jb207dGFnPWExLTEgdHItODhoQGV4YW1wbGUuY29tIDE4MCBzLTEtdHIg
Yy0yLXRyCjE3MCAxMjc1OTMwNzQ2Ljk5MCByIHMgSU5WSVRFLTQzIC0gMTk4LjUxLjEw
MC4xOjUwNjA6dWRwIDIwMy4wLjExMy4yMDA6NTA2MDp1ZHAgc2lwOmJvYkBleGFtcGxl
Lm5ldDtiMi0yIHNpcDphbGljZUBleGFtcGxlLmNvbTt0YWc9YTEtMSB0ci04OGhAZXhh
bXBsZS5jb20gMTgwIHMtMS10ciBjLTItdHIKMTcwIDEyNzU5MzA3NDcuMTAwIHIgciBJ
TlZJVEUtNDMgMjAzLjAuMTEzLjIwMDo1MDYwOnVkcCAyMDMuMC4xMTMuMTo1MDYwOnVk
cCBzaXA6Ym9iQGV4YW1wbGUubmV0O3RhZz1iMS0xIHNpcDphbGljZUBleGFtcGxlLmNv
bTt0YWc9YTEtMSB0ci04OGhAZXhhbXBsZS5jb20gMTgwIHMtMS10ciBjLTEtdHIKMTcz
IDEyNzU5MzA3NDcuMzAwIHIgcyBJTlZJVEUtNDMgLSAxOTguNTEuMTAwLjE6NTA2MDp1
ZHAgMjAzLjAuMTEzLjIwMDo1MDYwOnVkcCBzaXA6Ym9iQGV4YW1wbGUubmV0O3RhZz1i
MS0xIHNpcDphbGljZUBleGFtcGxlLmNvbTt0YWc9YTEtMSB0ci04OGhAZXhhbXBsZS5j
b20gMTgwIHMtMS10ciBjLTEtdHIKMTcyIDEyNzU5MzA3NDcuODAwIHIgciBJTlZJVEUt
NDMgLSAyMDMuMC4xMTMuMjAwOjUwNjA6dWRwIDIwMy4wLjExMy4xOjUwNjA6dWRwIHNp
cDpib2JAZXhhbXBsZS5uZXQ7dGFnPWIxLTEgc2lwOmFsaWNlQGV4YW1wbGUuY29tO3Rh
Zz1hMS0xIHRyLTg4aEBleGFtcGxlLmNvbSAyMDAgcy0xLXRyIGMtMS10cgoxNzMgMTI3
NTkzMDc0OC4wMDAgciBzIElOVklURS00MyAtIDE5OC41MS4xMDAuMTo1MDYwOnVkcCAy
MDMuMC4xMTMuMjAwOjUwNjA6dWRwIHNpcDpib2JAZXhhbXBsZS5uZXQ7dGFnPWIxLTEg
c2lwOmFsaWNlQGV4YW1wbGUuY29tO3RhZz1hMS0xIHRyLTg4aEBleGFtcGxlLmNvbSAy
MDAgcy0xLXRyIGMtMS10cgoxOTEgMTI3NTkzMDc0OC4yMDEgUiBzIENBTkNFTC00MyBz
aXA6Ym9iQGJvYjIuZXhhbXBsZS5uZXQgWzIwMDE6ZGI4Ojo5XTo1MDYwOnVkcCAyMDMu
MC4xMTMuMjAwOjUwNjA6dWRwIHNpcDpib2JAZXhhbXBsZS5uZXQ7YjItMiBzaXA6YWxp
Y2VAZXhhbXBsZS5jb207dGFnPWExLTEgdHItODhoQGV4YW1wbGUuY29tIC0gcy0xLXRy
IGMtMi10cgoxNzAgMTI3NTkzMDc0OC45OTEgciByIElOVklURS00MyAtIDIwMy4wLjEx
My4yMDA6NTA2MDp1ZHAgWzIwMDE6ZGI4Ojo5XTo1MDYwOnVkcCBzaXA6Ym9iQGV4YW1w
bGUubmV0O2IyLTIgc2lwOmFsaWNlQGV4YW1wbGUuY29tO3RhZz1hMS0xIHRyLTg4aEBl
eGFtcGxlLmNvbSA0ODcgcy0xLXRyIGMtMi10cgoxODggMTI3NTkzMDc0OS40NTUgUiBz
IEFDSy00MyBzaXA6Ym9iQGJvYjIuZXhhbXBsZS5uZXQgWzIwMDE6ZGI4Ojo5XTo1MDYw
OnVkcCAyMDMuMC4xMTMuMjAwOjUwNjA6dWRwIHNpcDpib2JAZXhhbXBsZS5uZXQ7YjIt
MiBzaXA6YWxpY2VAZXhhbXBsZS5jb207dGFnPWExLTEgdHItODhoQGV4YW1wbGUuY29t
IC0gcy0xLXRyIGMtMi10cgoxNzAgMTI3NTkzMDc1MC4wMDEgciByIENBTkNFTC00MyAt
IDIwMy4wLjExMy4yMDA6NTA2MDp1ZHAgWzIwMDE6ZGI4Ojo5XTo1MDYwOnVkcCBzaXA6
Ym9iQGV4YW1wbGUubmV0O2IyLTIgc2lwOmFsaWNlQGV4YW1wbGUuY29tO3RhZz1hMS0x
IHRyLTg4aEBleGFtcGxlLmNvbSAyMDAgcy0xLXRyIGMtMi10cgo=
-- END MESSAGE ARCHIVE --
15. References
15.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Gurbani, et al. Expires December 31, 2010 [Page 28]
Internet-Draft SIP CLF June 2010
15.2. Informative References
[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.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552,
July 2003.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4475] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J.,
and H. Schulzrinne, "Session Initiation Protocol (SIP)
Torture Test Messages", RFC 4475, May 2006.
[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
Gurbani, et al. Expires December 31, 2010 [Page 29]
Internet-Draft SIP CLF June 2010
Eric W. Burger (editor)
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
Olivier Festor
INRIA
INRIA - Nancy Grant Est
Campus Scientifique
54506, Vandoeuvre-les-Nancy Cedex
France
Email: Olivier.Festor@loria.fr
Gurbani, et al. Expires December 31, 2010 [Page 30]
