Network Working Group C. Holmberg
Internet-Draft Ericsson
Intended status: Standards Track R. Shpount
Expires: December 17, 2015 TurboBridge
June 15, 2015
DTLS Association Establishment Using the SDP Offer/Answer Mechanism
draft-holmberg-mmusic-sdp-dtls-00.txt
Abstract
This draft defines the criteria for when a DTLS association needs to
be established/re-established, based on an SDP offer/answer
transaction. The draft also defines how the SDP 'connection'
attribute is used with DTLS to signal to the remote peer whether a
new DTLS association needs to established/re-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 17, 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
Holmberg & Shpount Expires December 17, 2015 [Page 1]
Internet-DraDTLS Association Establishment Using the SDP Offe June 2015
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 2
4. DTLS Association Re-Establishment Criteria . . . . . . . . . 3
4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3
4.2. Change of DTLS Role . . . . . . . . . . . . . . . . . . . 3
4.3. Change of Fingerprint . . . . . . . . . . . . . . . . . . 3
4.4. ICE Considerations . . . . . . . . . . . . . . . . . . . 3
4.5. SIP Considerations . . . . . . . . . . . . . . . . . . . 4
5. SDP Connection Attribute for DTLS . . . . . . . . . . . . . . 4
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4
6. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 5
6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5
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 . . . . . . . . . . . . . . . . . . . 6
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 7
12. Normative References . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
This draft defines the criteria for when a DTLS association needs to
be established/re-established, based on an SDP offer/answer
transaction. The draft also defines how the SDP 'connection'
attribute is used with DTLS to signal to the remote peer whether a
new DTLS association needs to established/re-established.
2. Abbreviations
TBD
3. 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].
Holmberg & Shpount Expires December 17, 2015 [Page 2]
Internet-DraDTLS Association Establishment Using the SDP Offe June 2015
4. DTLS Association Re-Establishment Criteria
4.1. General
If an endpoint changes the local transport parameters associated with
a DTLS association, the endpoint MUST create a new DTLS association.
Section 6 defines the SDP Offer/Answer procedures [RFC3264]
associated with that.
NOTE: As described in Section 4.4, when Interactive Connectivity
Establishment (ICE) [RFC5245] is used there are specific scenarios
where the change of transport parameters do not trigger a re-
establishment of the DTLS association.
This section describes other events that require re-establishment of
a DTLS association. If such event occur, the endpoint MUST also
change the local transport parameters. An endpoint MUST NOT re-
establish a DTLS association without also changing the local
transport parameters, event if the trigger as such for the re-
establishment is not a change of the local transport parameters.
NOTE: In future, if new events that require re-establishment of a
DTLS association are found, this section should be updated to cover
those events.
4.2. Change of DTLS Role
[RFC5763] defines how the DTLS roles are negotiated using an offer/
answer transaction. If DTLS roles associated with the DTLS
association have previously been negotiated, and a subsequent offer/
answer transaction changes the roles, the DTLS association MUST be
re-established.
4.3. Change of Fingerprint
If the certificate fingerprint [REF-TO-BE-ADDED] associated with the
DTLS association changes, the DTLS association MUST be re-
established.
4.4. ICE Considerations
If Interactive Connectivity Establishment (ICE) [RFC5245] is used,
the re-establishment of a DTLS association requires the ICE session
to be re-established. Similarly, the re-establishment of an ICE
session requires re-establishment of the DTLS association.
When an endpoint wants to re-establish the ICE session, if follows
the procedures in [RFC5245]. When the endpoint collects the new set
Holmberg & Shpount Expires December 17, 2015 [Page 3]
Internet-DraDTLS Association Establishment Using the SDP Offe June 2015
of ICE candidates, the host candidate(s) MUST be different from the
previously used host candidates.
An ICE restart [RFC5245] does not require re-establishment of the
DTLS association and the ICE session, even if new host candidates
might be taken into use due to the restart.
Note that, 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 endpoints switch between
those ICE candidates, and hence such switch will not trigger re-
establishment of the DTLS association.
NOTE: The procedures defined in [RFC5763] are defined for SRTP-DTLS
[RFC5763]. However, this document refer the the procedures for
general usage with DTLS.
4.5. 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.
5. SDP Connection Attribute for DTLS
5.1. General
The SDP 'connection' attribute 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 the existing DTLS association MUST be used.
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.
Holmberg & Shpount Expires December 17, 2015 [Page 4]
Internet-DraDTLS Association Establishment Using the SDP Offe June 2015
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.
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 to 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.
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 local events) that the
DTLS association is to be re-established. In addition, the answerer
MUSTbinsert 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 (or re-
establishment) of the DTLS association, it MUST reject the offer
[RFC3264].
If an answerer receives an offer that contains a 'connection'
attribute with an 'existing' value, and if the answerer determines
that the DTLS association does not need to be re-established, it MUST
insert 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.
Holmberg & Shpount Expires December 17, 2015 [Page 5]
Internet-DraDTLS Association Establishment Using the SDP Offe June 2015
If the DTLS association is to be established (or re-established), and
if the answerer becomes DTLS client, the answerer MUST initiate the
procedures for establishing/re-establishing the DTLS association. If
the answerer becomes DTLS server, it waits for the offerer to
establish (or re-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/re-establish the DTLS association. If the
offerer becomes DTLS server, it waits for the answerer to establish/
re-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 a previously
established DTLS association is to be established (or re-
established), 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 DTLS association
is not to be established (or re-established), 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.
7. RFC Updates
Here we will add the RFC updates that are needed.
8. Security Considerations
TBD
Holmberg & Shpount Expires December 17, 2015 [Page 6]
Internet-DraDTLS Association Establishment Using the SDP Offe June 2015
9. IANA Considerations
TBD
10. Acknowledgements
TBD
11. Change Log
[RFC EDITOR NOTE: Please remove this section when publishing]
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.
[RFC4572] Lennox, J., "Connection-Oriented Media Transport over the
Transport Layer Security (TLS) Protocol in the Session
Description Protocol (SDP)", RFC 4572, July 2006.
[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
Holmberg & Shpount Expires December 17, 2015 [Page 7]
Internet-DraDTLS Association Establishment Using the SDP Offe June 2015
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 17, 2015 [Page 8]