One document matched: draft-kaplan-sip-session-id-01.txt
Differences from draft-kaplan-sip-session-id-00.txt
SIP Working Group H. Kaplan
Internet Draft Acme Packet
Intended status: Standards Track
Expires: May 30, 2009 November 30, 2008
A Session Identifier for the Session Initiation Protocol (SIP)
draft-kaplan-sip-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/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 May 30, 2009.
Copyright and License Notice
Copyright (c) 2008 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.
Abstract
There are several reasons for having a globally unique session
identifier for the same SIP session, which can be maintained across
B2BUA's and other SIP middle-boxes. This draft proposes a new SIP
header to carry such a value: Session-ID.
Kaplan Expires May 30, 2009 [Page 1]
Internet-Draft SIP Session Identifier November 2008
Table of Contents
1. Introduction..................................................2
1.1. Requirements..............................................3
1.2. Example use-cases for Session-ID..........................4
2. Terminology...................................................5
3. Applicability.................................................5
4. Overview of Operation.........................................5
5. Session-ID Behavior...........................................6
5.1. Generating a Session-ID value.............................6
5.2. UAC Behavior..............................................7
5.3. UAS Behavior..............................................7
5.4. Proxy Behavior............................................7
5.5. B2BUA Behavior............................................8
5.5.1 B2BUA Generation of New Session-ID......................8
5.5.2 B2BUA Insertion of Saved Session-ID.....................9
6. Dialog Matching using Session-ID..............................9
6.1. Changes for Dialog-Matching Mechanisms...................10
7. Session-ID Migration and Failure Scenarios...................10
8. New Header...................................................11
8.1. "Session-ID" header......................................12
8.2. Augmented BNF Definitions................................12
9. Example Exchange.............................................12
10. Security Considerations......................................12
10.1. Security considerations for B2BUA vendors and operators..13
10.2. Security considerations for extensions to the Session-ID.14
11. IANA Considerations..........................................15
12. Acknowledgments..............................................15
13. References...................................................15
13.1. Normative References.....................................15
13.2. Informative References...................................15
Author's Address...................................................16
Acknowledgment.....................................................16
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.
Kaplan Expires - May 2007 [Page 2]
SIP Session Identifier November 2008
Unfortunately, the Call-ID is often changed by B2BUA's and other
such middle-boxes in the end-to-end message path. A B2BUA logically
represents a UAS and UAC, and as such may use a new Call-ID value
for the dialog it creates on its UAC half; but there are several
use-cases for having a common, consistent end-to-end identifier, as
described later in this draft.
There are several reasons the Call-ID value is changed by B2BUA's.
There are security and privacy reasons, since Call-ID values
typically contain UA IP Addresses; some B2BUA's need to change them
to keep track of spiraling dialogs; and some need to change them to
keep track of separate forks. In fact, some people have argued a
B2BUA has no choice but to create a new one, in order to strictly
comply with RFC 3261 as a UAC. In general, B2BUA's modify the Call-
ID value in both directions, "fixing" it to be what each side of the
B2BUA would expect. This works fine if the B2BUA is in the message
path, and knows all SIP message or body contents which use or
reference the value. However for subsequent out-of-dialog requests,
or new SIP uses, a B2BUA often does not or cannot "fix" the value
correctly, for example if it is not traversed.
Therefore, in order to provide an identifier which will not be
modified/replaced by B2BUA's, 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 B2BUA's 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 B2BUA's, and be used for matching
purposes.
1.1. Requirements
The following requirements drive the need for Session-ID:
REQ1: It must be possible 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 for a SIP device to use the identifier in
out-of-dialog requests, to match existing dialogs at B2BUA's and/or
UAS's, if the Call-ID and tags the device believes are correct do
not in fact match, with as high a probability as possible.
REQ3: It must be possible to pass the identifier through B2BUA's,
with as high a probability as possible. This requirement drives the
following requirements:
Kaplan Expires - May 2007 [Page 3]
SIP Session Identifier November 2008
REQ3a: 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.
REQ3b: 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.
One should note that REQ2 and REQ3b are at odds with each other to
some degree, as described in the Security section. Rationale is
given for why B2BUA's should not be concerned with such a
contradiction in the "Security Considerations for B2BUA vendors and
operators" section.
1.2. Example use-cases for Session-ID
The need for a unique identifier is driven by the following use-
cases:
1. Certain SIP applications need to reference dialogs in out-of-
dialog requests at a layer above the SIP message dialog matching
rules, and wish it to work across B2BUA domains. For example,
the SIP Media Control Channel Framework [media-ctrl] needs to
reference a dialog identifier used between a UAC and UAS by a
third party. The mechanism originally used the Call-ID and
remote/local-tags for such matching, but changed due to concerns
over B2BUA's changing them, and now uses a new "cfw-id" SDP
attribute instead which does not rely on the Call-ID value.
2. Multiple RFC 3265 Event packages use the Call-ID value in their
package bodies to reference established sessions, even though
they don't actually need to match a Call-ID per se - and should
work across B2BUA domains. These packages could be updated to
include a Session-ID mechanism as a secondary, optional matching
criteria.
3. Several proposed and documented identity verification mechanisms
need a hard-to-guess dialog identifier for verification. For
example, [RFC4474] and [RFC4916] use the Call-ID header value in
its signature to prevent replay/copy-paste attacks, even though
they do not need a Call-ID value per se; they just need a unique
dialog identifier. Likewise, [draft-derive] wishes to perform a
reverse dialog-verification to verify a caller identity based on
some unique identifier for the dialog; and [draft-pass] creates a
header-parameter to perform something similar.
4. Some SIP service providers implement call admission control (CAC)
for bandwidth, and only allow SIP INVITE requests if the network
has sufficient bandwidth for the given SDP. If a call request is
forked by B2BUA's, or crosses them, however, the CAC model treats
Kaplan Expires - May 2007 [Page 4]
SIP Session Identifier November 2008
each fork as a separate call because there is no identifier to
tie them together. This leads to rejected forks due to CAC, when
they should have been allowed to proceed. A common identifier
would provide the necessary information to correlate the forked
requests. Currently proprietary SIP headers are used for this
purpose.
5. Troubleshooting SIP sessions is more complicated if multiple legs
of the session are on different sides of B2BUA's, due to the lack
of a common identifier to tie the legs together. Currently
proprietary mechanisms are used to achieve this.
6. When SIP requests cross B2BUA's, the only form of loop detection
that will stop a loop is the Max-Forwards hop-count limit being
reached (value reaching zero). Via header values are removed by
B2BUA's, so both spirals and simple loops cannot be detected by
Via branch-parameter matching. A Session-ID value could be used
to detect loops by imposing a limit on the number of times the
same Session-ID can cross the same B2BUA. This would be a local
decision, and an optimization, but it would be useful.
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".
3. Applicability
This draft proposes a new SIP header for all requests and responses.
4. 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 the request, or a registration. The value is based on the
rules for creating a fixed-length pseudo-random value, and is
inserted in a new Session-ID header defined in this draft. The UAC
and UAS then reflect this value in all messages for the duration of
the dialog.
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.
Kaplan Expires - May 2007 [Page 5]
SIP Session Identifier November 2008
This Session-ID 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 value provides an identifier
for other uses, some of which are similar to Call-ID.
In particular, a UA or B2BUA can provide a matching function whereby
out-of-dialog requests are "matched" to established dialogs using
the Session-ID value and remote-tag, as defined later in this
document. This is to enable SIP uses of Call-ID matching for out-
of-dialog requests to function in scenarios they cannot today, for
example in specific scenarios with the dialog-events package. The
specific mechanisms to be enabled for such use are to be documented
separately, in updates to their relevant RFCs as appropriate. [Open
issue: or should we document and extend them in this document?]
5. Session-ID Behavior
5.1. Generating a Session-ID value
This draft proposes the Session-ID header value be generated based
on a defined hash mechanism for creating a 128-bit pseudo-random
value, and encode it as its lower-case hex representation. The
reason for specifying the mechanism, and its length, is to make it
impossible to determine the manufacturer of the device which
generated it by looking at its format or value. 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 SBC's to modify that SDP field for
"anonymization" purposes)
In order to perform matching of out-of-dialog requests to
established dialogs, for example for [dialog-events], a generator
and B2BUA's need to remember the Session-ID for a given dialog(s).
For example by having a Session-ID-to-dialogs table. This is
described in more detail in following sections of this document.
The Session-ID value is generated by taking the Call-ID header
value, and SHA-1 hashing it based on [RFC2104] HMAC using a locally
generated pseudo-random 128-bit system secret key, to create a 128-
bit resultant HMAC value. The secret key makes the resultant HMAC
value not re-creatable by other parties, which is necessary to
prevent detection of Call-ID's being changed, as required by Req-3b.
Otherwise, middle-boxes may have motivation to remove the Session-ID
in order to hide the fact that they changed the Call-ID.
Per [RFC2104], the algorithm is thus HMAC-SHA-1-128(Call-ID_value,
secret_key), and the 128-bit result is encoded using lowercase
Kaplan Expires - May 2007 [Page 6]
SIP Session Identifier November 2008
alphanumeric hex representation, as defined in the ABNF section of
this document.
5.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 draft MUST
generate a *new* unique Session-ID value whenever it generates an
out-of-dialog request, or for a new Registration. The UAC MUST re-
use the same Session-ID 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 and
thus the hash mechanism should by definition produce the correct
Session-ID; 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 value in every SIP
message it transmits. This serves both a troubleshooting purpose,
and may be used in specific identity verification mechanisms which
are beyond the scope of this draft.
5.3. UAS Behavior
A UAS compliant with this document MUST copy a received Session-ID
value 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 value in
all responses and upstream in-dialog requests.
5.4. Proxy Behavior
A Proxy MUST NOT remove or modify the Session-ID header values it
receives, if one is in the message. By definition, an RFC 3261
compliant Proxy would not modify or remove such a header.
Kaplan Expires - May 2007 [Page 7]
SIP Session Identifier November 2008
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
message, following the rules for doing so as a B2BUA defined later.
If the Proxy forks a request, it MUST copy the same Session-ID value
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 value 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 value from the original request into the message it
locally creates. This serves both a troubleshooting purpose, and
may be used in specific identity verification mechanisms which are
beyond the scope of this draft.
5.5. B2BUA Behavior
A B2BUA compliant with this document MUST copy the Session-ID it
receives in requests as a UAS into the related requests it generates
as a UAC; and any Session-ID value 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 value 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 value,
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 value from the original request into the message it
locally creates. A B2BUA MUST remember the received Session-ID
value for the duration of the transaction and dialog, for the
purpose of re-insertion, and for the purpose of matching out-of-
dialog requests to established dialogs on the B2BUA as defined
later.
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 the header value.
5.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 MUST generate a new Session-ID. It MUST then
Kaplan Expires - May 2007 [Page 8]
SIP Session Identifier November 2008
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.
5.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 value 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.
6. Dialog Matching using Session-ID
A UAC, UAS or B2BUA complying with this document MAY perform a
dialog matching function, whereby out-of-dialog requests are matched
to established dialogs using the Session-ID value. For example, if
a UA receives a Replaces header in an out-of-dialog INVITE, and the
Call-ID in the Replaces header value does not match any dialog the
UA knows about, it could attempt to match an embedded Session-ID
value in the Replaces header to its Session-ID table.
For the matching function to work, the UA/B2BUA needs to have stored
the Session-ID values for all dialogs. How they do so is
implementation specific, but the UA/B2BUA needs to be able to
internally find any and all dialogs for a given Session-ID value.
One problem with performing matching in this way is that the B2BUA
will not know which specific dialog a Session-ID value refers to. A
B2BUA has at least a UAC and UAS dialog associated with the same
Session-ID value; if the Call-ID and tags don't match one, then it
cannot be sure which one the UAC sending the out-of-dialog request
wishes to match with.
A UA or B2BUA which performs the matching function MUST only match a
Session-ID to an established dialog if the requested remote-tag
matching criteria also matches, for uses that have such a tag
identifier (which are all known uses except the In-Reply-To header
of [RFC3261]).
Note the "remote-tag" is the term as defined by [RFC3261]: for a UAC
it is the to-tag received from a dialog-creating response, while for
Kaplan Expires - May 2007 [Page 9]
SIP Session Identifier November 2008
a UAS it is the from-tag received in a dialog-creating request. For
a B2BUA, it is those same tags on its respective UAC and UAS sides.
Otherwise, if no dialog is found with the same Session-ID and
remote-tag value, the UA/B2BUA MUST process the request as if it did
not find a match. For example, if the Replaces header field has an
embedded Session-ID value that matches a dialog set known to the
UAC, but the Replaces "from-tag" parameter value does not match a
remote-tag for any of the dialogs in the set, the UAC would reject
the request with a 481 Call/Transaction Does Not Exist response.
Note this means that middle-boxes in an end-to-end path which change
the original tags would sometimes prevent upstream/downstream
UA's/B2BUA's from matching dialogs successfully with this new
mechanism. Mandating middle-boxes to not change tags is beyond the
scope of this document.
6.1. Changes for Dialog-Matching Mechanisms
This document does not update the current SIP extensions which need
dialog-matching for out-of-dialog requests. It is expected that a
separate document will be created to do so.
[Open issue: should this doc do it?]
The following are the known list of currently defined uses which
need this property:
o In-Reply-To [RFC3261]
o Replaces [Replaces]
o Join [Join]
o Target-Dialog [Target-Dialog]
o Event Package for INVITE-Initiated Dialog [dialog-events]
o Event Package for Conference State [RFC4575]
o Event Package for Key Press Stimulus [KPML]
[Open issue: should we give guidance on future extensions which need
matching?]
[Note: one possible way to do so would be to make the new out-of-
dialog message use the same Session-ID header value in the message
itself for its Session-ID value; in other words doing a transfer
could keep the same Session-ID for the new call]
7. Session-ID Migration and Failure Scenarios
SIP is already widely deployed on the Internet, and it is
impractical to expect all UA's 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
B2BUA's or Proxies to perform the Session-ID generator and inserter
role. Even within those device types, it is impractical to expect
Kaplan Expires - May 2007 [Page 10]
SIP Session Identifier November 2008
all B2BUA's to support this mechanism all at once, or any time in
the near future. Therefore, it is expected that some B2BUA's and/or
UA's 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 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 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.
For example, if the UAC or UAS do not support this draft's
mechanism, there is the possibility for out-of-dialog requests which
need the matching behavior to fail if they reach the UAC or UAS
without crossing a B2BUA which supports the matching mechanism. And
the more hops away from the UAC/UAS such matching B2BUA's are, the
more likely such a case will occur.
Another 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 B2BUA's
or UAS's 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 dialogs temporarily. Eventually the UAC would
only accept one of the dialogs (typically), and only one Session-ID
would remain.
These are just some examples; the number of possible scenarios
involving devices which do not support this mechanism is unbounded.
However the Session-ID mechanism, as defined in this document,
should not cause any of them to fail if they would not have already
failed without Session-ID, and should cause some of them to succeed
that would otherwise have failed.
8. New Header
The following table updates Table 2 in [RFC3261] and other defined
extensions.
Hdr-field when ACK BYE CAN INV OPT REG PRA INF REF UPD SUB NOT MSG
-----------------------------------------------------------------
Session-ID R m m m m m m m m m m m m m
Session-ID r m m m m m m m m m m m m m
Kaplan Expires - May 2007 [Page 11]
SIP Session Identifier November 2008
8.1. "Session-ID" header
This draft proposes "Session-ID" to be added to the definition of
the element "message-header" in the SIP message grammar.
The Session-ID header is a single-instance header.
The compact form of the header is requested to be: h
[for "Hide from middleboxes" or "Help us help you" :) ]
8.2. Augmented BNF Definitions
Session-ID = "Session-ID" HCOLON sess-id
*( SEMI generic-param )
sess-id = 32(DIGIT / %x61-7A) ; 32 chars of [0-9a-z]
NOTE: The sess-id value is case-SENSITIVE, just as Call-ID is,
however only lower-case characters are defined and allowed.
See the Security Considerations section for discussion about using
header parameters in Session-ID header fields.
9. 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: f81d4fae7dec11d0a76500a0c91e6bf6
CSeq: 1 INVITE
Contact: <sip:alice@192.168.1.1>
10. Security Considerations
There are several security considerations surrounding this
document's mechanism.
The Session-ID's value is created from the Call-ID using a hashing
mechanism based on [RFC2104], using SHA-1 and a secret key known
only to the system generating the Session-ID. Because the algorithm
is defined in this document, it should be fairly secure from
Kaplan Expires - May 2007 [Page 12]
SIP Session Identifier November 2008
detecting the generator of the Session-ID, in terms of manufacturer
or code base.
The Session-ID generation algorithm should provide a reasonably
random 128-bit Session-ID value, to avoid collisions, and would not
let one re-create the original Call-ID. The secret key MUST only be
used for the Session-ID mechanism, in case a weakness is found which
reveals the key. One such weakness may be that a UAC generates one
or more Call-ID's which have a property that makes determining the
key more likely.
Using a Session-ID value for out-of-dialog request matching criteria
is potentially not as secure as using the Call-ID and tags. For
one, Call-ID and tag values are potentially harder to guess due to
their undefined lengths, depending on their generating systems. But
more importantly, dialog matching mechanisms performed by SIP
extensions typically use the Call-ID and both local and remote tags
for matching. If only the Session-ID value were used for matching,
for example, then all recipients of forked requests would have
sufficient information to successfully match the dialogs. While
some people may consider this a "feature" not a weakness, this
document assumes otherwise and requires both the Session-ID and
remote-tag to match, preventing any recipient but the matching
forked one from being able to use it. But it does not use the
local-tag, in order to increase likelihood of success.
[Open issue: is that a problem? I don't think so, but it needs
scrutiny]
10.1. Security considerations for B2BUA vendors and operators
One of the requirements 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. That requirement is somewhat
contradictory with the requirement to be usable for out-of-dialog
matching purposes, because clearly a UA/B2BUA which performs the
matching mechanism in this draft would detect the Call-ID and/or
local-tag are not correct while the Session-ID and remote-tag are,
and thus surmise that a middle-box had changed the Call-ID and/or
local-tag. Some future mechanism similar to dialog-event package
could also perform a check to see if the Call-ID had been changed by
first trying only the Call-ID for a match, and upon failure trying
the Session-ID, and if it succeeds they could surmise the Call-ID
had been changed by a middle-box.
B2BUA vendors and operators should note, however, that the only time
a Call-ID would be changed by a B2BUA such that an out-of-dialog
request using it does not successfully match is when a UA could send
an out-of-dialog request to some node other than that B2BUA; if a
B2BUA cannot or does not wish to prevent that from happening, then a
Kaplan Expires - May 2007 [Page 13]
SIP Session Identifier November 2008
change could be detected even *without* the Session-ID, simply by
assuming a failed Call-ID match means a middle-box changed it.
Therefore, Session-ID does not create a new "leak" of information
that a Call-ID was changed by a B2BUA. To the contrary, it enables
scenarios with such "leaks" to fix themselves, so that they do not
create failed requests.
If operators of the B2BUAs actually *want* such cases to fail, then
they will choose to do whatever they want to make that happen, and
nothing can stop them. If they do so by removing or changing the
Session-ID, they would simply not be compliant with this document.
It would be preferable for them to leave the Session-ID alone, and
prevent B2BUA circumvention in a different way. Other techniques
exist for doing so, but are beyond the scope of this draft.
Furthermore, it is highly unlikely that SIP users or vendors would
perform such a Call-ID check for anything but beneficial reasons,
for example for troubleshooting purposes or to make the application
work; it would be foolish to do otherwise because so many devices in
modern deployments modify the Call-ID value, that it cannot
reasonably be considered malicious for middle-boxes modify it.
10.2. Security considerations for extensions to the Session-ID
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 B2BUA behavior, by creating a SIP header
value for which the properties are such that B2BUA's 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* future defined parameters, maintain this
benign property. Any future extensions to the Session-ID mechanism
and header field MUST maintain this property, or else B2BUA's 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. Because of this, any uses for Session-ID header
parameters MUST be documented in RFCs.
Kaplan Expires - May 2007 [Page 14]
SIP Session Identifier November 2008
11. IANA Considerations
This document asks IANA for a new SIP header field, in long and
compact form.
12. Acknowledgments
Thanks to Raphael Coeffic, Bob Penfield, Dale Worley, Paul Kyzivat,
and Ian Elz for their input. The list of current uses which need
matching was taken from [draft-transparent-b2bua].
13. References
13.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.
[RFC2104] Krawczyk, H., Bellare, M., Canetti, R., "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, February 1997.
13.2. Informative References
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
Event Notification", RFC 3265, June 2002
[SIP-Identity] Peterson, J., Jennings, C., "Enhancements for
Authenticated Identity Management in the Session Initiation
Protocol (SIP)", RFC 4474, August 2006.
[Connected-Identity] Elwell, J., "Connected Identity in the Session
Initiation Protocol (SIP)", RFC 4916, June 2007.
[Replaces] Elwell, J., "The Session Initiation Protocol (SIP)
"Replaces" Header", RFC 3891, September 2004.
[Join] Mahy, R. and D. Petrie, "The Session Initiation Protocol
(SIP) "Join" Header", RFC 3911, October 2004.
[Target-Dialog] Rosenberg, J., "Request Authorization through
Dialog Identification in the Session Initiation Protocol
(SIP)", RFC 4538, June 2006.
[dialog-events] Elwell, J., "The Session Initiation Protocol (SIP)
"Replaces" Header", RFC 3891, September 2004.
Kaplan Expires - May 2007 [Page 15]
SIP Session Identifier November 2008
[RFC4575] Rosenberg, J., Schulzrinne, H., and O. Orit, "A Session
Initiation Protocol (SIP) Event Package for Conference State",
RFC 4575, August 2006.
[KPML] Burger, E. and M. Dolly, "A Session Initiation Protocol
(SIP) Event Package for Key Press Stimulus (KPML)", RFC 4730,
November 2006.
[RFC4122] Leach, P., Mealling, M., Salz, R., "A Universally Unique
IDentifier (UUID) URN Namespace", RFC 4122, July 2005.
[media-ctrl] Boulton, C., Melanchuk, T., McGlashan, S., "Media
Control Channel Framework", draft-ietf-mediactrl-sip-control-
framework-06, October 2008.
[draft-derive] Kuthan, J., Sisalem, D., Coeffic, R., Pascual V.,
"Dialog Event foR Identity VErification", draft-kuthan-sip-
derive-00, October 2008.
[draft-pass] Kaplan, H., "Private Extensions to the Session
Initiation Protocol (SIP) for Asserter Identification within
Trusted Networks", draft-kaplan-sip-asserter-identity-00, July
2008.
[draft-transparent-b2bua] Marjou, X., Elz, I., Musgrave, P., "Best
Current Practices for a Session Initiation Protocol (SIP)
Transparent Back-To-Back User-Agent (B2BUA)", draft-marjou-
sipping-b2bua-01, July 2007.
Author's Address
Hadriel Kaplan
Acme Packet
71 Third Ave.
Burlington, MA 01803, USA
Email: hkaplan@acmepacket.com
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Kaplan Expires - May 2007 [Page 16]
| PAFTECH AB 2003-2026 | 2026-04-24 02:44:06 |