Usage of the Session Description Protocol (SDP) Alternative Network Address Types (ANAT) Semantics in the Session Initiation Protocol (SIP)
draft-ietf-sip-anat-usage-00

SIP Working Group                                           G. Camarillo
Internet-Draft                                                  Ericsson
Expires: December 15, 2004                                  J. Rosenberg
                                                             dynamicsoft
                                                           June 16, 2004

  Usage of the Session Description Protocol (SDP) Alternative Network
   Address Types (ANAT) Semantics in the Session Initiation Protocol
                                 (SIP)
                    draft-ietf-sip-anat-usage-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 December 15, 2004.

Copyright Notice

   Copyright (C) The Internet Society (2004). All Rights Reserved.

Abstract

   This document describes how to use the ANAT semantics of the SDP
   grouping framework in SIP. In particular, we define the sdp-anat SIP
   option-tag. This SIP option-tag ensures that SDP session descriptions
   using 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.

Camarillo & Rosenberg    Expires December 15, 2004              [Page 1]
Internet-Draft             ANAT Usage in SIP                   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  . . . . .  4
     4.2   Answerer does Not Support All the Network Types Offered  .  4
     4.3   OPTIONS Requests . . . . . . . . . . . . . . . . . . . . .  4
   5.  Option-Tag Usage . . . . . . . . . . . . . . . . . . . . . . .  5
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  5
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  5
   8.  Normative References . . . . . . . . . . . . . . . . . . . . .  5
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .  6
       Intellectual Property and Copyright Statements . . . . . . . .  7

Camarillo & Rosenberg    Expires December 15, 2004              [Page 2]
Internet-Draft             ANAT Usage in SIP                   June 2004

1.  Introduction

   SIP [3] UAs (User Agents) have often support for 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 ANAT semantics [6] of the SDP [2] grouping framework [5] allow
   UAs to offer 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. On reception of this offer, the answerer
   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
   [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'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 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

Camarillo & Rosenberg    Expires December 15, 2004              [Page 3]
Internet-Draft             ANAT Usage in SIP                   June 2004

   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
   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.

Camarillo & Rosenberg    Expires December 15, 2004              [Page 4]
Internet-Draft             ANAT Usage in SIP                   June 2004

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
   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.

Camarillo & Rosenberg    Expires December 15, 2004              [Page 5]
Internet-Draft             ANAT Usage in SIP                   June 2004

   [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]  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 December 15, 2004              [Page 6]
Internet-Draft             ANAT Usage in SIP                   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 December 15, 2004              [Page 7]