< draft-ietf-sipclf-problem-statement-10.txt   draft-ietf-sipclf-problem-statement-11.txt >
SIPCLF V. Gurbani, Ed. SIPCLF V. Gurbani, Ed.
Internet-Draft Bell Laboratories, Alcatel-Lucent Internet-Draft Bell Laboratories, Alcatel-Lucent
Intended status: Standards Track E. Burger, Ed. Intended status: Standards Track E. Burger, Ed.
Expires: August 9, 2012 Georgetown University Expires: September 10, 2012 Georgetown University
T. Anjali T. Anjali
Illinois Institute of Technology Illinois Institute of Technology
H. Abdelnur H. Abdelnur
O. Festor O. Festor
INRIA INRIA
February 6, 2012 March 9, 2012
The Common Log Format (CLF) for the Session Initiation Protocol (SIP): The Common Log Format (CLF) for the Session Initiation Protocol (SIP):
Framework and Data Model Framework and Data Model
draft-ietf-sipclf-problem-statement-10 draft-ietf-sipclf-problem-statement-11
Abstract Abstract
Well-known web servers such as Apache and web proxies like Squid Well-known web servers such as Apache and web proxies like Squid
support event logging using a common log format. The logs produced support event logging using a common log format. The logs produced
using these de-facto standard formats are invaluable to system using these de-facto standard formats are invaluable to system
administrators for trouble-shooting a server and tool writers to administrators for trouble-shooting a server and tool writers to
craft tools that mine the log files and produce reports and trends. craft tools that mine the log files and produce reports and trends.
Furthermore, these log files can also be used to train anomaly Furthermore, these log files can also be used to train anomaly
detection systems and feed events into a security event management detection systems and feed events into a security event management
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 9, 2012. This Internet-Draft will expire on September 10, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 10 skipping to change at page 3, line 10
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problem statement . . . . . . . . . . . . . . . . . . . . . . 5 3. Problem statement . . . . . . . . . . . . . . . . . . . . . . 5
4. What SIP CLF is and what it is not . . . . . . . . . . . . . . 5 4. What SIP CLF is and what it is not . . . . . . . . . . . . . . 6
5. Alternative approaches to SIP CLF . . . . . . . . . . . . . . 6 5. Alternative approaches to SIP CLF . . . . . . . . . . . . . . 6
5.1. SIP CLF and CDRs . . . . . . . . . . . . . . . . . . . . . 6 5.1. SIP CLF and CDRs . . . . . . . . . . . . . . . . . . . . . 7
5.2. SIP CLF and Wireshark packet capture . . . . . . . . . . . 7 5.2. SIP CLF and Wireshark packet capture . . . . . . . . . . . 7
6. Motivation and use cases . . . . . . . . . . . . . . . . . . . 8 5.3. SIP CLF and syslog . . . . . . . . . . . . . . . . . . . . 8
7. Challenges in establishing a SIP CLF . . . . . . . . . . . . . 9 5.4. SIP CLF and IPFIX . . . . . . . . . . . . . . . . . . . . 9
8. Data model . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Motivation and use cases . . . . . . . . . . . . . . . . . . . 9
8.1. SIP CLF mandatory fields . . . . . . . . . . . . . . . . . 11 7. Challenges in establishing a SIP CLF . . . . . . . . . . . . . 11
8.2. Mandatory fields and SIP entities . . . . . . . . . . . . 13 8. Data model . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.1. SIP CLF mandatory fields . . . . . . . . . . . . . . . . . 12
9.1. UAC registration . . . . . . . . . . . . . . . . . . . . . 15 8.2. Mandatory fields and SIP entities . . . . . . . . . . . . 14
9.2. Direct call between Alice and Bob . . . . . . . . . . . . 16 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.3. Single downstream branch call . . . . . . . . . . . . . . 18 9.1. UAC registration . . . . . . . . . . . . . . . . . . . . . 16
9.4. Forked call . . . . . . . . . . . . . . . . . . . . . . . 23 9.2. Direct call between Alice and Bob . . . . . . . . . . . . 17
10. Security Considerations . . . . . . . . . . . . . . . . . . . 31 9.3. Single downstream branch call . . . . . . . . . . . . . . 19
11. Operational guidance . . . . . . . . . . . . . . . . . . . . . 33 9.4. Forked call . . . . . . . . . . . . . . . . . . . . . . . 24
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 10. Security Considerations . . . . . . . . . . . . . . . . . . . 32
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 11. Operational guidance . . . . . . . . . . . . . . . . . . . . . 34
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
14.1. Normative References . . . . . . . . . . . . . . . . . . . 34 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35
14.2. Informative References . . . . . . . . . . . . . . . . . . 34 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 14.1. Normative References . . . . . . . . . . . . . . . . . . . 35
14.2. Informative References . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
1. Terminology 1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
RFC 3261 [RFC3261] defines additional terms used in this document RFC 3261 [RFC3261] defines additional terms used in this document
that are specific to the SIP domain such as "proxy"; "registrar"; that are specific to the SIP domain such as "proxy"; "registrar";
"redirect server"; "user agent server" or "UAS"; "user agent client" "redirect server"; "user agent server" or "UAS"; "user agent client"
skipping to change at page 5, line 33 skipping to change at page 5, line 33
does not prescribe a specific representation format for the SIP CLF does not prescribe a specific representation format for the SIP CLF
record and instead, allows other documents to define a representation record and instead, allows other documents to define a representation
format. [I-D.ietf-sipclf-format] is an example of a representation format. [I-D.ietf-sipclf-format] is an example of a representation
format that provides an UTF-8 based logging scheme. format that provides an UTF-8 based logging scheme.
3. Problem statement 3. Problem statement
The Session Initiation Protocol (SIP) [RFC3261] is an Internet The Session Initiation Protocol (SIP) [RFC3261] is an Internet
multimedia session signaling protocol. A typical deployment of SIP multimedia session signaling protocol. A typical deployment of SIP
in an enterprise will consist of SIP entities from multiple vendors. in an enterprise will consist of SIP entities from multiple vendors.
Currently, if these entities are capable of producing a log file of Each SIP entity produces logs using a proprietary format. The result
the transactions being handled by them, the log files are produced in of multiplicity of the log file formats is the inability of the
a proprietary format. The result of multiplicity of the log file support staff to easily trace a call from one entity to another, or
formats is the inability of the support staff to easily trace a call even to craft common tools that will perform trend analysis,
from one entity to another, or even to craft common tools that will debugging and troubleshooting problems uniformly across the SIP
perform trend analysis, debugging and troubleshooting problems entities from multiple vendors.
uniformly across the SIP entities of 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
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 SIP does not currently have a common log format and this document
serves to provide the rationale to establish a SIP CLF and identifies serves to provide the rationale to establish a SIP CLF and identifies
the required minimal information that must appear in any SIP CLF the required minimal information that must appear in any SIP CLF
record. record.
4. What SIP CLF is and what it is not 4. What SIP CLF is and what it is not
The SIP CLF is a standardized manner of producing a log file. This 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. format can be used by SIP clients, SIP Servers, proxies, and B2BUAs.
skipping to change at page 6, line 33 skipping to change at page 6, line 44
The SIP CLF is not a quality of service (QoS) measurement tool. If 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 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 received media, then SIP CLF does not aid in this task since it does
not summarize events at the media layer. not summarize events at the media layer.
And finally, the SIP CLF is not a tool for supporting lawful And finally, the SIP CLF is not a tool for supporting lawful
intercept. intercept.
5. Alternative approaches to SIP CLF 5. Alternative approaches to SIP CLF
It is perhaps tempting to consider other approaches --- which though The working group discussed four alternative approaches to determine
not standardized, are in wide enough use in networks today --- to whether they fill the requirements of what is desired of a SIP CLF
determine whether or not a SIP CLF would benefit a SIP network outlined in Section 3. We conclude that while every scheme discussed
consisting of multi-vendor products. The two existing approaches below comes with its advantages, its disadvantages may preclude it
that approximate what SIP CLF does are Call Detail Records (CDRs) and from being used as a SIP CLF. However, we stress that the data model
Wireshark packet sniffing. 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 CDRs 5.1. SIP CLF and CDRs
CDRs are used in operator networks widely and with the adoption of CDRs are used in operator networks widely and with the adoption of
SIP, standardization bodies such as 3GPP have subsequently defined SIP, standardization bodies such as 3GPP have subsequently defined
SIP-related CDRs as well. Today, CDRs are used to implement the SIP-related CDRs as well. Today, CDRs are used to implement the
functionality approximated by SIP CLF, however, there are important functionality approximated by SIP CLF, however, there are important
differences. differences.
One, SIP CLF operates natively at the transaction layer and maintains One, SIP CLF operates natively at the transaction layer and maintains
skipping to change at page 7, line 45 skipping to change at page 8, line 13
captured message into its individual header components. While captured message into its individual header components. While
Wireshark is appropriate to capture and view discrete SIP messages, Wireshark is appropriate to capture and view discrete SIP messages,
it does not suffice to serve in the same capacity as SIP CLF for the it does not suffice to serve in the same capacity as SIP CLF for the
following reasons: following reasons:
o Using Wireshark will not eliminate the need for agreeing to a o Using Wireshark will not eliminate the need for agreeing to a
common set of fields to represent a SIP CLF record. This common common set of fields to represent a SIP CLF record. This common
understanding is important for interoperability to allow one understanding is important for interoperability to allow one
implementation to read a log file written by a different implementation to read a log file written by a different
implementation. implementation.
o The Wireshark packet capture is not easily searchable by simple
command line tools for text processing.
o Using Wireshark would require that the underlying libraries o Using Wireshark would require that the underlying libraries
related to Wireshark and packet capture be available for all related to Wireshark and packet capture be available for all
platforms on which a SIP server or a SIP client can execute on. 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 Given the different platforms that a SIP client or server runs on
--- mobile, fixed host, tablet, etc. --- this may become an --- mobile, fixed host, tablet, etc. --- this may become an
inhibiting factor when compared to the SIP client or server inhibiting factor when compared to the SIP client or server
producing a SIP CLF record natively (the SIP client or server has producing a SIP CLF record natively (the SIP client or server has
already parsed the SIP message for operation on it, therefore, it already parsed the SIP message for operation on it, therefore, it
seems reasonable to have it write the parsed tokens out to seems reasonable to have it write the parsed tokens out to
persistent store in an agreed upon format). persistent store in an agreed upon format).
o If SIP messages are exchanged over a secure transport (TLS), o If SIP messages are exchanged over a secure transport (TLS),
Wireshark will be unable to decrypt them and render them as Wireshark will be unable to decrypt them and render them as
individual SIP headers. individual SIP headers.
o Using Wireshark and the related packet capture libraries may o Using Wireshark and the related packet capture libraries may
imposes a dependency on a third party library. 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,
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.
Furthermore, while IPFIX can collect the same information that a SIP
entity produces in a log file using SIP CLF, it does so at the
packet-level. This means that SIP traffic has to be in cleartext so
that the required SIP headers and their values can be extracted.
6. Motivation and use cases 6. Motivation and use cases
As SIP becomes pervasive in multiple business domains and ubiquitous As SIP becomes pervasive in multiple business domains and ubiquitous
in academic and research environments, it is beneficial to establish in academic and research environments, it is beneficial to establish
a CLF for the following reasons: a CLF for the following reasons:
Common reference for interpreting events: In a laboratory Common reference for interpreting events: In a laboratory
environment or an enterprise service offering there will typically environment or an enterprise service offering there will typically
be SIP entities from multiple vendors participating in routing be SIP entities from multiple vendors participating in routing
requests. Absent a common log format, each entity will produce requests. Absent a common log format, each entity will produce
skipping to change at page 10, line 43 skipping to change at page 12, line 8
monitoring the log file. monitoring the log file.
Finally, beyond supporting native SIP actors such as proxies, Finally, beyond supporting native SIP actors such as proxies,
registrars, redirect servers, and user agent servers (UAS), it is registrars, redirect servers, and user agent servers (UAS), it is
beneficial to derive a common log format that supports back-to-back beneficial to derive a common log format that supports back-to-back
user agent (B2BUA) behavior, which may vary considerably depending on user agent (B2BUA) behavior, which may vary considerably depending on
the specific nature of the B2BUA. the specific nature of the B2BUA.
8. Data model 8. Data model
The minimal SIP CLF fields are defined below. Some of these fields This document defines the mandatory fields that MUST occur in a SIP
contain URIs [RFC3986]. If the URI contains an escaped character CLF record. Some of these fields contain URIs [RFC3986]. If the URI
(""%" HEX HEX" mechanism), the escaped character MUST be logged as contains an escaped character (""%" HEX HEX" mechanism), the escaped
received. The maximum size (in number of bytes) for a SIP CLF field character MUST be logged as received. The maximum size (in number of
is 4096 bytes. This limit is the same regardless of whether the SIP bytes) for a SIP CLF field is 4096 bytes. This limit is the same
CLF field is a meta-field (see "Timestamp" and "Directionality" regardless of whether the SIP CLF field is a meta-field (see
defined below) or a normal SIP header. If the body of the SIP "Timestamp" and "Directionality" defined below) or a normal SIP
message is to be logged, it MUST conform to this limit as well. header. If the body of the SIP message is to be logged, it MUST
conform to this limit as well.
Logging bodies of a SIP message is left optional (and is not shown in Logging bodies of a SIP message is left optional (and is not shown in
the examples of Section 9). If the body is to be logged, the the examples of Section 9). If the body is to be logged, the
specific syntax and semantics used to log bodies MUST be defined by specific syntax and semantics used to log bodies MUST be defined by
the specific representation format used to generate the SIP CLF the specific representation format used to generate the SIP CLF
record. record.
The data model supports extensibility by providing the capability to The data model supports extensibility by providing the capability to
log "optional fields". Optional fields are those SIP header fields log "optional fields". Optional fields are those SIP header fields
(or field components) that are not mandatory (see Section 8.1 for the (or field components) that are not mandatory (see Section 8.1 for the
skipping to change at page 34, line 47 skipping to change at page 35, line 47
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005. RFC 3986, January 2005.
[RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
Transport Layer Protocol", RFC 4253, January 2006. Transport Layer Protocol", RFC 4253, January 2006.
[RFC5101] Claise, B., "Specification of the IP Flow Information
Export (IPFIX) Protocol for the Exchange of IP Traffic
Flow Information", RFC 5101, January 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
[rieck2008] [rieck2008]
Rieck, K., Wahl, S., Laskov, P., Domschitz, P., and K-R. Rieck, K., Wahl, S., Laskov, P., Domschitz, P., and K-R.
Muller, "A Self-learning System for Detection of Anomalous Muller, "A Self-learning System for Detection of Anomalous
SIP Messages", Principles, Systems and Applications of IP SIP Messages", Principles, Systems and Applications of IP
Telecommunications Services and Security for Next Telecommunications Services and Security for Next
Generation Networks (IPTComm), LNCS 5310, pp. 90-106, Generation Networks (IPTComm), LNCS 5310, pp. 90-106,
2008. 2008.
[schneier-1] [schneier-1]
Schneier, B. and J. Kelsey, "Secure audit logs to support Schneier, B. and J. Kelsey, "Secure audit logs to support
computer forensics", ACM Transactions on Information and computer forensics", ACM Transactions on Information and
System Security (TISSEC), 2(2), pp. 159,176, May 1999. System Security (TISSEC), 2(2), pp. 159,176, May 1999.
 End of changes. 15 change blocks. 
46 lines changed or deleted 114 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/