Using the SDP Offer/Answer Mechanism for DTLS
draft-ietf-mmusic-dtls-sdp-00

The information below is for an old version of the document
Document Type Active Internet-Draft (mmusic WG)
Last updated 2015-10-16 (latest revision 2015-09-07)
Replaces draft-holmberg-mmusic-sdp-dtls
Stream IETF
Intended RFC status Proposed Standard
Formats plain text pdf html bibtex
Additional URLs
- Mailing list discussion
Stream WG state WG Document (wg milestone: Jul 2017 - Using the SDP Offer/... )
Document shepherd Flemming Andreasen
IESG IESG state I-D Exists
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                        C. Holmberg
Internet-Draft                                                  Ericsson
Intended status: Standards Track                              R. Shpount
Expires: March 10, 2016                                      TurboBridge
                                                       September 7, 2015

             Using the SDP Offer/Answer Mechanism for DTLS
                   draft-ietf-mmusic-dtls-sdp-00.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 March 10, 2016.

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 March 10, 2016                 [Page 1]
Internet-DraftUsing the SDP Offer/Answer Mechanism for DTLSeptember 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
Show full document text