[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 draft-ietf-mmusic-dtls-sdp

Network Working Group                                        C. Holmberg
Internet-Draft                                                  Ericsson
Intended status: Standards Track                              R. Shpount
Expires: December 22, 2015                                   TurboBridge
                                                           June 20, 2015


             Using the SDP Offer/Answer Mechanism for DTLS
                 draft-holmberg-mmusic-sdp-dtls-01.txt

Abstract

   This draft defines the SDP offer/answer procedures for negotiating
   and establishing a DTLS association.  The draft also defines the
   criteria for when a new DTLS association must be established.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on December 22, 2015.

Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.




Holmberg & Shpount      Expires December 22, 2015               [Page 1]


Internet-DraftUsing the SDP Offer/Answer Mechanism for DTLS    June 2015


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Establishing a new DTLS Association . . . . . . . . . . . . .   3
     2.1.  General . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.2.  ICE Considerations  . . . . . . . . . . . . . . . . . . .   3
     2.3.  SIP Considerations  . . . . . . . . . . . . . . . . . . .   3
   3.  Abbreviations . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Conventions . . . . . . . . . . . . . . . . . . . . . . . . .   4
   5.  SDP Connection Attribute for DTLS . . . . . . . . . . . . . .   4
     5.1.  General . . . . . . . . . . . . . . . . . . . . . . . . .   4
   6.  SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . .   4
     6.1.  General . . . . . . . . . . . . . . . . . . . . . . . . .   4
     6.2.  Generating the Initial SDP Offer  . . . . . . . . . . . .   5
     6.3.  Generating the Answer . . . . . . . . . . . . . . . . . .   5
     6.4.  Offerer Processing of the SDP Answer  . . . . . . . . . .   6
     6.5.  Modifying the Session . . . . . . . . . . . . . . . . . .   6
   7.  RFC Updates . . . . . . . . . . . . . . . . . . . . . . . . .   6
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
   11. Change Log  . . . . . . . . . . . . . . . . . . . . . . . . .   7
   12. Normative References  . . . . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   [RFC5763] defines SDP Offer/Answer procedures for SRTP-DTLS.  This
   draft defines the SDP Offer/Answer [RFC3264] procedures for
   negotiation DTLS in general, based on the procedures in [RFC5763].

   This draft also defines the usage of the SDP 'connection' attribute
   with DTLS.  The attribute is used in SDP offers and answers to
   explicitly indicate whether a new DTLS association is to be
   established.

   As defined in [RFC5245], when Interactive Connectivity Establishment
   (ICE) [RFC5245] is used, the ufrag value is changed both when ICE is
   negotiated, and when ICE restart [RFC5245] occurs.  These events do
   not always require a new DTLS association to be established, but
   currently there is no way to explicitly indicate in an SDP offer or
   answer whether a new DTLS association is required.  To solve that
   problem, this draft defines the usage of the SDP 'connection'
   attribute with DTLS.  The attribute is used in SDP offers and answers
   to explicitly indicate whether a new DTLS association is to be
   established/re-established.  The attribute can be used both with and
   without ICE.




Holmberg & Shpount      Expires December 22, 2015               [Page 2]


Internet-DraftUsing the SDP Offer/Answer Mechanism for DTLS    June 2015


2.  Establishing a new DTLS Association

2.1.  General

   As defined in [RFC5763], an endpoint MUST indicate (in an offer or
   answer) that a new DTLS association to established in the following
   cases:

   o  The DTLS roles change;

   o  The fingerprint (certificate) value changes;

   o  The local transport parameters (IP address and/or port) of at
      least one endpoint change; or

   o  If ICE is used and the ufrag value changes, and there is no
      explicit indication (SDP 'connection' attribute) that a new DTLS
      association shall not be established;

   When a new DTLS association is established, an endpoint MUST use a
   new set of transport parameters (IP address and port combination).

2.2.  ICE Considerations

   An ICE restart [RFC5245] does not by default require a new DTLS
   association to be established.  A new DTLS association needs to be
   established only if or more of the criteria listed in Section 2.1 is
   fulfilled (e.g. if the local transport paramters change).

   As defined in [RFC5763], each ICE candidate associated with a
   component is treated as being part of the same DTLS association.
   Therefore, from a DTLS perspective it is not considered a change of
   local transport parameters when an endpoint switches between those
   ICE candidates.

2.3.  SIP Considerations

   When the Session Initiation Protocol (SIP) [RFC3261] is used as the
   signal protocol for establishing a multimedia session, dialogs
   [RFC3261] might be established between the caller and multiple
   callees.  This is referred to as forking.  If forking occurs,
   separate DTLS associations MUST be established between the caller and
   each callee.








Holmberg & Shpount      Expires December 22, 2015               [Page 3]


Internet-DraftUsing the SDP Offer/Answer Mechanism for DTLS    June 2015


3.  Abbreviations

   TBD

4.  Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

5.  SDP Connection Attribute for DTLS

5.1.  General

   The SDP 'connection' attribute [RFC4145] was originally defined for
   connection-oriented protocols, e.g.  TCP and TLS.  This section
   defines how the attribute is used with DTLS.

   A 'connection' attribute value of 'new' indicates that a new DTLS
   association MUST be established.  A 'connection' attribute value of
   'existing' indicates that a new DTLS association MUST NOT be
   established.

   When used with DTLS, there is no default value defined for the
   attribute.  Implementations that wish to use the attribute MUST
   explicitly include it in SDP offers and answers.  If an offer or
   answer does not contain an attribute, other means needs to be used in
   order for endpoints to determine whether an offer or answer is
   associated with an event that requires the DTLS association to be re-
   established.

6.  SDP Offer/Answer Procedures

6.1.  General

   This section defines the SDP offer/answer procedures for using the
   SDP 'connection' attribute for DTLS.  The section also describes how
   the usage of the SDP 'setup' attribute and the SDP 'fingerprint'
   attribute [RFC4572] is affected.

   The procedures in this section are based on the procedures for SRTP-
   DTLS [RFC5763], with the addition of usage of the SDP 'connection'
   attribute.








Holmberg & Shpount      Expires December 22, 2015               [Page 4]


Internet-DraftUsing the SDP Offer/Answer Mechanism for DTLS    June 2015


6.2.  Generating the Initial SDP Offer

   When the offerer sends the initial offer, and the offerer wants to
   establish a DTLS association, it MUST insert an SDP 'connection'
   attribute with a 'new' value in the offer.  In addition, the offerer
   MUST insert an SDP 'setup' attribute according to the procedures in
   [RFC4572], and an SDP 'fingerprint' attribute according to the
   procedures in [RFC4572], in the offer.

   If ICE is used, the offerer MUST insert the SDP 'ice-ufrag' and 'ice-
   pwd' attributes according to the procedures in [RFC5245] in the
   offer.

6.3.  Generating the Answer

   If an answerer receives an offer that contains an SDP 'connection'
   attribute with a 'new' value, the answerer MUST insert a 'new' value
   in the associated answer.  The same applies if the answerer receives
   an offer that contains an SDP 'connection' attribute with a 'new'
   value, but the answerer determines (based on the criteria for
   establishing a new DTLS association) that a new DTLS association is
   to be established.  In addition, the answerer MUST insert an SDP
   'setup' attribute according to the procedures in [RFC4572], and an
   SDP 'fingerprint' attribute according to the procedures in [RFC4572],
   in the answer.

   If the answerer does not accept the establishment of the DTLS
   association, it MUST reject the "m=" lines associated with the
   suggested DTLS association [RFC3264].

   If an answerer receives an offer that contains a 'connection'
   attribute with an 'existing' value, and if the answerer determines
   that a new DTLS association does not need to be established, it MUST
   insert a connection attribute with an 'existing' value in the
   associated answer.  In addition, the answerer MUST insert an SDP
   'setup' attribute with a value that does not change the previously
   negotiated DTLS roles, and an SDP 'fingerprint' attribute with a
   value that does not change the fingerprint, in the answer.

   If the answerer receives an offer that does not contain an SDP
   'connection' attribute, the answerer MUST NOT insert a 'connection'
   attribute in the answer.

   If ICE is used, the answerer MUST insert the SDP 'ice-ufrag' and
   'ice-pwd' attributes according to the procedures in [RFC5245] in the
   answer.





Holmberg & Shpount      Expires December 22, 2015               [Page 5]


Internet-DraftUsing the SDP Offer/Answer Mechanism for DTLS    June 2015


   If a new DTLS association is to be established, and if the answerer
   becomes DTLS client, the answerer MUST initiate the procedures for
   establishing the DTLS association.  If the answerer becomes DTLS
   server, it MUST wait for the offerer to establish the DTLS
   association.

6.4.  Offerer Processing of the SDP Answer

   When an offerer receives an answer that contains an SDP 'connection'
   attribute with a 'new' value, and if the offerer becomes DTLS client,
   the offerer MUST establish a DTLS association.  If the offerer
   becomes DTLS server, it MUST wait for the answerer to establish the
   DTLS association.

   If the answer contains an SDP 'connection' attribute with an
   'existing' value, the offerer will continue using the previously
   established DTLS association.  It is considered an error case if the
   answer contains a 'connection' attribute with an 'existing' value,
   and a DTLS association does not exist.

6.5.  Modifying the Session

   When the offerer sends a subsequent offer, and the offerer wants to
   establish a new DTLS association, the offerer MUST insert an SDP
   'connection' attribute with a 'new' value in the offer.  In addition,
   the offerer MUST insert an SDP 'setup' attribute according to the
   procedures in [RFC4572], and an SDP 'fingerprint' attribute according
   to the procedures in [RFC4572], in the offer.

   when the offerer sends a subsequent offer, and the offerer does not
   want to establish a new DTLS association, if a previously established
   DTLS association exists, the offerer MUST insert an SDP 'connection'
   attribute with an 'existing' value in the offer.  In addition, the
   offerer MUST insert an SDP 'setup' attribute with a value that does
   not change the previously negotiated DTLS roles, and an SDP
   'fingerprint' attribute with a value that does not change the
   fingerprint, in the offer.

   If ICE is used, the offerer MUST insert the SDP 'ice-ufrag' and 'ice-
   pwd' attributes according to the procedures in [RFC5245] in the
   subsequent offer.

7.  RFC Updates

   Here we will add the RFC updates that are needed.






Holmberg & Shpount      Expires December 22, 2015               [Page 6]


Internet-DraftUsing the SDP Offer/Answer Mechanism for DTLS    June 2015


8.  Security Considerations

   This draft does not modify the security considerations associated
   with DTLS, or the SDP offer/answer mechanism.  The draft simply
   clarifies the procedures for negotiating and establishing a DTLS
   association.

9.  IANA Considerations

   TBD

10.  Acknowledgements

   Thanks to Justin Uberti, Martin Thomson, Paul Kyzivat and Jens
   Guballa for providing comments and suggestions on the draft.

11.  Change Log

   [RFC EDITOR NOTE: Please remove this section when publishing]

   Changes from draft-holmberg-mmusic-sdp-dtls-00

   o  - Editorial changes and clarifications.

12.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3261]  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.

   [RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
              with Session Description Protocol (SDP)", RFC 3264, June
              2002.

   [RFC4145]  Yon, D. and G. Camarillo, "TCP-Based Media Transport in
              the Session Description Protocol (SDP)", RFC 4145,
              September 2005.

   [RFC4572]  Lennox, J., "Connection-Oriented Media Transport over the
              Transport Layer Security (TLS) Protocol in the Session
              Description Protocol (SDP)", RFC 4572, July 2006.






Holmberg & Shpount      Expires December 22, 2015               [Page 7]


Internet-DraftUsing the SDP Offer/Answer Mechanism for DTLS    June 2015


   [RFC5245]  Rosenberg, J., "Interactive Connectivity Establishment
              (ICE): A Protocol for Network Address Translator (NAT)
              Traversal for Offer/Answer Protocols", RFC 5245, April
              2010.

   [RFC5763]  Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
              for Establishing a Secure Real-time Transport Protocol
              (SRTP) Security Context Using Datagram Transport Layer
              Security (DTLS)", RFC 5763, May 2010.

Authors' Addresses

   Christer Holmberg
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: christer.holmberg@ericsson.com


   Roman Shpount
   TurboBridge
   4905 Del Ray Avenue, Suite 300
   Bethesda, MD  20814
   USA

   Phone: +1 (240) 292-6632
   Email: rshpount@turbobridge.com






















Holmberg & Shpount      Expires December 22, 2015               [Page 8]


Html markup produced by rfcmarkup 1.121, available from https://tools.ietf.org/tools/rfcmarkup/