< draft-ietf-sipclf-problem-statement-09.txt   draft-ietf-sipclf-problem-statement-10.txt >
SIPCLF V. Gurbani, Ed. SIPCLF V. Gurbani, Ed.
Internet-Draft Bell Laboratories, Alcatel-Lucent Internet-Draft Bell Laboratories, Alcatel-Lucent
Intended status: Informational E. Burger, Ed. Intended status: Standards Track E. Burger, Ed.
Expires: June 8, 2012 Georgetown University Expires: August 9, 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
December 6, 2011 February 6, 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-09 draft-ietf-sipclf-problem-statement-10
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
system. The Session Initiation Protocol does not have a common log system. The Session Initiation Protocol (SIP) does not have a common
format, and as a result, each server supports a distinct log format log format, and as a result, each server supports a distinct log
that makes it unnecessarily complex to produce tools to do trend format that makes it unnecessarily complex to produce tools to do
analysis and security detection. We propose a common log file format trend analysis and security detection. We propose a common log file
for SIP servers that can be used uniformly by user agents, proxies, format for SIP servers that can be used uniformly by user agents,
registrars, redirect servers as well as back-to-back user agents. proxies, registrars, redirect servers as well as back-to-back user
agents.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 June 8, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problem statement . . . . . . . . . . . . . . . . . . . . . . 4 3. Problem statement . . . . . . . . . . . . . . . . . . . . . . 5
4. What SIP CLF is and what it is not . . . . . . . . . . . . . . 4 4. What SIP CLF is and what it is not . . . . . . . . . . . . . . 5
5. Alternative approaches to SIP CLF . . . . . . . . . . . . . . 5 5. Alternative approaches to SIP CLF . . . . . . . . . . . . . . 6
5.1. SIP CLF and CDRs . . . . . . . . . . . . . . . . . . . . . 5 5.1. SIP CLF and CDRs . . . . . . . . . . . . . . . . . . . . . 6
5.2. SIP CLF and Wireshark packet capture . . . . . . . . . . . 6 5.2. SIP CLF and Wireshark packet capture . . . . . . . . . . . 7
6. Motivation and use cases . . . . . . . . . . . . . . . . . . . 6 6. Motivation and use cases . . . . . . . . . . . . . . . . . . . 8
7. Challenges in establishing a SIP CLF . . . . . . . . . . . . . 8 7. Challenges in establishing a SIP CLF . . . . . . . . . . . . . 9
8. Data model . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. Data model . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. SIP CLF mandatory fields . . . . . . . . . . . . . . . . . 10 8.1. SIP CLF mandatory fields . . . . . . . . . . . . . . . . . 11
8.2. Mandatory fields and SIP entities . . . . . . . . . . . . 12 8.2. Mandatory fields and SIP entities . . . . . . . . . . . . 13
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. UAC registration . . . . . . . . . . . . . . . . . . . . . 13 9.1. UAC registration . . . . . . . . . . . . . . . . . . . . . 15
9.2. Direct call between Alice and Bob . . . . . . . . . . . . 15 9.2. Direct call between Alice and Bob . . . . . . . . . . . . 16
9.3. Single downstream branch call . . . . . . . . . . . . . . 16 9.3. Single downstream branch call . . . . . . . . . . . . . . 18
9.4. Forked call . . . . . . . . . . . . . . . . . . . . . . . 22 9.4. Forked call . . . . . . . . . . . . . . . . . . . . . . . 23
10. Security Considerations . . . . . . . . . . . . . . . . . . . 30 10. Security Considerations . . . . . . . . . . . . . . . . . . . 31
11. Operational guidance . . . . . . . . . . . . . . . . . . . . . 31 11. Operational guidance . . . . . . . . . . . . . . . . . . . . . 33
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
14.1. Normative References . . . . . . . . . . . . . . . . . . . 32 14.1. Normative References . . . . . . . . . . . . . . . . . . . 34
14.2. Informative References . . . . . . . . . . . . . . . . . . 32 14.2. Informative References . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
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 4, line 20 skipping to change at page 5, line 20
status: The HTTP status code returned to the client. status: The HTTP status code returned to the client.
bytes: The content-length of the document transferred. bytes: The content-length of the document transferred.
The inspiration for the SIP CLF is the Apache CLF. However, the The inspiration for the SIP CLF is the Apache CLF. However, the
state machinery for a HTTP transaction is much simpler than that of state machinery for a HTTP transaction is much simpler than that of
the SIP transaction (as evidenced in Section 7). The SIP CLF needs the SIP transaction (as evidenced in Section 7). The SIP CLF needs
to do considerably more. to do considerably more.
This document outlines the problem statement that argues for a SIP
CLF. In addition, it provides a data 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 3. Problem statement
The Session Initiation Protocol [RFC3261](SIP) 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 Currently, if these entities are capable of producing a log file of
the transactions being handled by them, the log files are produced in the transactions being handled by them, the log files are produced in
a proprietary format. The result of multiplicity of the log file a proprietary format. The result of multiplicity of the log file
formats is the inability of the support staff to easily trace a call 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 from one entity to another, or even to craft common tools that will
perform trend analysis, debugging and troubleshooting problems perform trend analysis, debugging and troubleshooting problems
uniformly across the SIP entities of multiple vendors. uniformly across the SIP entities of multiple vendors.
SIP does not currently have a CLF format and this document serves to SIP does not currently have a common log format and this document
provide the rationale to establish a SIP CLF and identifies the serves to provide the rationale to establish a SIP CLF and identifies
required minimal information that must appear in any SIP CLF record. the required minimal information that must appear in any SIP CLF
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.
The SIP CLF is simply an easily digestible log of currently occurring The SIP CLF is simply an easily digestible log of currently occurring
events and past transactions. It contains enough information to events and past transactions. It contains enough information to
allow humans and automata to derive relationships between discrete allow humans and automata to derive relationships between discrete
transactions handled at a SIP entity or to search for a certain transactions handled at a SIP entity or to search for a certain
dialog or a related set of transactions. dialog or a related set of transactions.
skipping to change at page 5, line 19 skipping to change at page 6, line 28
enterprises will bill customers based on SIP CLF. The SIP CLF enterprises will bill customers based on SIP CLF. The SIP CLF
records events at the signaling layer only and does not attempt to records events at the signaling layer only and does not attempt to
correlate the veracity of these events with the media layer. Thus, correlate the veracity of these events with the media layer. Thus,
it cannot be used to trigger customer billing. it cannot be used to trigger customer billing.
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
intercept.
5. Alternative approaches to SIP CLF 5. Alternative approaches to SIP CLF
It is perhaps tempting to consider other approaches --- which though It is perhaps tempting to consider other approaches --- which though
not standardized, are in wide enough use in networks today --- to not standardized, are in wide enough use in networks today --- to
determine whether or not a SIP CLF would benefit a SIP network determine whether or not a SIP CLF would benefit a SIP network
consisting of multi-vendor products. The two existing approaches consisting of multi-vendor products. The two existing approaches
that approximate what SIP CLF does are Call Detail Records (CDRs) and that approximate what SIP CLF does are Call Detail Records (CDRs) and
Wireshark packet sniffing. Wireshark packet sniffing.
5.1. SIP CLF and CDRs 5.1. SIP CLF and CDRs
skipping to change at page 6, line 24 skipping to change at page 7, line 37
not have an interest in generating CDRs, but they will like to have a not have an interest in generating CDRs, but they will like to have a
concise representation of the messages being handled by the SIP concise representation of the messages being handled by the SIP
entities in a common format. entities in a common format.
5.2. SIP CLF and Wireshark packet capture 5.2. SIP CLF and Wireshark packet capture
Wireshark is a popular raw packet capture tool. It contains filters Wireshark is a popular raw packet capture tool. It contains filters
that can understand SIP at the protocol level and break down a that can understand SIP at the protocol level and break down a
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 two it does not suffice to serve in the same capacity as SIP CLF for the
reasons. following reasons:
First, all SIP entities that need to save SIP CLF records would o Using Wireshark will not eliminate the need for agreeing to a
require a Wireshark library for different operating systems and common set of fields to represent a SIP CLF record. This common
configurations to link into. Second, and more importantly, if the understanding is important for interoperability to allow one
SIP messages are exchanged over a TLS-oriented transport, Wireshark implementation to read a log file written by a different
will be unable to decrypt them and render them as individual SIP implementation.
headers. o Using Wireshark would require that the underlying libraries
related to Wireshark and 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),
Wireshark will be unable to decrypt them and render them as
individual SIP headers.
o Using Wireshark and the related packet capture libraries may
imposes a dependency on a third party library.
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 CLF format, each entity will produce output requests. Absent a common log format, each entity will produce
records in a native format making it hard to establish commonality output records in a native format making it hard to establish
for tools that operate on the log file. commonality for tools that operate on the log file.
Writing common tools: A CLF format allows independent tool providers Writing common tools: A common log format allows independent tool
to craft tools and applications that interpret the CLF data to providers to craft tools and applications that interpret the CLF
produce insightful trend analysis and detailed traffic reports. data to produce insightful trend analysis and detailed traffic
The format should be such that it retains the ability to be read reports. The format should be such that it retains the ability to
by humans and processed using traditional Unix text processing be read by humans and processed using traditional Unix text
tools. processing tools.
Session correlation across diverse processing elements: In Session correlation across diverse processing elements: In
operational SIP networks, a request will typically be processed by operational SIP networks, a request will typically be processed by
more than one SIP server. A SIP CLF will allow the network more than one SIP server. A SIP CLF will allow the network
operator to trace the progression of the request (or a set of operator to trace the progression of the request (or a set of
requests) as they traverse through the different servers to requests) as they traverse through the different servers to
establish a concise diagnostic trail of a SIP session. establish a concise diagnostic trail of a SIP session.
Note that tracing the request through a set of servers is Note that tracing the request through a set of servers is
considerably less challenging if all the servers belong to the considerably less challenging if all the servers belong to the
skipping to change at page 7, line 35 skipping to change at page 9, line 12
"Find all messages corresponding to server transaction X, "Find all messages corresponding to server transaction X,
including all forked branches.") including all forked branches.")
Message correlation across dialogs: A SIP CLF can correlate Message correlation across dialogs: A SIP CLF can correlate
transactions that comprise a dialog (e.g., "Find all messages for transactions that comprise a dialog (e.g., "Find all messages for
dialog created by Call-ID C, From tag F and To tag T.") dialog created by Call-ID C, From tag F and To tag T.")
Trend analysis: A SIP CLF allows an administrator to collect data Trend analysis: A SIP CLF allows an administrator to collect data
and spot patterns or trends in the information (e.g., "What is the 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 domain where the most sessions are routed to between 9:00 AM and
12:00 PM?") 1:00 PM?")
Train anomaly detection systems: A SIP CLF will allow for the Train anomaly detection systems: A SIP CLF will allow for the
training of anomaly detection systems that once trained can training of anomaly detection systems that once trained can
monitor the CLF file to trigger an alarm on the subsequent monitor the CLF file to trigger an alarm on the subsequent
deviations from accepted patterns in the data set. Currently, deviations from accepted patterns in the data set. Currently,
anomaly detection systems monitor the network and parse raw anomaly detection systems monitor the network and parse raw
packets that comprise a SIP message -- a process that is packets that comprise a SIP message -- a process that is
unsuitable for anomaly detection systems [rieck2008]. With all unsuitable for anomaly detection systems [rieck2008]. With all
the necessary event data at their disposal, network operations the necessary event data at their disposal, network operations
managers and information technology operation managers are in a managers and information technology operation managers are in a
skipping to change at page 9, line 6 skipping to change at page 10, line 26
ACK is a special method that is associated with an INVITE only. It ACK is a special method that is associated with an INVITE only. It
does not require a response, and furthermore, if it is acknowledging does not require a response, and furthermore, if it is acknowledging
a non-2xx response, then the ACK is considered part of the original a non-2xx response, then the ACK is considered part of the original
INVITE transaction. If it is acknowledging a 2xx-class response, INVITE transaction. If it is acknowledging a 2xx-class response,
then the ACK is a separate transaction consisting of a request only 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 (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, another method that is tied to an INVITE transaction, but unlike ACK,
the CANCEL request elicits a final response. the CANCEL request elicits a final response.
While most requests elicit a response immediately, the INVITE request 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 in SIP can remain in a pending state at a proxy as it forks branches
user agent server while it alerts the user. RFC 3261 [RFC3261] downstream or at a user agent server while it alerts the user.
instructs the server transaction to send a 1xx-class provisional [RFC3261] instructs the server transaction to send a 1xx-class
response if a final response is delayed for more than 200 ms. A SIP provisional response if a final response is delayed for more than 200
CLF log file needs to include such provisional responses because they ms. A SIP CLF log file needs to include such provisional responses
help train automata associated with anomaly detection systems and because they help train automata associated with anomaly detection
provide some positive feedback for a human observer monitoring the systems and provide some positive feedback for a human observer
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 CLF format that supports back-to-back user beneficial to derive a common log format that supports back-to-back
agent (B2BUA) behavior, which may vary considerably depending on the user agent (B2BUA) behavior, which may vary considerably depending on
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 The minimal SIP CLF fields are defined below. Some of these fields
contain URIs. If the URI contains an escaped character (""%" HEX contain URIs [RFC3986]. If the URI contains an escaped character
HEX" mechanism), the escaped character MUST be logged as received. (""%" HEX HEX" mechanism), the escaped character MUST be logged as
The maximum size (in number of bytes) for a SIP CLF field is 4096 received. The maximum size (in number of bytes) for a SIP CLF field
bytes. This limit is the same regardless of whether the SIP CLF is 4096 bytes. This limit is the same regardless of whether the SIP
field is a meta-field (see "Timestamp" and "Directionality" defined CLF field is a meta-field (see "Timestamp" and "Directionality"
below) or a normal SIP header. If the body of the SIP message is to defined below) or a normal SIP header. If the body of the SIP
be logged, it MUST conform to this limit as well. 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
mandatory field list). Optional fields may contain SIP headers or mandatory field list). Optional fields may contain SIP headers or
other elements present in a SIP message (for example, the Reason- other elements present in a SIP message (for example, the Reason-
Phrase element from the Status-Line production rule in RFC 3261 Phrase element from the Status-Line production rule in RFC 3261
[RFC3261]). Optional fields may also contain additional information [RFC3261]). Optional fields may also contain additional information
that a particular vendor desires to log. The specific syntax and that a particular vendor desires to log. The specific syntax and
semantics to be accorded to optional fields MUST be defined by the semantics to be accorded to optional fields MUST be defined by the
specific representation format used to generate the SIP CLF record. specific representation format used to generate the SIP CLF record.
Finally, [I-D.ietf-sipclf-format] is an example of a representation
format draft that provides an ASCII-based encoding scheme.
8.1. SIP CLF mandatory fields 8.1. SIP CLF mandatory fields
The following SIP CLF fields are defined as minimal information that The following SIP CLF fields are defined as minimal information that
MUST appear in any SIP CLF record: MUST appear in any SIP CLF record:
Timestamp - Date and time of the request or response represented as Timestamp - Date and time of the request or response represented as
the number of seconds and milliseconds since the Unix epoch. the number of seconds and milliseconds since the Unix epoch.
Message type - An indicator on whether the SIP message is a request Message type - An indicator on whether the SIP message is a request
or a response. The allowable values for this field are 'R' (for or a response. The allowable values for this field are 'R' (for
skipping to change at page 30, line 16 skipping to change at page 31, line 50
response was generated, and that the pending INVITE returned a 487. 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 The ACK to the final non-2xx response and a 200 to the CANCEL request
complete the exchange on that branch. complete the exchange on that branch.
10. Security Considerations 10. Security Considerations
A log file by its nature reveals both the state of the entity 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 producing it and the nature of the information being logged. To the
extent that this state should not be publicly accessible and that the extent that this state should not be publicly accessible and that the
information is to be considered private, appropriate file and information is to be considered private, appropriate file and
directory permissions attached to the log file should be used. The directory permissions attached to the log file SHOULD be used. It is
following threats may be considered for the log file while it is outside the scope of this document to specify how to protect the log
file while it is stored on disk, however, certain precautions can be
taken. Operators SHOULD consider using common administrative
features such as disk encryption and securing log files [schneier-1].
Operators SHOULD also consider hardening the machine on which the log
file is stored by restricting physical access to the host as well as
restricting access to the file itself. Depending on the specific
operating system and environment, the file and directory permissions
SHOULD be set to be most restrictive such that the file is not
publicly readable and writable and the directory where the file is
stored is not publicly accessible.
The following threats may be considered for the log file while it is
stored: stored:
o An attacker may gain access to view the log file, or may o An attacker may gain access to view the log file, or may
surreptitiously make a copy of the log file for later viewing. surreptitiously make a copy of the log file for later viewing.
o An attacker who is unable to eavesdrop real-time SIP traffic on 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 the network but nonetheless can access the log file, is able to
easily mount reply attack or other attacks that result from easily mount replay attack or other attacks that result from
channel eavesdropping. Encrypting SIP traffic does not help here channel eavesdropping. Encrypting SIP traffic does not help here
because the SIP entity generating the log file would have because the SIP entity generating the log file would have
decrypted the message for processing and subsequent logging. decrypted the message for processing and subsequent logging.
o An attacker may delete parts of --- or indeed, the whole --- file. 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 Public access to the SIP log file creates more of a privacy leak when
the log file while it is stored on disk. However, operators may compared to an adversary eavesdropping cleartext SIP traffic on the
consider using common administrative features such as disk encryption network. If all SIP traffic on a network segment is encrypted, then
and securing log files [schneier-1]. Operators may also consider as noted above, special attention must be directed to the file and
hardening the machine on which the log files are stored by directory permissions associated with the log file to preserve
restricting physical access to the host as well as restricting access privacy such that only a privileged user can access the contents of
to the files themselves. the log file.
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 Transporting SIP CLF files across the network pose special challenges
as well. The following threats may be considered for transferring as well. The following threats may be considered for transferring
log files or while transferring individual log records: log files or while transferring individual log records:
o An attacker may view the records; o An attacker may view the records;
o An attacker may modify the records in transit or insert previously o An attacker may modify the records in transit or insert previously
captured records into the stream; captured records into the stream;
o An attacker may remove records in transit, or may stage a man- in- 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 the-middle attack to deliver a partially or entirely falsified log
file. file.
It is also outside the scope of this document to specify protection It is also outside the scope of this document to specify protection
methods for log files or log records that are being transferred methods for log files or log records that are being transferred
between hosts. However, operators may consider using common security between hosts, however, certain precautions can be taken. Operators
protocols described in [RFC3552] to transfer log files or individual SHOULD require mutual authentication, channel confidentiality and
records. Alternatively, the log file may be transferred through bulk channel integrity while transferring the log file. The use of a
methods that also guarantees integrity, or at least detects and secure shell transport layer protocol [RFC4253] or TLS [RFC5246]
alerts to modification attempts. 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.
The SIP CLF represents the minimum fields that lend themselves to The SIP CLF represents the minimum fields that lend themselves to
trend analysis and serve as information that may be deemed useful. trend analysis and serve as information that may be deemed useful.
Other formats can be defined that include more headers (and the body) Other formats can be defined that include more headers (and the body)
from Section 8.1. However, where to draw a judicial line regarding from Section 8.1. However, where to draw a judicial line regarding
the inclusion of non-mandatory headers can be challenging. Clearly, the inclusion of non-mandatory headers can be challenging. Clearly,
the more information a SIP entity logs, the longer time the logging the more information a SIP entity logs, the longer time the logging
process will take, the more disk space the log entry will consume, process will take, the more disk space the log entry will consume,
and the more potentially sensitive information could be breached. and the more potentially sensitive information could be breached.
Therefore, adequate tradeoffs should be taken in account when logging Therefore, adequate tradeoffs should be taken in account when logging
skipping to change at page 31, line 42 skipping to change at page 33, line 37
reading or writing log files. SIP CLF entries can be unbounded in 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 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 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 log parsers, as a SIP CLF log writers may add one or more extension
fields to the message to be logged. fields to the message to be logged.
11. Operational guidance 11. Operational guidance
SIP CLF log files will take up substantive amount of disk space SIP CLF log files will take up substantive amount of disk space
depending on traffic volume at a processing entity and the amount of depending on traffic volume at a processing entity and the amount of
information being logged. As such, any enterprise using SIP CLF information being logged. As such, any organization using SIP CLF
should establish operational procedures for file rollovers as should establish operational procedures for file rollovers as
appropriate to the needs of the organization. appropriate to the needs of the organization.
Listing such operational guidelines in this document is out of scope Listing such operational guidelines in this document is out of scope
for this work. for this work.
12. IANA Considerations 12. IANA Considerations
This document does not require any considerations from IANA. This document does not require any considerations from IANA.
skipping to change at page 32, line 36 skipping to change at page 34, line 32
14.1. Normative References 14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
14.2. Informative References 14.2. Informative References
[I-D.ietf-sipclf-format] [I-D.ietf-sipclf-format]
Salgueiro, G., Gurbani, V., and A. Roach, "Format for the Salgueiro, G., Gurbani, V., and A. Roach, "Format for the
Session Initiation Protocol (SIP) Common Log Format Session Initiation Protocol (SIP) Common Log Format
(CLF)", draft-ietf-sipclf-format-03 (work in progress), (CLF)", draft-ietf-sipclf-format-05 (work in progress),
October 2011. December 2011.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Text on Security Considerations", BCP 72, RFC 3552, Resource Identifier (URI): Generic Syntax", STD 66,
July 2003. RFC 3986, January 2005.
[RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
Transport Layer Protocol", RFC 4253, January 2006.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[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.
skipping to change at page 33, line 38 skipping to change at page 36, line 4
Email: eburger@standardstrack.com Email: eburger@standardstrack.com
URI: http://www.standardstrack.com URI: http://www.standardstrack.com
Tricha Anjali Tricha Anjali
Illinois Institute of Technology Illinois Institute of Technology
316 Siegel Hall 316 Siegel Hall
Chicago, IL 60616 Chicago, IL 60616
USA USA
Email: tricha@ece.iit.edu Email: tricha@ece.iit.edu
Humberto Abdelnur Humberto Abdelnur
INRIA INRIA
INRIA - Nancy Grant Est INRIA - Nancy Grant Est
Campus Scientifique Campus Scientifique
54506, Vandoeuvre-les-Nancy Cedex 54506, Vandoeuvre-les-Nancy Cedex
France France
Email: Humberto.Abdelnur@loria.fr Email: humbol@gmail.com
Olivier Festor Olivier Festor
INRIA INRIA
INRIA - Nancy Grant Est INRIA - Nancy Grant Est
Campus Scientifique Campus Scientifique
54506, Vandoeuvre-les-Nancy Cedex 54506, Vandoeuvre-les-Nancy Cedex
France France
Email: Olivier.Festor@loria.fr Email: Olivier.Festor@loria.fr
 End of changes. 30 change blocks. 
112 lines changed or deleted 153 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/