Internet Engineering Task Force Sriram Parameswar
Internet Draft Brian Stucker
Nortel Networks
August 2001
Expires February 2002
<draft-spbs-sip-negotiate-00.txt>
The SIP Negotiate Method
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.
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 cite them other than as "work in
progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/lid-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This document is an individual submission to the IETF. Comments
should be directed to the authors.
Abstract
There is a need to negotiate a multitude of parameters, settings,
and algorithms when setting up sessions using Session Initiated
Protocol (SIP). While SIP itself provides mechanisms for
negotiation of these parameters on a per-session basis through the
use of the INVITE method, it does not provide a ready mechanism
for meta-session negotiation. The closest mechanism provided is
the REGISTER method, however, this method is directed towards the
registrar alone, and cannot be used to conduct negotiation of
parameters between any two arbitrary SIP nodes.
Examples of parameters that may need to be negotiated (and thus,
the ready impetus for providing a simple mechanism to handle this)
include: compression algorithms, code book size, message integrity
mechanisms, encryption algorithms, etc. Many of these parameters
are not always eligible for use in an INVITE method, for two
reasons:
Parameswar, Stucker [Page 1]
Internet Draft The SIP Negotiate Method August 2001
- The INVITE method describes the parameters for initiation of
a particular session. Once the session is over, the negotiated
settings (such as the RTP profile used, in the case of SDP)
are invalidated for future re-use. It would be inefficient to
have to renegotiate parameters that are the same from session
to session, or have to transmit large quantities of
persistent data (such as a code book) each time.
- Many meta-session applications (and therefore their attendant
negotiable parameters) are best utilized if they can be
applied for the first message of a session.
An example of this would be header compression. If the INVITE
were compressed, then the header that identifies the type of
compression in use would also be compressed, and therefore
unintelligible (assuming no shim mechanism).
This document seeks to solve these problems by introducing a SIP
extension that allows for meta-session parameters to be negotiated
in a generic manner. This negotiation would take place prior to
session establishment, between any two SIP entities
(User Agents, Proxies etc.).
1 Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 [1]
and indicate requirement levels for compliant SIP guidelines
2 Introduction
SIP sets up multimedia sessions between User Agents. Given the
complexity of these sessions, and the variety of User Agents and
their capabilities, there are several session parameters that need
to be pre-defined or negotiated prior to establishing these
sessions.
There is a real need to have a generic mechanism that will help
negotiate these parameters a-priori. The initial goal was to
establish a generic approach to negotiation, which would be
applicable across all protocols used in the Internet world. Given
the difficulty in coming up with a sufficiently generic approach
that would be acceptable, the authors decided to attack a more
immediate problem in the SIP arena and establish a generic
negotiation mechanism.
This draft does not describe an extension which may be used
Parameswar, Stucker [Page 2]
Internet Draft The SIP Negotiate Method August 2001
directly; it must be extended by other drafts by defining
payloads (preferably XML based) to perform the actual negotiation.
The result of the negotiation is a key that will be used in
subsequent transactions to maintain negotiation state. This key is
carried either as a shim i.e. between the transport and
application layers (SIP and UDP for example) or as a SIP header
(Key) in further SIP messages.
This new method may be used in both end-to-end and hop-by-hop
scenarios.
2.1. Overview of Operation
In general the network entity that needs to negotiate meta-session
parameters sends a NEGOTIATE with the payload indicating the
offered parameters/algorithms.
The NEGOTIATE follows the offer-answer model as described in
section B.1 of [bis-04], the entity that offers the parameters
must be willing and able to support all parameters in the offer.
The offer is placed in a NEGOTIATE payload. The offer may be
accepted or rejected, in case the offer is accepted the answer
is returned in the payload of a 200 OK. In case of a rejection a
488 or 606 is returned.
UAC UAS
|-----NEGOTIATE---->| Make an offer on one or more session
| | parameters. Negotiate carries Key.
| |
|<-------200--------| Accept offer and key. Key used to
| | maintain negotiation state.
| |
|---INVITE(etc.)--->| Session establishment with
| | negotiated parameters and key.
Negotiations expire and must be refreshed in exactly the same
manner as registrations (see RFC 2543 [1] ).
3.0 NEGOTIATE Method
"NEGOTIATE" is added to the definition of the element "Method" in
the SIP message grammar.
The NEGOTIATE method is used to set up session parameters and
algorithms prior to session establishment.
As with other methods the NEGOTIATE method name is case sensitive.
This document specifies the named extension 'negotiate'.
Parameswar, Stucker [Page 3]
Internet Draft The SIP Negotiate Method August 2001
This feature name is placed in the Proxy-Require, Require,
Supported or Proxy-Supported header in requests; and the Require,
Supported, Unsupported or Proxy-Supported header in responses.
NOTE: The Proxy-Supported header is still under consideration.
Further releases of this document will incorporate/delete headers
as required.
Header Where NEGOTIATE
------ ----- ---------
Accept R o
Accept-Encoding R o
Accept-Language R o
Allow g o
Authorization R o
Call-ID gc m
Contact R m
Contact 1xx -
Contact 2xx m
Contact 3xx -
Contact 4xx -
Contact 5xx -
Contact 6xx -
Content-Encoding e o
Content-Length e o
Content-Type e *
CSeq gc m
Date g o
Encryption g o
Expires g o
From gc m
Hide R o
Max-Forwards R o
Organization g o
Priority R o
Proxy-Authenticate 407 o
Proxy-Authorization R o
Proxy-Require R o
Proxy-Supported g o
Require R o
Retry-After R -
Retry-After 404,480,486 o
Retry-After 503 o
Retry-After 600,603 o
Response-Key R o
Record-Route R o
Route R -
Table 1 Summary of header fields, A-R
Parameswar, Stucker [Page 4]
Internet Draft The SIP Negotiate Method August 2001
Header Where NEGOTIATE
------ ----- ---------
Server r o
Subject R o
Supported g o
Timestamp g o
To gc(1) m
Unsupported 420 o
User-Agent g o
Via gc(2) m
Warning r o
WWW-Authenticate 401 o
Table 2 Summary of header fields, S-Z
3.1 Header Field Support for NEGOTIATE Method
Tables 1 and 2 add a column to tables 4 and 5 in the [rfc2543].
Refer to Section 6 of [1] for a description of the content of the
tables. Note that the rules defined in the enc. and e-e columns
in tables 4 and 5 in [1] also apply to use of the headers in the
NEGOTIATE request and responses to the NEGOTIATE request.
3.2 Responses to the NEGOTIATE Request Method
If a server receives an NEGOTIATE request it MUST send a final
response.
A 200 OK response MUST be sent by a UAS for an NEGOTIATE request
that is successful. The 200 OK MUST carry the key sent in the
original NEGOTIATE (see section 6.0) that is used to maintain
negotiation state.
4.0 New Headers
This table expands on tables 4 and 5 in RFC 2543 [1], by adding
support for the SUBSCRIBE, NOTIFY and NEGOTIATE.
Header field where proxy ACK BYE CAN INV OPT REG SUB NOT NEG
----------------------------------------------------------------
Key g o o o o o o o o m
Parameswar, Stucker [Page 5]
Internet Draft The SIP Negotiate Method August 2001
4.1 "Key" header
The following header is defined for the purposes of this
specification.
Key = [( "Key" | "y" )
(":" key-format)
("=" key-param)]
key-param = 1*( alphanum)
key-format = ( "Header" | "Key32" | "Key8" )
Examples:
Key: Header=ab45c6d2811e4681
y: Key32=1e6f9a33
Key: Key8=2c
4.1.1 Semantics of the Key Header
The role of the Key header is critical to creating a meta-session
parameter sets that reflect the outcome of negotiations between
various end-points. It is used to identify the resultant set of
parameters stored at the endpoints after a completed negotiation.
Because SIP does not provide a generic, non-registration, method
of referring to parameters that are kept and used across multiple
sessions; identification of these parameters is requires an
extension to the existing SIP specification in order to work under
all circumstances. This becomes especially important when
parameters cause the general headers of the SIP message to be
unintelligible prior to some type of decoding (ie. decompression,
decryption, etc.).
Additionally, it may be important that a SIP message is routable
without exposing the entire contents of the message itself. This
was identified in SIP. However this requirement may need to take
a back seat to other considerations, for example bandwidth
efficiency concerns, where the contents of the entire message may
not be intelligible. As you can see, this becomes very tricky to
identify which set of meta-session parameters to use to handle any
given message between two endpoints.
As a result, we offer two mechanisms in order to provide a means
by which to transport the Key information: header format, and
shim format. The key is always transported in header format, as
a normal, general SIP header when present in a NEGOTIATE method
transaction. Thereafter, it may be transported in either format
as indicated by in the original NEGOTIATE method.
Parameswar, Stucker [Page 6]
Internet Draft The SIP Negotiate Method August 2001
The key8 is an 8 bit Key and the key32 is a 32 bit Key, and either
maybe transported in a subsequent shim structure. The shims are
carried between the transport protocol (UDP, SCTP etc.) and SIP.
The use of the shim allows the entire SIP message to be treated in
the negotiated manner for example: the entire message may be
encrypted or compressed. The shim allows for the recipient to
perform the requisite decoding based on the negotiated algorithm.
Shims work well when they are negotiated hop-by-hop. However,
there exists a need to transit through a proxy and expose only
enough information for it to route on the message. In such
situations the header format is used. The header format places the
Key in clear text in a SIP message with any other pertinent
information required by a proxy in the clear. Thus end-to-end
negotiations may be performed in networks with intervening proxy
hops.
5.0 Key Generation
Keys must be relatively unique, and therefore must be generated
using an algorithm with distinct enough inputs to ensure that a
1-to-1 relationship exists between any single endpoint and the key
that maps to that endpoint. Keys are also symmetric. Meaning that
both endpoints use the same key value to describe the other
endpoint.
One way of ensuring this is to use an MD5 hash of values pertaining
to both the parties of a NEGOTIATE message. This could then be used
in the case that the key is transported in a header, or distilled
to an acceptable size for the shim in use. In order to provide a
consistent means of generating keys, implementations SHOULD use
the following algorithm:
The TO URL, FROM URL, Call-ID value, and Via Branch value (if
no branch is present, then an alphanumeric 0 should be used
instead) should be converted to upper case, with all
whitespace removed, and then concatenated together to form a
single string. This string should have the MD5 hash algorithm
applied to it, to create the negotiated key. This is the key
that is transported as part of the NEGOTIATE message.
The same callid should NOT be reused between two given
endpoints when sending NEGOTIATEs, in order to reduce the
likelihood that the same MD5 hash is generated. If an endpoint
receives a NEGOTIATE with a key value that already exists,
it should reject the request (with 400 "Bad Request" or
409 "Conflict").
Parameswar, Stucker [Page 7]
Internet Draft The SIP Negotiate Method August 2001
Example:
NEGOTIATE sip:broker@example.com SIP/2.0
Via: SIP/2.0/UDP client.example.com:5060
From: Endpoint <sip:user@client.example.com>;tag=88a7s
To: sip:broker@example.com
Call-ID: 3248543@client.example.com
CSeq: 1 NEGOTIATE
Content-Type: application/xpidf+xml
Content-Length: 120
...
Starter String fed in MD5:
SIP:BROKER@EXAMPLE.COMENDPOINT<SIP:USER@CLIENT.EXAMPLE
.COM>;TAG=88A7S3248543@CLIENT.EXAMPLE.COM0
MD5 Key output (representation):
ab45c6d2811e4681f23513
5.1 Conversion to Key8
When Key8 is used, the negotiated key must be distilled into an
8-bit value in order to fit into the shim properly (thus the term
Key8). This may be done by selecting the 8 most significant bits
of the negotiated key. Note, that this format should only be used
between a VERY small set of user agents, as the potential for key
collision, and subsequent need to recalculate a new callid, and
therefore a new key to try the negotiation again, increases.
5.2 Conversion to Key32
When Key32 is used, the negotiated key must be distilled into a
32-bit value in order to fit into the shim properly (thus the term
Key32). This may be done by selecting the 32 most significant bits
of the negotiated key (in network byte format). In practice a
random 32 bit number is likely to yield similar results.
6.0 Key Transport
6.1 Key Transport By Header
When the Key has been setup to be transported via a general
header, both endpoints continue to send a valid, clear-text, SIP
start line followed immediately by the Key header, which is also
sent as clear text. More of the headers of the message may be in
the clear, but at a minimum these two MUST be readable.
Parameswar, Stucker [Page 8]
Internet Draft The SIP Negotiate Method August 2001
This is done so that intermediary proxies may still be able to
route the request based off of the request URI in the start line,
and still be able to maintain some semblance of context by using
the Key header itself. Since the message data may not be readable
to such proxies, it should use the Key header alone to keep track
of context. This will likely not give enough information for the
proxy to be able to operate if it is call-stated, in which case a
hop-by-hop negotiation should be used so the proxy is able to
operate more completely. Note, that since only the Key header
form of transport has a notion of endpoint context, that the shim
should not be used to keep context alone.
It is recommended to allow the same headers used in the
construction of a key (TO, FROM, CALLID, and the top VIA), plus
the CSEQ to be in the clear in addition to the fields above if an
intermediate proxy is used. This is due to the fact that the key
is only sufficient to keep context in terms of a single
request/response pair, and is very limited in that regard for use
at a proxy.
When meta-session parameters which exhibit hop-by-hop nature are
to be supported - it is strongly recommended that intermediate
proxies insert themselves into the NEGOTIATE request process
(acting like a back-to-back UA) in order to ensure that all
requirements of the proxy are satisfied regardless of the
meta-session settings. This would require proxies to be
cognizant of the NEGOTIATE method and its payload.
6.2 Key Transport By Shim
The key, as stated before, may be sent as part of a shim to the
SIP protocol. This is offered in order to help minimize the
overhead to the message itself, particularly for environments
where every byte counts, and heavy compression is desirable.
This format also allows the entire message to have the meta-
session parameters applied to it, which can be useful in cases
where encryption is desired and all of the headers of the SIP
message must be included.
Additionally, keys must be prepended by a start byte. This is so
a key is not confused with a normal start character for any given
sip message. As a result, the top 6 bits of the first byte are
zeroed out so that no valid ASCII character may result, and the
shim can be detected by way of an illegal character.
6.2.1 Key32 Shim Format
The following shows the format of the Key32 shim (in which the
32-bit key is prepended by a shim start byte). Note that this
format is what is actually placed in all messages post-negotiation
Parameswar, Stucker [Page 9]
Internet Draft The SIP Negotiate Method August 2001
i.e. 32-bit key with start byte.
Byte 0: (MSB->LSB) [0000 00XY]
X = Version bit: Should always be set to zero (0)
Y = Shim Format: 0 = Key32, 1 = Key8.
Byte 1..4 (key)
Example:
0:0000 0000
1:1010 1011
2:0100 0101
3:1100 0110
4:1101 0010
Would be the 5 byte Shim32 representation of the key:
ab45c6d2
6.2.2 Key8 Format
The following shows the format of the Key8 shim (in which the
8-bit key is prepended by a shim start byte). Note that this
format is what is actually placed in all messages post-negotiation
i.e. 38-bit key with start byte.
Byte 0: (MSB->LSB) [0000 00XY]
X = Version bit: Should always be set to zero (0)
Y = Shim Format: 0 = Key32, 1 = Key8.
Byte 1 (key)
Example:
0:0000 0001
1:1010 1011
Would be the 2 byte Shim8 representation of the key:
ab
7.0 NEGOTIATE operation
This section deals with the specifics of how the negotiation
mechanism works.
NEGOTIATE is suitable for use between any two SIP entities i.e they
may be used between User Agents, SIP Proxies, BBUAs in any
Parameswar, Stucker [Page 10]
Internet Draft The SIP Negotiate Method August 2001
combination. Examples include UA to Proxy, Proxy to Proxy, UA to
UA, UA to BBUA etc.
There are no restrictions on when a NEGOTIATE method is sent,
however the authors recommend that if it is used in the middle of
an existing session that the resultant key and parameters NOT be
used in the context of the existing session. They may be used from
the next session onwards.
7.1 Message Body Inclusion
The NEGOTIATE method requires a Message body to carry meaningful
meta-session information. The answer is carried in the 200OK as a
similar message body. With this in mind the authors have make the
following recommendations:
(1) The NEGOTIATE/200 OK payload is in XML.
(2) Multiple NEGOTIATE payloads are permissible in a single
NEGOTIATE, they are enclosed using Multipart MIME.
(3) Body contents are not changed/manipulated by intermediate
proxies.
7.2 Negotiation Duration
It is recommended that the Expires header be used to impose a limit
on the duration of a negotiation. The use of a Key after the expiry
of the imposed time limit will result in a 4xx response (488
recommended). On expiry of the negotiation time limit, the expired
KEY is removed from the list of KEYs maintained.
7.3 Terminating a Negotiation
Either side may terminate a negotiation at any time. The
termination is achieved by sending a NEGOTIATE with the "Expires"
header set to "0." A successful termination will result in a 200 OK
from the other side. In case of Negotiation termination both the
request and response do not contain a message body. When a
negotiation is terminated that KEY is removed from the list of
KEYs maintained.
7.3 Refreshing of Negotiations
A negotiation may be refreshed at any time by the use of the
re-NEGOTIATE mechanism. As with the re-INVITE, it is RECOMMENDED
that re-NEGOTIATE be used only if the negotiated parameters need
to be changed or prior to expiry. The final expiration time is
placed in the Expires header in the response. Note that the
receiver of a NEGOTIATE may increase or decrease the expiry time
- as in rfc243bis-03 section 7.4, this avoids the situation where
Parameswar, Stucker [Page 11]
Internet Draft The SIP Negotiate Method August 2001
the offering party chooses a small expiry time causing frequent
refreshes. In general the behavior of NEGOTIATE shall follow that
of REGISTER in the rfc2543-bis03 section 7.
OPEN ISSUE: Should a mechanism like Min-SE as detailed in
draft-ietf-sip-session-timer-05 be considered? Thus
the initiator of the NEGOTIATE at least has some
control over the lower bound of the expiry.
If no refresh for a negotiation - as identified by the KEY is
received before its expiration time, that KEY is removed from the
list of KEYs maintained.
An interesting point is whether re-NEGOTIATE is performed using
the already negotiated parameters or in clear text, for example
re-NEGOTIATE compressed with the negotiated compression algorithm.
It is our recommendation that a re-NEGOTIATE be treated as a
brand new NEGOTIATION (especially since it may be used to change
existing parameters) and be done in clear text.
8.0 Behavior of SIP User Agents
Depending on the applications requiring the negotiation of a
meta-session parameters and the implementation details of the UAC,
the type transport used could be either Shim or Header (or both).
However, a UAC MUST support the Key header transport format if it
is received.
The particular format of the key should be placed into the message
prior to sending. If a key is received that is not understood by
the recipient (maybe it never negotiated that key), an appropriate
400 class response should be returned to the request so that the
sender of the key can determine that the key is no longer valid
for use.
Additionally, because the NEGOTIATE has an expiry timer associated
with it, a UA MUST continue to allow the key to be used if a
transaction began while the key was still good, however, new
transactions MAY not be allowed to use the key during this period.
8.1 Behavior of SIP Proxy and Redirect Servers
8.1.1 Proxy Server
Unless stated otherwise, the protocol rules for the NEGOTIATE
request at a proxy are identical to those for a BYE request as
specified in [1].
Parameswar, Stucker [Page 12]
Internet Draft The SIP Negotiate Method August 2001
8.1.1.1 Stateless Proxy Server
The case where a stateless proxy server is involved can cause
problems. In particular, the statelessness of the proxy precludes
it from creating meta-session parameters since it has no notion of
transaction, much less session. This means that meta-session
parameters that cause the SIP message headers themselves to become
unroutable by a stateless proxy should be used with care. The only
way around this problem is to explicitly state all of the
meta-session parameters by way of some header that is always
readable by the stateless proxy. For example, in cases where
algorithms such as dynamic compression are employed, this would
involve sending the entire dictionary along with each message,
thereby defeating the whole purpose of the compression. For other
meta-session parameters, this may not pose a similar problem.
However, since this draft seeks to simply provide a method of
negotiation, and does not seek to recommend the particulars of
what is negotiated; it is left up to the implementor to decide
what is appropriate for their particular needs.
It is recommended, that where a stateless proxy is known to
likely exist, that the key be transported via the header mechanism
in order to better ensure that the stateless proxy is able to
correctly route the SIP message (assumes that routing information
is left readable by the stateless proxy).
8.1.1.2 Transparency of the Negotiation
An interesting case exists where a proxy wishes to view
information in subsequent session transactions, but may not support
the NEGOTIATE method, or it's content.
For example, the proxy should forward the NEGOTIATE, even
though it does not understand it, according to RFC 2543. As a
result of the NEGOTIATE, the two UA's decide to compress their SDP
content. Later, an INVITE hits the same proxy, only this time the
SDP is unreadable due to the meta-session parameters setup as part
of the NEGOTIATE. In this case, it may not be able to do it's job
(billing, for instance) because the NEGOTIATE was transparent,
but the effects of the negotiation are not. In this case, the proxy
should not act any differently than it normally would if an INVITE
came in with malformed SDP.
If a proxy cannot transparently process SIP transactions that are
affected by meta-session parameters, they should not simply pass
along a NEGOTIATE, and instead assert itself in order to ensure
that SIP messages passing through it can be processed without
interruption.
Parameswar, Stucker [Page 13]
Internet Draft The SIP Negotiate Method August 2001
One method of doing this would be to act as a back to back user
agent in respect to the NEGOTIATE and it's meta-session parameters.
Another would be to intercept, and reject a NEGOTIATE that contains
parameters that are not acceptable to the proxy. A proxy, however,
MUST never alter the contents of the NEGOTIATE without causing a
new Key header to be generated.
8.1.2 Forking Proxy Server
In the case where a forking proxy server is involved in the
signaling path, such as sending a NEGOTIATE to a user's public
address, which is resolved into a contact list with several
entries, there exists the possibility for confusion on how
to apply the NEGOTIATE across the various contacts.
In particular, depending on the application that is using the
NEGOTIATE to set it's meta-session parameters, the application
may not be able to cope with multiple endpoints using the same
key.
An example of this would be using dynamic compression
where each entity keeping a dictionary to use for compression
is not aware of the dictionaries that are being update on
peer branches. Because of this, the originator of the NEGOTIATE
would wind up having to deal with two separate dynamic dictionaries
that are guaranteed to never be synchronized, causing compression
to intermittently fail.
Another example where no problem exists with forking a NEGOTIATE
would be where a static algorithm is being NEGOTIATED, and
application of that algorithm is entirely optional (thus not every
branch of the NEGOTIATE need accept the negotiation parameters).
This could easily be handled. An example of this would be the use
of a static, well-known, compression algorithm.
Because the problems with forking vary according to the application
that is employing the NEGOTIATE mechanism, it is recommended that
the UAC that initiates the NEGOTIATE request be aware of it's
specifics needs in this regard. If multiple responses are received,
indicating that a proxy forked somewhere, and the UAC's application
cannot handle this, the UAC SHOULD send another NEGOTIATE to the
contacts that it wishes to cancel the unintended negotiation with
the same key value used in the original NEGOTIATE, and an expiry
value of zero.
UAC's SHOULD NOT send a CANCEL in order to cause a negotiation
to be terminated, however UAS's MUST be prepared to receive a
CANCEL for a NEGOTIATE, and handle it as if it were a NEGOTIATE
with an expiry value of zero.
Parameswar, Stucker [Page 14]
Internet Draft The SIP Negotiate Method August 2001
8.1.3 Redirection Server
Unless stated otherwise, the protocol rules for the NEGOTIATE
request at a proxy are identical to those for a BYE request as
specified in [1].
9. Guidelines for extensions making use of NEGOTIATE
It is strongly recommended that prior to designing XML payloads
to use NEGOTIATE, the implementors ensure that a similar
function cannot be performed using existing SIP mechanisms.
The use of NEGOTIATE may be for uni-directional or bi-directional
meta-session information. For example using SCRIBE compression from
UAC to UAS only, and UAS chooses to use ROGER towards the UAC.
The XML payload SHOULD allow for negotiation of directionality.
10. Security Considerations
The worst damage that a mischievous intermediate could do would be
to intercept, and handle a NEGOTIATE as if it were the intended
recipient in order to gain access to information that it might
otherwise not have (encryption key, etc.). For this reason,
implementors should take care in how, and what they choose to
send in a NEGOTIATE or its responses.
Sending an 8-bit encryption key in a NEGOTIATE to be used to
encrypt sensitive information over the SIP signaling path for
the next 10 years, for instance, would be a poor implementation.
In general, the security precautions used to guard against
attacks against the sessions that the NEGOTIATE's meta-session
parameters will apply to SHOULD be applied to the actual
NEGOTIATE itself.
Other types of attacks must also be taken into consideration,
such as an intermediate tampering with the key value (causing
sessions to be potentially compromised), or with the contents
of the NEGOTIATE itself (causing confusion between the endpoints
as to the value of the meta-session parameters). These, however
are no worse than an intermediary scrambling any given piece
of any SIP message, and are therefore, not unique outside of
the amount of time such an attack may cause problems.
OPEN ISSUE: Should a negotiation be authenticated first? That is
should the reply be a 407 with challenge and
negotiation proceeds post authentication? This
is interesting because the NEGOTIATE could be used
to negotiate authentication mechanisms themselves.
Parameswar, Stucker [Page 15]
Internet Draft The SIP Negotiate Method August 2001
10.1 Message integrity and authenticity / Man-in-the-middle Attacks
One of the intended uses for the negotiation mechanism is to set
up authentication and message integrity algorithms. Thus the
NEGOTIATE method itself is not subject to these protections - this
makes the recipient vulnerable to the Man-in-the-middle attacks.
Views are solicited to mitigate this security consideration.
10.2 Denial of service attacks
The recipient of an offer is allowed to increase or decrease the
Expires value of a NEGOTIATE. This provides a measure of
protection against DOS attacks. The Min-SE header issue (see 7.3)
is of relevance here and the authors look for comments in this
area.
11.0 IANA Considerations
An option-tag "negotiate" is defined by this document. According to
[1] must register any new option with the IANA. The authors intend
to do this once the document has a measure of acceptance.
12 Example message flows
This section outlines some example flows to illustrate the use of
the new NEGOTIATE method and Key header.
12.1 Hop-by-Hop Negotiation
UAC Proxy UAS
--- ----- ---
| F1 NEGOTIATE | |
| ----------------------->| |
| F2 200 OK | |
|<------------------------| |
| | F3 NEGOTIATE |
| |------------------------->|
| | F4 200 OK |
| |<-------------------------|
| F5 INVITE | |
|------------------------>| |
| | F6 INVITE |
| |------------------------->|
In the scenario above the UAC wants to negotiate with an
intervening Proxy server, which is typically stateful or a BBUA.
The above also has applicability in wireless networks where the
mobile negotiates several meta-session parameters with the Proxy
Call State/Session Control Function (P-CSCF). It must be noted
Parameswar, Stucker [Page 16]
Internet Draft The SIP Negotiate Method August 2001
that the XML documents carried in the messages below are just an
illustration, and the authors expect XML documents to be defined
that will suit the negotiation process.
In the messages the UAC offers ROGER and SCRIBE as possible
compression mechanisms. The Proxy responds with a 200 OK and picks
SCRIBE. The 200 OK returns the Key sent by the UAC, thus confirming
that the next set of messages may be compressed. Also note that the
negotiation from the Proxy to the UAS is not shown for brevity.
F1 NEGOTIATE UAC->Proxy
NEGOTIATE sip:proxy.visited.example.com SIP/2.0
Via: SIP/2.0/UDP bobmobile.example.com:5060
From: Bob <sip:bob@mobile.example.com>;tag=88a7s
To: Proxy <sip:proxy.visited.example.com>
Key: Header=ab13984bdef
Expires: Fri, 01 Jan 2010 16:00:00 EST
Call-ID: 3248543@bobmobile.example.com
CSeq: 1 NEGOTIATE
Content-Type: application/xml
Content-Length: 120
<?xml version="1.0"?>
<negotiate meta-session-info="compression">
<tuple entity="sip:bob@mobile.example.com" />
<tuple qualifier="ROGER" qualifier="SCRIBE" />
</negotiate>
F2 200 OK Proxy->UAC
SIP/2.0 200 OK
Via: SIP/2.0/UDP proxy.visited.example.com:5060
From: Bob <sip:bob@mobile.example.com>;tag=88a7s
To: Proxy <sip:proxy.visited.example.com>;tag=8321234356
Key: Header=ab13984bdef
Expires: Fri, 01 Jan 2010 16:00:00 EST
Call-ID: 3248543@bobmobile.example.com
CSeq: 1 NEGOTIATE
Contact: <sip:proxy@110.111.112.113>
Content-Type: application/xml
Content-Length: 95
<?xml version="1.0"?>
<negotiate meta-session-info="compression">
<tuple entity="sip:bob@mobile.example.com" />
<tuple qualifier="SCRIBE" />
</negotiate>
F3 and F4 are similar to F1 and F2 respectively and thus not
reproduced. All content after Key in the INVITE (F5) is treated
Parameswar, Stucker [Page 17]
Internet Draft The SIP Negotiate Method August 2001
as compressed and thus not readable.
F5 INVITE UAC->Proxy
INVITE sip:joe.example.com SIP/2.0
Key: Header=ab13984bdef
a14adbe84585abe878693956cde5995affc
994adbeccff9494fa91344ffcdefac9474b
......
......
F6 is not shown.
12.2 End-to-End Negotiation and termination of negotiation
UA1 Proxy UA2
------- ------- -----------
| F1 NEGOTIATE | |
| ----------------------|----------->|
| F2 200 OK | |
|<----------------------|------------|
| | |
| <multiple sessions> | |
| | |
| | |
| F3 NEGOTIATE | |
|<----------------------|------------|
| F4 200 OK | |
|-----------------------|----------->|
This example shows an end to end negotiation, with F1 and
F2 same as above. The example further goes on to show how
the UA2 can terminate the negotiation by sending the NOTIFY
with an Expires value of zero. Note that in this case the
NOTIFY MUST carry the Key and is not carrying the XML payload.
F1 and F2 similar to above except that Proxy simply routes the
methods between UA1 and UA2.
F3 NEGOTIATE UA2->UA1
NEGOTIATE sip:proxy.visited.example.com SIP/2.0
Via: SIP/2.0/UDP bobmobile.example.com:5060
From: Proxy <sip:proxy.visited.example.com>;tag=9345ab
To: Bob <sip:bob@mobile.example.com>
Key: Header; ab13984bdef
Expires: 0
Call-ID: 978585@proxy.visited.example.com
CSeq: 1 NEGOTIATE
Content-Length: 0
Parameswar, Stucker [Page 18]
Internet Draft The SIP Negotiate Method August 2001
F4 200 OK Proxy->UAC
SIP/2.0 200 OK
Via: SIP/2.0/UDP proxy.visited.example.com:5060
From: Proxy <sip:proxy.visited.example.com>;tag=9345ab
To: Bob <sip:bob@mobile.example.com>;tag=83ac6786
Key: Header; ab13984bdef
Expires: 0
Call-ID: 978585@proxy.visited.example.com
CSeq: 1 NEGOTIATE
Contact: <sip:proxy@110.111.112.113>
Content-Length: 0
13. References
[1] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg,
"SIP: Session Initiation Protocol", RFC 2543, March 1999.
[2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg,
"SIP: session initiation protocol" (RFC2543bis-03), Internet
Draft, Internet Engineering Task Force, May 2001.
Work in progress
[3] S.Donovan,J.Rosenberg, "The SIP Session Timer",
draft-ietf-sip-session-timer-05. Work in Progress
[4] B. Hoeneisen, M. Isomaki, K. Kiss, "The SIP Proxy-Supported
header field", Internet Draft, Internet Engineering Task Force,
July 2001.
Work in progress
14. Author's Address
Sriram Parameswar
Nortel Networks
2375 B Glenville Avenue
Richardson, Texas 75083
USA
Email: sriramp@nortelnetworks.com
Brian Stucker
Nortel Networks
2380 Performance Drive
Richardson, Texas 75083
USA
Email: bstucker@nortelnetworks.com