ISPATCH Working Group H. Kaplan
Internet Draft Acme Packet
Intended status: Informational
Expires: October 17, 2010 April 17, 2010
A Session Identifier for the Session Initiation Protocol (SIP)
draft-kaplan-dispatch-session-id-01
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 17, 2010.
Copyright and License 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.
Kaplan Expires October 17, 2010 [Page 1]
Internet-Draft SIP Session Identifier April 2010
Abstract
There is a need for having a globally unique session identifier for
the same SIP session, which can be consistently maintained across
Proxies, B2BUAs and other SIP middle-boxes, for the purpose of
Troubleshooting. This draft proposes a new SIP header to carry such
a value: Session-ID.
Table of Contents
1. Introduction................................................2
1.1. Requirements...........................................3
2. Terminology.................................................4
3. Overview of Operation.......................................4
4. Session-ID Behavior.........................................4
4.1. Generating a Session-ID value..........................4
4.2. UAC Behavior...........................................5
4.3. UAS Behavior...........................................6
4.4. Proxy Behavior.........................................6
4.5. B2BUA Behavior.........................................7
4.5.1 B2BUA Generation of New Session-ID 7
4.5.2 B2BUA Insertion of Saved Session-ID 8
5. Session-ID Migration and Failure Scenarios..................8
6. New 'Session-ID' Header.....................................8
6.1. Augmented BNF Definitions..............................9
7. Example Exchange............................................9
8. Security Considerations.....................................9
8.1. Security considerations for administrators.............9
8.2. Security considerations for Session-ID extensions.....10
9. IANA Considerations........................................10
10. Acknowledgments............................................10
11. References.................................................10
11.1. Normative References..................................10
Author's Address.................................................11
1. Introduction
The SIP [RFC3261] Call-ID header value is a globally unique
identifier, mandatory in all requests/responses, which identifies
SIP messages belonging to the same dialog or registration. It
provides a portion of the SIP message dialog-matching criteria, and
is used in such things as [Replaces] headers and [dialog-events]
package for matching to dialogs, and in [SIP-Identity] and
[Connected-identity] as one of the inputs for signing.
In practice, the Call-ID is often changed by B2BUAs and other such
middle-boxes in the logical end-to-end message path. A B2BUA
logically represents a UAS and UAC, and as such generates a new
Kaplan Expires - October 2010 [Page 2]
Internet-Draft SIP Session Identifier April 2010
Call-ID value for the dialog it creates on its UAC side; in fact for
some B2BUA scenarios the Call-ID must be changed for SIP to function
properly.
At the same time, there is a need for a unique, common, consistent
end-to-end identifier to help troubleshoot SIP sessions and message-
flows as they cross SIP nodes. Troubleshooting is more complicated
if multiple legs of the session are on different sides of B2BUAs,
due to the lack of a common identifier such as a Call-ID to tie the
legs together. Proprietary mechanisms are currently used to achieve
this goal.
Therefore, in order to provide an identifier which will not be
modified/replaced by B2BUAs, this draft proposes a new SIP Header
"Session-ID", and mandatory rules for the value of such a header.
The rules are designed to be such that the value in the Session-ID
header is not considered unsafe, private, or have any property which
would cause B2BUAs to change it. The goal of this draft is to
enable use-cases which need a unique identifier for a given session
which can successfully cross B2BUAs, such as Application Servers,
Softswitches, PBXs, SBCs, Feature Servers, etc.
1.1. Requirements
The following requirements drive the need for Session-ID:
REQ1: It must be possible for an administrator to use the identifier
to identify a set of dialogs which have a direct correlation with
each other such that they represent the same SIP session, with as
high a probability as possible.
REQ2: It must be possible to pass the identifier through SIP B2BUAs,
with as high a probability as possible. This requirement drives the
following requirements:
REQ2a: The identifier must not reveal any information related to any
SIP device or domain identity, including IP Address, port, hostname,
domain name, username, Address-of-Record, MAC address, IP address
family, transport type, etc.
REQ2b: The identifier must not reveal to the receiver of it that the
Call-ID, tags, or any other SIP header or body portion have been
changed by middle-boxes, with as high a probability as possible.
REQ2c: The identifier must not be used for anything at a SIP layer
to change the behavior of the SIP protocol.
Kaplan Expires - October 2010 [Page 3]
Internet-Draft SIP Session Identifier April 2010
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. The
terminology in this document conforms to RFC 2828, "Internet
Security Glossary".
This document uses the terms "header field" and "header field value"
following the definition of those terms in [RFC3261], which are not
interchangeable. The "header field" is the entire SIP header's
contents, including any parameters. The "header field value" is
only the field-value portion, which does not include header
parameters.
3. Overview of Operation
The general concept is that the UAC generating an out-of-dialog
request generates a new, pseudo-random, unique value which remains
constant for the duration of the transaction, any dialog created
from that request, or for a registration. The value is inserted in
a new Session-ID header field defined in this draft. The UAC and
UAS then reflect this header field value in all messages for the
duration of the dialog. In other words, the Session-ID provides a
value similar in nature to Call-ID, except one which crosses B2BUAs
and which has no sensitive information in it.
To aid in migration of deployments, a B2BUA or Proxy MAY also
generate and/or insert the value on behalf of a UAC or UAS, if one
or the other does not support this document's mechanism.
Although the Session-ID concept is similar to the Call-ID, it is not
used for message dialog-matching rules in RFC 3261, nor does it
change the Call-ID usage, nor does it replace the Call-ID value.
Instead this new header field provides an identifier for
troubleshooting uses only.
The format of the Session-ID value is restricted, both to avoid
detection of the system type which generated it, and to keep it a
hexadecimal representation such that it can be stored as a 64-bit
binary value in log records.
4. Session-ID Behavior
4.1. Generating a Session-ID value
This draft mandates the Session-ID header field value be pseudo-
random value encoded as a token string of 16 characters in length,
comprised of the characters of a-f and 0-9 only. In other words, it
Kaplan Expires - October 2010 [Page 4]
Internet-Draft SIP Session Identifier April 2010
can be represented as a 64-bit binary value, encoded as lower-case
hexadecimal ascii.
The algorithm to generate the value is left up to specific
implementations, however it MUST have the following properties:
- The value MUST be unique for each SIP Dialog or Registration,
as described previously.
- The value MUST contain 64 bits of randomness, in order to avoid
global collisions and detecting the vendor type.
- The value MUST NOT contain any fixed character or character
sequence which is the same for all Session-ID values generated
by the same system.
- The value MUST NOT contain any pattern which could reveal the
specific vendor or product type, for a single Session-ID value.
- The value MUST NOT contain any portion which reveals the IP
Address, hostname or domain name in any form.
One way to achieve the above properties is to base the Session-ID
off of the Call-ID value, by using a one-way digest mechanism with a
private key, and encoding the results in hexadecimal ascii. Another
way would be to simply create a random 64-bit number and encode it
in hexadecimal ascii.
Note that if a system needs to pad a value to make the Session-ID
value 16 characters, it would fail to meet the requirements above if
the pad were of a fixed character sequence, or a fixed string
generated from a non-pseudo-random algorithm.
The reason for specifying these properties and the length is to make
it impossible to determine the manufacturer of the device which
generated it by looking at the format or value of a received
Session-ID header field. For example, the theoretically random
"session id" value in SDP origin line has been found to be fairly
vendor-specific in nature, and one can narrow the vendor that
generated the SDP simply by the origin session id value. (In fact,
this drove some SIP intermediaries to modify that SDP field for
"anonymization" purposes)
In order to enable trouble-shooting of in-dialog messages, a
generator needs to remember or re-create the same Session-ID value
for the duration of a given dialog(s). This is described in more
detail in following sections of this document.
4.2. UAC Behavior
The rules for when a UAC generates a new Session-ID value are
similar as those for Call-ID value: a UAC supporting this document's
mechanism MUST generate a new unique Session-ID value whenever it
generates an out-of-dialog request, or for a new Registration. The
Kaplan Expires - October 2010 [Page 5]
Internet-Draft SIP Session Identifier April 2010
UAC MUST re-use the same Session-ID value for in-dialog messages,
and for any out-of-dialog request it retransmits or re-generates in
response to a 3xx, or it re-formulates due to failure responses.
This follows the rules in [RFC3261] for Call-ID generation.
Session-ID values in Registration "refreshes" - REGISTER requests
which are used to update the expiry time but not to register a new
contact - MUST use the same Session-ID value as previous REGISTER
requests. New Registrations, which add or change the Contact URI
for the AoR, but not simply to delete them, MUST use a new Session-
ID value. This follows the behavior of Call-ID per RFC 3261; it is
re-iterated here because some devices incorrectly change their Call-
ID value for every re-Registration, and MUST NOT do the same to the
Session-ID.
The UAC MUST include the Session-ID header field in every SIP
message it transmits.
4.3. UAS Behavior
A UAS compliant with this document MUST copy a received Session-ID
header field in a request, into responses and subsequent upstream
requests sent within the dialog.
If an out-of-dialog request is received without a Session-ID header
field, the UAS SHOULD generate a new one for subsequent use in the
transaction and dialog, as defined for a UAC, and use the same value
in all responses and upstream in-dialog requests for the same
dialog.
4.4. Proxy Behavior
A Proxy MUST NOT remove or modify the Session-ID header field it
receives, if one is in the message. By definition, an RFC 3261
compliant Proxy would not modify or remove such a header.
If the Proxy forks a request, it MUST copy the same Session-ID
header field into all the forked request copies. If the Proxy
recurses requests due to 3xx redirection, or regenerates requests
due to failures, it MUST use the same Session-ID header field as the
original request, just as the UAC does.
If the Proxy locally generates any response or request based on a
received request, including 100 Trying, it MUST insert any received
Session-ID header field from the original request into the response
message it locally creates. This is necessary for troubleshooting
purposes.
Kaplan Expires - October 2010 [Page 6]
Internet-Draft SIP Session Identifier April 2010
A Proxy compliant with this draft MAY generate a new Session-ID or
insert a previously saved one, if and only if none existed in a
received message, following the rules for doing so as a B2BUA
defined later.
4.5. B2BUA Behavior
A B2BUA compliant with this document MUST copy the Session-ID header
field it receives in requests as a UAS into the related requests it
generates as a UAC; and any Session-ID field it receives in
responses as a UAC into the correlated responses it generates as a
UAS.
If the B2BUA forks or creates multiple requests as a UAC, from a
request it received as a UAS, the B2BUA MUST copy the same Session-
ID header field it received into all the forks/requests. If the
B2BUA recurses requests due to 3xx redirection, or regenerates
requests due to failures, it MUST use the same Session-ID field,
just as the UAC does.
If the B2BUA locally generates any response or request based on a
received request, including 100 Trying, it MUST insert any received
Session-ID field from the original request into the response message
it locally creates.
A B2BUA MAY remember the received Session-ID value for the duration
of the transaction and dialog, for the purpose of re-insertion, in
case the far-end does not support this draft.
In all cases, if the SIP message received by a B2BUA contained a
Session-ID header field, a B2BUA compliant with this document MUST
NOT remove, modify or replace it as it "forwards" the message on the
other logical UA "side" of itself.
4.5.1 B2BUA Generation of New Session-ID
If an out-of-dialog request is received by a B2BUA compliant with
this document, and the request does *not* contain a Session-ID
header field, the B2BUA MAY generate a new one. It MUST then insert
it in any requests or responses it generates, as if it had actually
received the new Session-ID from the UAC, following the rules
previously defined for a B2BUA. This allows for a B2BUA to provide
a migration to Session-ID deployment, on behalf of upstream nodes
that do not yet support it. As defined previously, if any received
message already had a Session-ID, a B2BUA compliant with this
document would not replace it.
Kaplan Expires - October 2010 [Page 7]
Internet-Draft SIP Session Identifier April 2010
4.5.2 B2BUA Insertion of Saved Session-ID
If a Session-ID was received in an out-of-dialog request, or the
B2BUA locally generated one because none existed, the B2BUA SHOULD
insert the same Session-ID field into all responses and upstream in-
dialog requests if and only if a Session-ID is not already in them.
This allows for a B2BUA to provide a migration to Session-ID
deployment, on behalf of downstream nodes that do not yet support
it.
5. Session-ID Migration and Failure Scenarios
SIP is already widely deployed on the Internet, and it is
impractical to expect all UAs to be upgraded to support this
document's mechanism in the near future. A solution for gradual
migration is necessary, which this document provides by allowing
B2BUAs or Proxies to perform the Session-ID generator and inserter
role. Even within those device types, it is impractical to expect
all B2BUAs to support this mechanism all at once, or any time in the
near future. Therefore, it is expected that some B2BUAs and/or UAs
will support generating and inserting Session-ID, while others will
not support Session-ID at all.
Due to the varying types of B2BUAs, such as PBXs, SBCs, Application
Servers, Feature Servers, and Softswitches of various flavors, and
the numerous SIP deployment models in use, there are going to be
cases in which Session-ID will fail to be a consistent value for all
related dialogs, or fail to successfully match. The goal of this
draft is to improve troubleshooting of current deployments as much
as possible - not to cover all possible scenarios - and in this
author's opinion that is the best that can be done given the
constraints.
One example is for forked requests: if a UAC which does not support
this mechanism sends a request to a Proxy or B2BUA which also does
not support this mechanism, each fork could reach B2BUAs or UASs
which *do* support this mechanism. In such a case, each of those
forked-to B2BUA/UAS will generate unique Session-IDs and put them in
their responses, leading to two different Session-ID values for the
same related early dialogs temporarily. Typically, the UAC would
eventually only accept one of the dialogs, and only one Session-ID
would remain.
6. New 'Session-ID' Header
This draft adds the "Session-ID" token to the definition of the
element "message-header" in the SIP message grammar. The Session-ID
header is a single-instance header.
Kaplan Expires - October 2010 [Page 8]
Internet-Draft SIP Session Identifier April 2010
6.1. Augmented BNF Definitions
Session-ID = "Session-ID" HCOLON sess-id
*( SEMI generic-param )
sess-id = 16(DIGIT / %x61-66) ;16 chars of [0-9a-f]
NOTE: The sess-id value is technically case-INSENSITIVE, but note
that only lower-case characters are allowed.
See the Security Considerations section for discussion about using
header parameters in Session-ID header fields.
7. Example Exchange
In the following example, Alice initiates a call to Bob. Alice
generates a Session-ID header in the out-of-dialog INVITE.
Alice generates the following: (note: much has been left out for
simplicity)
INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bKnashds10
From: Alice <sip:alice@example.net>;tag=1234567
To: Bob <sip:bob@example.com>
Call-Id: 123456mcmxcix@1.2.3.4
Session-ID: f81d4fae7dec11d0
CSeq: 1 INVITE
Contact: <sip:alice@192.168.1.1>
8. Security Considerations
There are several security considerations surrounding this
document's mechanism.
The Session-ID generation algorithm should provide a reasonably
random 16-character Session-ID value, to avoid collisions, and would
not let one re-create the original Call-ID.
There is no known security issue with viewing or modifying the
Session-ID, other than to hamper troubleshooting efforts.
8.1. Security considerations for administrators
The requirement for the Session-ID is to be an identifier which
cannot be used by a recipient to identify if the Call-ID has been
changed by middle-boxes. As such, a UAS/UAC cannot detect the
original Call-ID, nor whether it has been changed, and thus should
not cause administrators concern to be "passed through".
Kaplan Expires - October 2010 [Page 9]
Internet-Draft SIP Session Identifier April 2010
8.2. Security considerations for Session-ID extensions
In general, B2BUA behavior cannot be dictated by standards. They do
whatever their owners/operators wish them to do, or whatever is
necessary to make their applications work. This document attempts
to normatively specify some B2BUA behavior, by creating a SIP header
value for which the properties are such that B2BUAs should have no
legitimate reason to interfere. This effectively creates a
"promise" that future uses of this Session-ID header field,
including its value *and* any future defined parameters, maintain
this benign property. Any future extensions to the Session-ID
mechanism and header field MUST maintain this property, or else
B2BUAs will begin to modify it again or remove it, and its value
will be lost.
Manufacturers of SIP devices should note that there is no guarantee
that a B2BUA will not inspect the Session-ID header field, and
remove it if it does not comply with this document's value
restrictions. Any Session-ID header parameters MUST be registered
with IANA and documented in IETF RFCs, pursuant to the requirements
of [RFC3968].
9. IANA Considerations
This document asks IANA to register a new SIP header field named
'Session-ID', pursuant to the registration policies for such in
[RFC5727]. This is a single-instance header field, and is
appropriate for any SIP message, of any Method type, in any request
or response.
The ABNF rules for this new header allow for header parameters,
however they must be registered following the rules of [RFC3968], as
required by [RFC5727].
10. Acknowledgments
Thanks to Raphael Coeffic, Bob Penfield, Dale Worley, Paul Kyzivat,
Ian Elz, Marco Stura, Martin Dolly, Martin Huelsemann, and Laura
Liess for their input.
11. References
11.1. Normative 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.
Kaplan Expires - October 2010 [Page 10]
Internet-Draft SIP Session Identifier April 2010
[RFC3968] Camarillo, G., "The Internet Assigned Number Authority
(IANA) Header Field Parameter Registry for the Session
Initiation Protocol (SIP)", RFC 3968, December 2004.
[RFC5727] Peterson, J., Jennings, C., Sparks, R., "Change Process
for the Session Initiation Protocol (SIP) and the Real-time
Applications and Infrastructure Area", RFC 5727, March 2010.
Author's Address
Hadriel Kaplan
Acme Packet
71 Third Ave.
Burlington, MA 01803, USA
Email: hkaplan@acmepacket.com
Kaplan Expires - October 2010 [Page 11]