MMUSIC Working Group G. Camarillo
Internet-Draft Ericsson
Expires: November 30, 2004 J. Rosenberg
dynamicsoft
June 1, 2004
The sdp-anat Session Initiation Protocol (SIP) Option-Tag
draft-camarillo-sip-anat-option-tag-00.txt
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
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 November 30, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document defines the sdp-anat SIP option-tag. The presence of
this option-tag in a Supported header field indicates support for the
SDP grouping framework and for the ANAT (Alternative Network Address
Types) semantics.
Camarillo & Rosenberg Expires November 30, 2004 [Page 1]
Internet-Draft The sdp-anat Option-Tag June 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The sdp-anat Option-Tag . . . . . . . . . . . . . . . . . . . 3
4. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 3
4.1 Answerer Supports All the Network Types Offered . . . . . 3
4.2 Answerer does not Support All the Network Types Offered . 4
4.3 OPTIONS Requests . . . . . . . . . . . . . . . . . . . . . 4
5. Option-Tag Usage . . . . . . . . . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
8. Normative References . . . . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 6
Intellectual Property and Copyright Statements . . . . . . . . 7
Camarillo & Rosenberg Expires November 30, 2004 [Page 2]
Internet-Draft The sdp-anat Option-Tag June 2004
1. Introduction
SIP [3] UAs (User Agents) with support for different network types
can use the ANAT semantics [6] of the SDP [2] grouping framework [5]
to offer alterative addresses of different types. For example, an
IPv4/IPv6 dual stack SIP UA following the offer/answer model [4]
would generate an offer grouping its IPv6 address and its IPv4
address using ANAT.
If the recipient of an offer that uses ANAT supports the ANAT
semantics, everything works as described in the ANAT specification
[6]. Nevertheless, the recipient of such an offer (i.e., the
answerer) may not support ANAT. In this case, different
implementations of the answerer would react in different ways. This
document discusses the answerer behaviors that are most likely to be
found and defines the sdp-anat SIP option-tag.
The sdp-anat option-tag can be used to ensure that an offer using
ANAT is not processed by answerers without support for ANAT. This
option-tag can also be used to explicitly discover the capabilities
of a UA (i.e., whether or not it supports ANAT).
2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in BCP 14, RFC 2119 [1] and indicate requirement levels for
compliant implementations.
3. The sdp-anat Option-Tag
We define the option-tag sdp-anat for use in the Require and
Supported SIP [3] header fields. SIP user agents that place this
option-tag in a Supported header field understand the ANAT semantics
as defined in [6].
4. Backward Compatibility
Answerers without support for ANAT will react in different ways on
reception of an offer using ANAT. We expect that, even under the same
circumstances, different implementations behave in different ways. In
this section, we analyze these behaviors (i.e., the next subsections
assume that the answerer does not support ANAT).
4.1 Answerer Supports All the Network Types Offered
If the answerer supports all the network types in the offer, it may
Camarillo & Rosenberg Expires November 30, 2004 [Page 3]
Internet-Draft The sdp-anat Option-Tag June 2004
accept the offer and establish all the media streams in it. This
behavior is not what the offerer expected because it results in too
many media streams being established. If the answerer starts sending
media over all of them, the result may be a high bandwidth usage.
The answerer may also reject the offer, because although it supports
all the network types in it, the answerer may not support them
simultaneously. The error response sent by the answerer will most
likely not be explicit enough about the situation. So, the offerer
will not understand what went wrong.
In the previous scenarios, the sdp-anat option-tag would avoid the
establishment of too many media streams and would allow the answerer
to explicitly inform the offerer that the answerer did not support
ANAT.
4.2 Answerer does not Support All the Network Types Offered
If the answerer does not support all the network types in the offer,
it may only establish the media streams whose address types
understands (it would reject the rest). This would be an acceptable
behavior from the offerer's point of view.
On the other hand, the answerer may also reject the offer because it
contains unknown address types. The error response sent by the
answerer will most likely not be explicit enough about the situation.
So, the offerer will not understand what went wrong.
In the previous scenario, the sdp-anat option-tag would allow the
answerer to explicitly inform the offerer that the answerer did not
support ANAT.
4.3 OPTIONS Requests
Although RFC 3388 [5] provides servers with a means to indicate
support for ANAT in an SDP description, many servers do not include
an SDP description in their responses to OPTIONS requests. The
sdp-anat option-tag makes it possible to discover if any server
supports ANAT, since they would include this option-tag in a
Supported header field in their responses.
5. Option-Tag Usage
As discussed in the previous section, the use of the sdp-anat
option-tag makes SIP messages more explicit about ANAT support, which
is generally a good property. So, SIP entities generating an offer
that uses the ANAT semantics SHOULD place the sdp-anat option-tag in
a Require header field. SIP entities that support the ANAT semantics
Camarillo & Rosenberg Expires November 30, 2004 [Page 4]
Internet-Draft The sdp-anat Option-Tag June 2004
MUST understand the sdp-anat option-tag.
6. Security Considerations
An attacker may attempt to add the sdp-anat option tag to the Require
header field of a message to perform a DoS attack. If the UAS does
not support ANAT, it will return an error response instead of
processing the message.
An attacker may attemp to remove the sdp-anat option-tag from the
Require header field of a message. This may result in the
establishment of too many media streams.
To avoid the previous attacks, it is RECOMMENDED that the Require
header field is integrity protected. The natural choice to integrity
protect header fields in SIP is S/MIME.
7. IANA Considerations
This document defines a SIP option-tag (sdp-anat) in Section 3. It
should be registered in the SIP parameter registry at:
http://www.iana.org/assignments/sip-parameters
SIP user agents that place the sdp-anat option-tag in a Supported
header field understand the ANAT semantics.
8 Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[3] 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.
[4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[5] Camarillo, G., Eriksson, G., Holler, J. and H. Schulzrinne,
"Grouping of Media Lines in the Session Description Protocol
(SDP)", RFC 3388, December 2002.
Camarillo & Rosenberg Expires November 30, 2004 [Page 5]
Internet-Draft The sdp-anat Option-Tag June 2004
[6] Camarillo, G., "The Alternative Network Address Types Semantics
for the Session Description Protocol Grouping Framework",
draft-ietf-mmusic-anat-00 (work in progress), December 2003.
Authors' Addresses
Gonzalo Camarillo
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
EMail: Gonzalo.Camarillo@ericsson.com
Jonathan Rosenberg
dynamicsoft
600 Lanidex Plaza
Parsippany, NJ 07054
US
EMail: jdrosen@dynamicsoft.com
Camarillo & Rosenberg Expires November 30, 2004 [Page 6]
Internet-Draft The sdp-anat Option-Tag June 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the IETF's procedures with respect to rights in IETF Documents can
be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Camarillo & Rosenberg Expires November 30, 2004 [Page 7]
