SIP ANAT Usage: Usage of the Session Description Protocol (SDP) Alternative Network Address Types (ANAT) Semantics in the Session Initiation Protocol (SIP)
Offering multiple network address types in phone call setup.
Camarillo, G. and J. Rosenberg, "Usage of the Session Description Protocol (SDP) Alternative Network Address Types (ANAT) Semantics in the Session Initiation Protocol (SIP)", RFC 4092, DOI 10.17487/RFC4092, June 2005, <https://www.rfc-editor.org/info/rfc4092>.
@misc{rfc4092,
series = {Request for Comments},
number = 4092,
howpublished = {RFC 4092},
publisher = {RFC Editor},
doi = {10.17487/RFC4092},
url = {https://www.rfc-editor.org/info/rfc4092},
author = {G. Camarillo and J. Rosenberg},
title = {{Usage of the Session Description Protocol (SDP) Alternative Network Address Types (ANAT) Semantics in the Session Initiation Protocol (SIP)}},
pagetotal = 6,
year = 2005,
month = jun,
} RFC text
Contents
Network Working Group G. Camarillo
Request for Comments: 4092 Ericsson
Category: Standards Track J. Rosenberg
Cisco Systems
June 2005
Usage of the Session Description Protocol (SDP)
Alternative Network Address Types (ANAT) Semantics
in the Session Initiation Protocol (SIP)
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes how to use the Alternative Network Address
Types (ANAT) semantics of the Session Description Protocol (SDP)
grouping framework in SIP. In particular, we define the sdp-anat SIP
option-tag. This SIP option-tag ensures that SDP session
descriptions that use ANAT are only handled by SIP entities with ANAT
support. To justify the need for such a SIP option-tag, we describe
what could possibly happen if an ANAT-unaware SIP entity tried to
handle media lines grouped with ANAT.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. The sdp-anat Option-Tag . . . . . . . . . . . . . . . . . . . . 2
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. 3
4.3. OPTIONS Requests . . . . . . . . . . . . . . . . . . . . 4
5. Option-Tag Usage . . . . . . . . . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . 4
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
8. Normative References . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction
SIP [3] UAs (User Agents) often support different network address
types. For example, a UA may have an IPv6 address and an IPv4
address. Such a UA will typically be willing to use any of its
addresses to establish a media session with a remote UA. If the
remote UA only supports IPv6, for instance, both UAs will use IPv6 to
send and receive media.
The Alternative Network Address Types (ANAT) semantics [7] of the SDP
[2] grouping framework [5] allow UAs to offer [4] alternative
addresses of different types in an SDP session description. The
IPv4/IPv6 dual-stack SIP UA of our previous example would generate an
offer grouping an IPv6 media line and an IPv4 media line using ANAT.
Upon receipt of this offer, the answerer [4] would accept one media
line and reject the other.
If the recipient of an offer that uses ANAT supports the ANAT
semantics, everything works as described in the ANAT specification
[7]. 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's behaviors that are most likely to
be found and describes their consequences. To avoid these
consequences, we define 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 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 [7].
4. Backward Compatibility
Answerers without support for ANAT will react in different ways upon
receipt of an offer using ANAT. We expect that, even under the same
circumstances, different implementations will behave in different
ways. In this section, we analyze these behaviors (i.e., the
following 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
accept the offer and establish all the media streams in it. This
behavior is not what the offerer expects 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 it
understands and 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. 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 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 attempt 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, integrity protection of the Require
header field is RECOMMENDED. The natural choice to integrity protect
header fields in SIP is S/MIME [6].
7. IANA Considerations
This document defines a SIP option-tag (sdp-anat) in Section 3. It
has been registered by the IANA in the SIP parameter registry.
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.
[6] Peterson, J., "S/MIME Advanced Encryption Standard (AES)
Requirement for the Session Initiation Protocol (SIP)", RFC
3853, July 2004.
[7] Camarillo, G. and J. Rosenberg, "The Alternative Network Address
Types (ANAT) Semantics for the Session Description Protocol
(SDP) Grouping Framework", RFC 4091, June 2005.
Authors' Addresses
Gonzalo Camarillo
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
EMail: Gonzalo.Camarillo@ericsson.com
Jonathan Rosenberg
Cisco Systems
600 Lanidex Plaza
Parsippany, NJ 07054
US
EMail: jdrosen@cisco.com
Full Copyright Statement
Copyright (C) The Internet Society (2005).
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.
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.
Intellectual Property
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 procedures with respect to rights in RFC 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
AI ELI5
On this page
§1Dual-Stack Device Offers
SIP (Session Initiation Protocol) is used to set up phone calls and other real-time communications. Many modern devices have both IPv4 and IPv6 addresses. When such a device offers to start a call, it wants to say you can reach me at either of my addresses; pick one.
The Session Description Protocol (SDP) offers a way to do this through the ANAT (Alternative Network Address Types) semantics defined in RFC 4091. ANAT allows an offerer to group multiple media lines (one for each address type) and indicate that the answerer should choose one.
However, if the answerer does not understand ANAT, confusion results: it might accept all media lines (creating duplicate streams), or reject the offer without a clear error message. RFC 4092 solves this by defining the sdp-anat option-tag.
When you call someone, you might say here is my IPv4 address and here is my IPv6 address, pick one. But if the other person does not understand that you are offering choices, they might get confused. This RFC solves that confusion.
§2The sdp-anat Option-Tag
The sdp-anat option-tag is a SIP option-tag that can appear in Require and Supported header fields. An offerer that includes sdp-anat in a Require header is saying I am using ANAT; only answer if you understand it. A recipient that includes it in a Supported header is saying I understand ANAT.
SIP entities that support ANAT semantics MUST understand the sdp-anat option-tag. They understand what the grouping framework and ANAT specification say: that grouped media lines represent alternatives, and only one should be accepted.
An option-tag is a label that says I am using a special feature. When you require sdp-anat, you are saying this offer uses ANAT, and you need to understand it.
§3What Happens Without the Tag
Without the sdp-anat option-tag, answerers without ANAT support behave unpredictably. If an answerer supports all the address types in an offer but not ANAT, it might accept all media lines, wasting bandwidth by establishing multiple streams. Or it might reject the offer because it encounters unknown syntax, sending a confusing error message.
If an answerer does not support all address types, it might accept only the ones it understands (which is actually acceptable behavior) or reject the entire offer without clear explanation.
The sdp-anat option-tag prevents these scenarios. An answerer without ANAT support will reject the request with a 420 Bad Extension response, explicitly indicating that it does not support ANAT.
Without the tag, a device that does not understand ANAT might accept all the address options (creating too many streams), or reject the call with a confusing error. The tag says only talk to me if you get this.
§4Requirement and Discovery
Offerers that use ANAT semantics SHOULD place the sdp-anat option-tag in a Require header field of the SIP offer. This ensures that only answerers with ANAT support will receive the offer.
The option-tag also enables capability discovery. An endpoint can send a SIP OPTIONS request and include sdp-anat in a Require header. Only servers that support ANAT will respond with a 200 OK message. This allows clients to discover which servers in their domain support ANAT without trying to send a full SIP invitation.
When you send a call offer using ANAT, you put sdp-anat in a Require header so only compatible devices will answer. You can also use OPTIONS requests to ask a server do you support ANAT? without making a real call.
- INVITE with sdp-anat in RequireOffer includes grouped IPv4 and IPv6 media lines.
- 200 OK (if ANAT supported)Answer selects one media line.
§5DoS and Tampering Risks
An attacker could add the sdp-anat option-tag to the Require header to cause a denial-of-service attack: if a UAS (User Agent Server) does not support ANAT, it will reject the request. Conversely, an attacker could remove the sdp-anat tag, causing multiple media streams to be established if the answerer does not understand ANAT.
To defend against these attacks, the RFC recommends integrity protection of the Require header field. The natural choice for SIP is S/MIME (Secure MIME), which cryptographically signs SIP message headers.
An attacker could trick the sdp-anat tag into the message to break the call, or remove it to waste bandwidth. To prevent this, protect the Require header by signing it.