RFC 4092

Usage of the Session Description Protocol (SDP) Alternative Network Address Types (ANAT) Semantics in the Session Initiation Protocol (SIP)

📅 published June 2005, from ietf

RFC 4092 📮 Usage of the Session Description Protocol (SDP) Alternative Network Address Types (ANAT) Semantics in the Session Initiation Protocol (SIP)

okay so this is RFC 4092 🎀, a Standards Track doc from June 2005. The authors are Gonzalo Camarillo (Ericsson) and Jonathan Rosenberg (Cisco Systems), and it's part of the Network Working Group 🧚. Bestie, the whole thing is about making sure SIP and ANAT play nicely together 💅

Status of This Memo ✨

This document is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions to make it better 🙌 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🦋

Copyright (C) The Internet Society (2005).

Abstract 🌸

Okay this one is the main pitch 💖 The document explains how to use the Alternative Network Address Types (ANAT) semantics of the Session Description Protocol (SDP) grouping framework in SIP. The big deal is the sdp-anat SIP option-tag ✨ It makes sure SDP session descriptions that use ANAT only get handled by SIP entities that actually support ANAT. To prove we need it, the doc walks through what could go wrong 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 🌈

Okay so SIP [3] UAs (User Agents) are often able to use different network address types 🫶 A UA might have an IPv6 address and an IPv4 address, right? Such a UA will usually be happy to use any of its addresses to set up a media session with a remote UA. If the remote UA only speaks IPv6, for example, both UAs will just use IPv6 to send and receive media ✨

The Alternative Network Address Types (ANAT) semantics [7] of the SDP [2] grouping framework [5] let UAs offer [4] alternative addresses of different types in an SDP session description. So our IPv4/IPv6 dual-stack SIP UA from before would make an offer that groups an IPv6 media line and an IPv4 media line using ANAT. When the answerer [4] gets that offer, it accepts one media line and rejects the other 💅

If the recipient of an offer that uses ANAT supports the ANAT semantics, everything works the way the ANAT specification [7] describes 🎀 But the recipient (aka the answerer) might not support ANAT, and then different implementations would react in different ways 😬 This document looks at the answerer behaviors that are most likely to show up and what they lead to. To dodge those consequences, we define the sdp-anat SIP option-tag 🔥

The sdp-anat option-tag can be used to make sure an offer using ANAT doesn't get processed by answerers without ANAT support. It can also be used to explicitly discover whether a UA 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 put this option-tag in a Supported header field understand the ANAT semantics as defined in [7] ✨

4. Backward Compatibility 🙈

Answerers without ANAT support will react in different ways when they get an offer that uses ANAT. We expect that, even under the same circumstances, different implementations will behave differently 🤷‍♀️ In this section we analyze those behaviors. The subsections below 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 is NOT what the offerer expects, because it results in way too many media streams being established 😭 If the answerer starts sending media over all of them, that could mean high bandwidth usage.

The answerer may also reject the offer, even though it supports all the network types in it, because it may not support them simultaneously. The error response it sends will most likely not explain the situation clearly, so the offerer won't understand what went wrong 💀

So in these scenarios, the sdp-anat option-tag would stop too many media streams from getting established, and it would let the answerer clearly tell the offerer that it didn't support ANAT 🫶

4.2. Answerer Does Not Support All the Network Types Offered 🦋

If the answerer doesn't support all the network types in the offer, it may only establish the media streams whose address types it understands and reject the rest. From the offerer's point of view, that's an acceptable behavior 👑

On the other hand, the answerer may also reject the offer because it contains unknown address types. Again, the error response will most likely not be explicit enough, so the offerer won't get what went wrong 😩

In this scenario, the sdp-anat option-tag would let the answerer explicitly tell the offerer that it didn't support ANAT 💖

4.3. OPTIONS Requests 🧚

Okay so RFC 3388 [5] gives servers a way to indicate ANAT support in an SDP description. But lots of servers don't include an SDP description in their responses to OPTIONS requests 💅 The sdp-anat option-tag fixes this, because servers would include the option-tag in a Supported header field in their responses. That makes it possible to discover whether any server supports ANAT ✨

5. Option-Tag Usage 💜

As we talked about in the last section, using the sdp-anat option-tag makes SIP messages way 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 🔥

Okay this part is serious bestie 😭 An attacker may try to add the sdp-anat option tag to the Require header field of a message in order to pull off a DoS attack. If the UAS does not support ANAT, it will return an error response instead of processing the message.

An attacker may also try to remove the sdp-anat option-tag from the Require header field of a message. That may result in too many media streams being established 💀

To avoid the previous attacks, integrity protection of the Require header field is RECOMMENDED. The natural choice for integrity protecting 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 put 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

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 on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to apply to the implementation or use of the technology described in this document, or on the extent to which any license under such rights might or might not be available. It also doesn't say it has made any independent effort to identify any such rights. Info on the procedures for rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the results of an attempt to get a general license or permission for implementers or users to use these proprietary rights can be found in the IETF online IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology required to implement this standard. Please send that info to the IETF at ietf-ipr@ietf.org 💜

Acknowledgement 🌸

Funding for the RFC Editor function is currently provided by the Internet Society ✨

📦 where this page comes from