draft-ietf-mmusic-dtls-sdp-29.txt   draft-ietf-mmusic-dtls-sdp-30.txt 
Network Working Group C. Holmberg Network Working Group C. Holmberg
Internet-Draft Ericsson Internet-Draft Ericsson
Updates: 5763,7345 (if approved) R. Shpount Updates: 5763,7345 (if approved) R. Shpount
Intended status: Standards Track TurboBridge Intended status: Standards Track TurboBridge
Expires: March 4, 2018 August 31, 2017 Expires: March 12, 2018 September 8, 2017
Session Description Protocol (SDP) Offer/Answer Considerations for Session Description Protocol (SDP) Offer/Answer Considerations for
Datagram Transport Layer Security (DTLS) and Transport Layer Security Datagram Transport Layer Security (DTLS) and Transport Layer Security
(TLS) (TLS)
draft-ietf-mmusic-dtls-sdp-29.txt draft-ietf-mmusic-dtls-sdp-30.txt
Abstract Abstract
This document defines the Session Description Protocol (SDP) offer/ This document defines the Session Description Protocol (SDP) offer/
answer procedures for negotiating and establishing a Datagram answer procedures for negotiating and establishing a Datagram
Transport Layer Security (DTLS) association. The document also Transport Layer Security (DTLS) association. The document also
defines the criteria for when a new DTLS association must be defines the criteria for when a new DTLS association must be
established. The document updates RFC 5763 and RFC 7345, by established. The document updates RFC 5763 and RFC 7345, by
replacing common SDP offer/answer procedures with a reference to this replacing common SDP offer/answer procedures with a reference to this
specification. specification.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
8122. 8122.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 4, 2018. This Internet-Draft will expire on March 12, 2018.
Internet-DrafSession Description Protocol (SDP) Offer/Answer August 2017
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
skipping to change at page 3, line 4 skipping to change at page 3, line 4
9.2.3. Update to section 6.6 . . . . . . . . . . . . . . . . 16 9.2.3. Update to section 6.6 . . . . . . . . . . . . . . . . 16
9.2.4. Update to section 6.7.1 . . . . . . . . . . . . . . . 16 9.2.4. Update to section 6.7.1 . . . . . . . . . . . . . . . 16
9.3. Update to RFC 7345 . . . . . . . . . . . . . . . . . . . 17 9.3. Update to RFC 7345 . . . . . . . . . . . . . . . . . . . 17
9.3.1. Update to section 4 . . . . . . . . . . . . . . . . . 17 9.3.1. Update to section 4 . . . . . . . . . . . . . . . . . 17
9.3.2. Update to section 5.2.1 . . . . . . . . . . . . . . . 17 9.3.2. Update to section 5.2.1 . . . . . . . . . . . . . . . 17
9.3.3. Update to section 10.1 . . . . . . . . . . . . . . . 18 9.3.3. Update to section 10.1 . . . . . . . . . . . . . . . 18
10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
13. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 19 13. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 19
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
Internet-DrafSession Description Protocol (SDP) Offer/Answer August 2017 14.1. Normative References . . . . . . . . . . . . . . . . . . 24
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
14.1. Normative References . . . . . . . . . . . . . . . . . . 23
14.2. Informative References . . . . . . . . . . . . . . . . . 25 14.2. Informative References . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
[RFC5763] defines Session Description Protocol (SDP) offer/answer [RFC5763] defines Session Description Protocol (SDP) offer/answer
procedures for Secure Realtime Transport Protocol Using Datagram procedures for Secure Realtime Transport Protocol Using Datagram
Transport Layer Security (DTLS-SRTP). [RFC7345] defines SDP offer/ Transport Layer Security (DTLS-SRTP). [RFC7345] defines SDP offer/
answer procedures for UDP Transport Layer over Datagram Transport answer procedures for UDP Transport Layer over Datagram Transport
Layer Security (UDPTL-DTLS). This specification defines general Layer Security (UDPTL-DTLS). This specification defines general
skipping to change at page 4, line 5 skipping to change at page 4, line 5
pair of SDP 'tls-id' attribute values (the attribute values of the pair of SDP 'tls-id' attribute values (the attribute values of the
offerer and the answerer) uniquely identifies the DTLS association. offerer and the answerer) uniquely identifies the DTLS association.
Providing a new value of the 'tls-id' attribute in an SDP offer or Providing a new value of the 'tls-id' attribute in an SDP offer or
answers can be used to indicate whether a new DTLS association is to answers can be used to indicate whether a new DTLS association is to
be established. be established.
The SDP 'tls-id' attribute can be specified when negotiating a The SDP 'tls-id' attribute can be specified when negotiating a
Transport Layer Security (TLS) connection, using the procedures in Transport Layer Security (TLS) connection, using the procedures in
this document in conjunction with the procedures in [RFC5763] and this document in conjunction with the procedures in [RFC5763] and
Internet-DrafSession Description Protocol (SDP) Offer/Answer August 2017
[RFC8122]. The unique combination of SDP 'tls-id' attribute values [RFC8122]. The unique combination of SDP 'tls-id' attribute values
can be used to identity the negotiated TLS connection. The unique can be used to identity the negotiated TLS connection. The unique
value can be used, for example, within TLS protocol extensions to value can be used, for example, within TLS protocol extensions to
differentiate between multiple TLS connections and correlate those differentiate between multiple TLS connections and correlate those
connections with specific offer/answer exchanges. The TLS specific connections with specific offer/answer exchanges. The TLS specific
considerations are described in Section 7. considerations are described in Section 7.
2. Conventions 2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 5, line 5 skipping to change at page 5, line 5
SDP offer/answer exchange, following the procedures in Section 5. SDP offer/answer exchange, following the procedures in Section 5.
The sections below describe typical cases where a new DTLS The sections below describe typical cases where a new DTLS
association needs to be established. association needs to be established.
In this document, a "new DTLS association" between two endpoints In this document, a "new DTLS association" between two endpoints
refers to either an initial DTLS association (when no DTLS refers to either an initial DTLS association (when no DTLS
association is currently established between the endpoints) or an association is currently established between the endpoints) or an
DTLS association replacing a previously established DTLS association. DTLS association replacing a previously established DTLS association.
Internet-DrafSession Description Protocol (SDP) Offer/Answer August 2017
3.2. Change of Local Transport Parameters 3.2. Change of Local Transport Parameters
If an endpoint modifies its local transport parameters (address and/ If an endpoint modifies its local transport parameters (address and/
or port), and if the modification requires a new DTLS association, or port), and if the modification requires a new DTLS association,
the endpoint must change its local SDP 'tls-id' attribute value (see the endpoint must change its local SDP 'tls-id' attribute value (see
Section 4). Section 4).
If the underlying transport prohibits a DTLS association from If the underlying transport prohibits a DTLS association from
spanning multiple transports, and if the transport is changed, the spanning multiple transports, and if the transport is changed, the
endpoint must change its local SDP 'tls-id' attribute value (see endpoint must change its local SDP 'tls-id' attribute value (see
skipping to change at page 6, line 5 skipping to change at page 6, line 5
If an endpoint uses ICE, and modifies a local ufrag value, and if the If an endpoint uses ICE, and modifies a local ufrag value, and if the
modification requires a new DTLS association, the endpoint MUST modification requires a new DTLS association, the endpoint MUST
change its local SDP 'tls-id' attribute value (see Section 4). change its local SDP 'tls-id' attribute value (see Section 4).
4. SDP tls-id Attribute 4. SDP tls-id Attribute
The pair of SDP 'tls-id' attribute values (the attribute values of The pair of SDP 'tls-id' attribute values (the attribute values of
the offerer and the answerer) uniquely identifies the DTLS the offerer and the answerer) uniquely identifies the DTLS
association or TLS connection. association or TLS connection.
Internet-DrafSession Description Protocol (SDP) Offer/Answer August 2017
Name: tls-id Name: tls-id
Value: tls-id-value Value: tls-id-value
Usage Level: media Usage Level: media
Charset Dependent: no Charset Dependent: no
Default Value: N/A Default Value: N/A
skipping to change at page 6, line 52 skipping to change at page 6, line 50
updated to support the 'tls-id' attribute), unless there is another updated to support the 'tls-id' attribute), unless there is another
mechanism to explicitly indicate that a new DTLS association is to be mechanism to explicitly indicate that a new DTLS association is to be
established, a modification of one or more of the following established, a modification of one or more of the following
characteristics MUST be treated as an indication that an endpoint characteristics MUST be treated as an indication that an endpoint
wants to establish a new DTLS association: wants to establish a new DTLS association:
o DTLS setup role; or o DTLS setup role; or
o fingerprint set; or o fingerprint set; or
o local transport parameters; or o local transport parameters
NOTE: A modification of the ufrag value is not treated as an
Internet-DrafSession Description Protocol (SDP) Offer/Answer August 2017 indication that an endpoint wants to establish a new DTLS assocation.
In order to indicate that a new DTLS association is to be
o ICE ufrag value established, one or more of the characteristics listed above have to
be modified.
The mux category [I-D.ietf-mmusic-sdp-mux-attributes] for the 'tls- The mux category [I-D.ietf-mmusic-sdp-mux-attributes] for the 'tls-
id' attribute is 'IDENTICAL', which means that the attribute value id' attribute is 'IDENTICAL', which means that the attribute value
applies to all media descriptions being multiplexed applies to all media descriptions being multiplexed
[I-D.ietf-mmusic-sdp-bundle-negotiation]. However, as described in [I-D.ietf-mmusic-sdp-bundle-negotiation]. However, as described in
[I-D.ietf-mmusic-sdp-bundle-negotiation], in order to avoid [I-D.ietf-mmusic-sdp-bundle-negotiation], in order to avoid
duplication the attribute is only associated with the "m=" line duplication the attribute is only associated with the "m=" line
representing the offerer/answerer BUNDLE-tag. representing the offerer/answerer BUNDLE-tag.
For RTP-based media, the 'tls-id' attribute applies to the whole For RTP-based media, the 'tls-id' attribute applies to the whole
skipping to change at page 8, line 4 skipping to change at page 8, line 8
new DTLS association can be de-multiplexed. In case of an ordered new DTLS association can be de-multiplexed. In case of an ordered
transport (e.g., SCTP) this can be done simply by sending packets for transport (e.g., SCTP) this can be done simply by sending packets for
the new DTLS association after all packets associated with a the new DTLS association after all packets associated with a
previously established DTLS association has been sent. In case of an previously established DTLS association has been sent. In case of an
unordered transport, such as UDP, packets associated with a unordered transport, such as UDP, packets associated with a
previously established DTLS association can arrive after the answer previously established DTLS association can arrive after the answer
SDP was received and after the first packets associated with the new SDP was received and after the first packets associated with the new
DTLS association were received. The only way to de-multiplex packets DTLS association were received. The only way to de-multiplex packets
associated with with a previously established DTLS association and associated with with a previously established DTLS association and
the new DTLS association is on the basis of transport 5-tuple. the new DTLS association is on the basis of transport 5-tuple.
Internet-DrafSession Description Protocol (SDP) Offer/Answer August 2017
Because of this, if an unordered transport is used for the DTLS Because of this, if an unordered transport is used for the DTLS
association, a new transport (3-tuple) must be allocated by at least association, a new transport (3-tuple) must be allocated by at least
one of the endpoints so that DTLS packets can be de-multiplexed. one of the endpoints so that DTLS packets can be de-multiplexed.
When an offerer needs to establish a new DTLS association, and if an When an offerer needs to establish a new DTLS association, and if an
unordered transport (e.g., UDP) is used, the offerer MUST allocate a unordered transport (e.g., UDP) is used, the offerer MUST allocate a
new transport (3-tuple) for the offer in such a way that the offerer new transport (3-tuple) for the offer in such a way that the offerer
can disambiguate any packets associated with the new DTLS association can disambiguate any packets associated with the new DTLS association
from any packets associated with any other DTLS association. This from any packets associated with any other DTLS association. This
typically means using a local address and/or port, or a set of ICE typically means using a local address and/or port, or a set of ICE
skipping to change at page 9, line 4 skipping to change at page 9, line 9
attribute has been defined. attribute has been defined.
Unlike for TCP and TLS connections, endpoints MUST NOT use the SDP Unlike for TCP and TLS connections, endpoints MUST NOT use the SDP
'setup' attribute 'holdconn' value when negotiating a DTLS 'setup' attribute 'holdconn' value when negotiating a DTLS
association. association.
Endpoints MUST support the hash functions as defined in [RFC8122]. Endpoints MUST support the hash functions as defined in [RFC8122].
The certificate received during the DTLS handshake [RFC6347] MUST The certificate received during the DTLS handshake [RFC6347] MUST
match a certificate fingerprint received in SDP 'fingerprint' match a certificate fingerprint received in SDP 'fingerprint'
Internet-DrafSession Description Protocol (SDP) Offer/Answer August 2017
attributes according to the procedures defined in [RFC8122]. If attributes according to the procedures defined in [RFC8122]. If
fingerprints do not match the hashed certificate, then an endpoint fingerprints do not match the hashed certificate, then an endpoint
MUST tear down the media session immediately (see [RFC8122]). Note MUST tear down the media session immediately (see [RFC8122]). Note
that it is permissible to wait until the other side's fingerprint(s) that it is permissible to wait until the other side's fingerprint(s)
has been received before establishing the connection; however, this has been received before establishing the connection; however, this
may have undesirable latency effects. may have undesirable latency effects.
SDP offerers and answerers might reuse certificates across multiple SDP offerers and answerers might reuse certificates across multiple
DTLS associations, and provide identical fingerprint values for each DTLS associations, and provide identical fingerprint values for each
DTLS association. The combination of the SDP 'tls-id' attribute DTLS association. The combination of the SDP 'tls-id' attribute
skipping to change at page 10, line 4 skipping to change at page 10, line 7
attribute value, the offerer MUST be prepared to receive a DTLS attribute value, the offerer MUST be prepared to receive a DTLS
ClientHello message [RFC6347] (if a new DTLS association is ClientHello message [RFC6347] (if a new DTLS association is
established by the answerer) from the answerer before the offerer established by the answerer) from the answerer before the offerer
receives the SDP answer. receives the SDP answer.
If the offerer receives a DTLS ClientHello message, and a DTLS If the offerer receives a DTLS ClientHello message, and a DTLS
association is established, before the offerer receives the SDP association is established, before the offerer receives the SDP
Answer carrying the fingerprint associated with the DTLS association, Answer carrying the fingerprint associated with the DTLS association,
any data received on the DTLS association before the fingerprint MUST any data received on the DTLS association before the fingerprint MUST
be considered coming from an unverified source. The processing of be considered coming from an unverified source. The processing of
Internet-DrafSession Description Protocol (SDP) Offer/Answer August 2017
such data, and sending of data by the offerer to the unverified such data, and sending of data by the offerer to the unverified
source, is outside the scope of this document. source, is outside the scope of this document.
5.3. Generating the Answer 5.3. Generating the Answer
When an answerer sends an answer, the answerer MUST insert in the When an answerer sends an answer, the answerer MUST insert in the
answer an SDP 'setup' attribute according to the procedures in answer an SDP 'setup' attribute according to the procedures in
[RFC4145], and one or more SDP 'fingerprint' attributes according to [RFC4145], and one or more SDP 'fingerprint' attributes according to
the procedures in [RFC8122]. If the answerer determines, based on the procedures in [RFC8122]. If the answerer determines, based on
the criteria specified in Section 3.1, that a new DTLS association is the criteria specified in Section 3.1, that a new DTLS association is
skipping to change at page 11, line 5 skipping to change at page 11, line 7
the answer, the answerer MUST initiate a DTLS handshake by sending a the answer, the answerer MUST initiate a DTLS handshake by sending a
DTLS ClientHello message towards the offerer. DTLS ClientHello message towards the offerer.
Even though an offerer is required to insert an 'SDP' setup attribute Even though an offerer is required to insert an 'SDP' setup attribute
with an 'actpass' attribute value in initial offers (Section 5.2) and with an 'actpass' attribute value in initial offers (Section 5.2) and
subsequent offers (Section 5.5), the answerer MUST be able to receive subsequent offers (Section 5.5), the answerer MUST be able to receive
initial and subsequent offers with other attribute values, in order initial and subsequent offers with other attribute values, in order
to be backward compatible with older implementations that might to be backward compatible with older implementations that might
insert other attribute values in initial and subsequent offers. insert other attribute values in initial and subsequent offers.
Internet-DrafSession Description Protocol (SDP) Offer/Answer August 2017
5.4. Offerer Processing of the SDP Answer 5.4. Offerer Processing of the SDP Answer
When an offerer receives an answer that establishes a new DTLS When an offerer receives an answer that establishes a new DTLS
association based on criteria defined in Section 3.1, and if the association based on criteria defined in Section 3.1, and if the
offerer becomes DTLS client (based on the value of the SDP 'setup' offerer becomes DTLS client (based on the value of the SDP 'setup'
attribute value [RFC4145]), the offerer MUST establish a DTLS attribute value [RFC4145]), the offerer MUST establish a DTLS
association. If the offerer becomes DTLS server, it MUST wait for association. If the offerer becomes DTLS server, it MUST wait for
the answerer to establish the DTLS association. the answerer to establish the DTLS association.
If the offerer indicated a desire to reuse an existing DTLS If the offerer indicated a desire to reuse an existing DTLS
skipping to change at page 12, line 5 skipping to change at page 12, line 5
'setup' attribute with an 'actpass' attribute value, and one or more 'setup' attribute with an 'actpass' attribute value, and one or more
SDP 'fingerprint' attributes with attribute values that do not change SDP 'fingerprint' attributes with attribute values that do not change
the previously sent fingerprint set, in the offer. In addition, the the previously sent fingerprint set, in the offer. In addition, the
offerer MUST insert an SDP 'tls-id' attribute with the previously offerer MUST insert an SDP 'tls-id' attribute with the previously
assigned attribute value in the offer. assigned attribute value in the offer.
NOTE: When a new DTLS association is being established, each endpoint NOTE: When a new DTLS association is being established, each endpoint
needs to be prepared to receive data on both the new and old DTLS needs to be prepared to receive data on both the new and old DTLS
associations as long as both are alive. associations as long as both are alive.
Internet-DrafSession Description Protocol (SDP) Offer/Answer August 2017
6. ICE Considerations 6. ICE Considerations
When the Interactive Connectivity Establishment (ICE) mechanism When the Interactive Connectivity Establishment (ICE) mechanism
[I-D.ietf-ice-rfc5245bis] is used, the ICE connectivity checks are [I-D.ietf-ice-rfc5245bis] is used, the ICE connectivity checks are
performed before the DTLS handshake begins. Note that if aggressive performed before the DTLS handshake begins. Note that if aggressive
nomination mode is used, multiple candidate pairs may be marked valid nomination mode is used, multiple candidate pairs may be marked valid
before ICE finally converges on a single candidate pair. before ICE finally converges on a single candidate pair.
NOTE: Aggressive nomination has been deprecated from ICE, but must NOTE: Aggressive nomination has been deprecated from ICE, but must
still be supported for backwards compatibility reasons still be supported for backwards compatibility reasons
skipping to change at page 13, line 4 skipping to change at page 13, line 4
As specified in [RFC4145], the SDP 'connection' attribute is used to As specified in [RFC4145], the SDP 'connection' attribute is used to
indicate whether to establish a new TLS connection. An offerer and indicate whether to establish a new TLS connection. An offerer and
answerer MUST ensure that the 'connection' attribute value and the answerer MUST ensure that the 'connection' attribute value and the
'tls-id' attribute value does not cause a conflict regarding whether 'tls-id' attribute value does not cause a conflict regarding whether
a new TLS connection is to be established or not. a new TLS connection is to be established or not.
NOTE: Even though the SDP 'connection' attribute can be used to NOTE: Even though the SDP 'connection' attribute can be used to
indicate whether a new TLS connection is to be established, the indicate whether a new TLS connection is to be established, the
unique combination of SDP 'tls-id' attribute values can be used to unique combination of SDP 'tls-id' attribute values can be used to
identity a TLS connection. The unique value can be used e.g., within identity a TLS connection. The unique value can be used e.g., within
Internet-DrafSession Description Protocol (SDP) Offer/Answer August 2017
TLS protocol extensions to differentiate between multiple TLS TLS protocol extensions to differentiate between multiple TLS
connections and correlate those connections with specific offer/ connections and correlate those connections with specific offer/
answer exchanges. One such extension is defined in answer exchanges. One such extension is defined in
[I-D.ietf-mmusic-sdp-uks]. [I-D.ietf-mmusic-sdp-uks].
If an offerer or answerer inserts an SDP 'connection' attribute with If an offerer or answerer inserts an SDP 'connection' attribute with
a 'new' value in the offer/answer and also inserts an SDP 'tls-id' a 'new' value in the offer/answer and also inserts an SDP 'tls-id'
attribute, the value of tls-id' attribute MUST be new and unique. attribute, the value of tls-id' attribute MUST be new and unique.
If an offerer or answerer inserts an SDP 'connection' attribute with If an offerer or answerer inserts an SDP 'connection' attribute with
skipping to change at page 14, line 5 skipping to change at page 14, line 5
c=IN IP4 192.0.2.2 c=IN IP4 192.0.2.2
a=tls-id:abc3de65cddef001be82 a=tls-id:abc3de65cddef001be82
a=setup:passive a=setup:passive
a=connection:new a=connection:new
a=fingerprint:SHA-256 \ a=fingerprint:SHA-256 \
12:DF:3E:5D:49:6B:19:E5:7C:AB:4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF: \ 12:DF:3E:5D:49:6B:19:E5:7C:AB:4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF: \
3E:5D:49:6B:19:E5:7C:AB:4A:AD 3E:5D:49:6B:19:E5:7C:AB:4A:AD
a=fingerprint:SHA-1 \ a=fingerprint:SHA-1 \
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
Internet-DrafSession Description Protocol (SDP) Offer/Answer August 2017
8. SIP Considerations 8. SIP Considerations
When the Session Initiation Protocol (SIP) [RFC3261] is used as the When the Session Initiation Protocol (SIP) [RFC3261] is used as the
signal protocol for establishing a multimedia session, dialogs signal protocol for establishing a multimedia session, dialogs
[RFC3261] might be established between the caller and multiple [RFC3261] might be established between the caller and multiple
callees. This is referred to as forking. If forking occurs, callees. This is referred to as forking. If forking occurs,
separate DTLS associations will be established between the caller and separate DTLS associations will be established between the caller and
each callee. each callee.
When forking occurs, an SDP offerer can receive DTLS ClientHello When forking occurs, an SDP offerer can receive DTLS ClientHello
skipping to change at page 15, line 5 skipping to change at page 15, line 5
This section updates specifications that use DTLS-protected media, in This section updates specifications that use DTLS-protected media, in
order to reflect the procedures defined in this specification. order to reflect the procedures defined in this specification.
9.2. Update to RFC 5763 9.2. Update to RFC 5763
9.2.1. Update to section 1 9.2.1. Update to section 1
The reference to [RFC4572] is replaced with a reference to [RFC8122]. The reference to [RFC4572] is replaced with a reference to [RFC8122].
Internet-DrafSession Description Protocol (SDP) Offer/Answer August 2017
9.2.2. Update to section 5 9.2.2. Update to section 5
The text in section 5 (Establishing a Secure Channel) is modified by The text in section 5 (Establishing a Secure Channel) is modified by
replacing generic SDP offer/answer procedures for DTLS with a replacing generic SDP offer/answer procedures for DTLS with a
reference to this specification: reference to this specification:
NEW TEXT: NEW TEXT:
The two endpoints in the exchange present their identities as part of The two endpoints in the exchange present their identities as part of
the DTLS handshake procedure using certificates. This document uses the DTLS handshake procedure using certificates. This document uses
skipping to change at page 16, line 4 skipping to change at page 16, line 4
Since the Identity header field is a digital signature across several Since the Identity header field is a digital signature across several
SIP header fields, in addition to the body of the SIP message, the SIP header fields, in addition to the body of the SIP message, the
receiver can also be certain that the message has not been tampered receiver can also be certain that the message has not been tampered
with after the digital signature was applied and added to the SIP with after the digital signature was applied and added to the SIP
message. message.
The far endpoint (answerer) may now establish a DTLS association with The far endpoint (answerer) may now establish a DTLS association with
the offerer. Alternately, it can indicate in its answer that the the offerer. Alternately, it can indicate in its answer that the
offerer is to initiate the DTLS association. In either case, mutual offerer is to initiate the DTLS association. In either case, mutual
DTLS certificate-based authentication will be used. After completing DTLS certificate-based authentication will be used. After completing
Internet-DrafSession Description Protocol (SDP) Offer/Answer August 2017
the DTLS handshake, information about the authenticated identities, the DTLS handshake, information about the authenticated identities,
including the certificates, are made available to the endpoint including the certificates, are made available to the endpoint
application. The answerer is then able to verify that the offerer's application. The answerer is then able to verify that the offerer's
certificate used for authentication in the DTLS handshake can be certificate used for authentication in the DTLS handshake can be
associated to a certificate fingerprint contained in the offer in associated to a certificate fingerprint contained in the offer in
the SDP. At this point, the answerer may indicate to the end user the SDP. At this point, the answerer may indicate to the end user
that the media is secured. The offerer may only tentatively accept that the media is secured. The offerer may only tentatively accept
the answerer's certificate since it may not yet have the answerer's the answerer's certificate since it may not yet have the answerer's
certificate fingerprint. certificate fingerprint.
skipping to change at page 17, line 5 skipping to change at page 17, line 5
request a session modification that MAY include an updated offer. request a session modification that MAY include an updated offer.
This session modification can be carried in either an INVITE or This session modification can be carried in either an INVITE or
UPDATE request. The peers can reuse an existing DTLS association, UPDATE request. The peers can reuse an existing DTLS association,
or establish a new one, following the procedures in [RFCXXXX]. or establish a new one, following the procedures in [RFCXXXX].
9.2.4. Update to section 6.7.1 9.2.4. Update to section 6.7.1
The text in section 6.7.1 (ICE Interaction) is modified by replacing The text in section 6.7.1 (ICE Interaction) is modified by replacing
the ICE procedures with a reference to this specification: the ICE procedures with a reference to this specification:
Internet-DrafSession Description Protocol (SDP) Offer/Answer August 2017
NEW TEXT: NEW TEXT:
The Interactive Connectivity Establishment (ICE) The Interactive Connectivity Establishment (ICE)
[I-D.ietf-ice-rfc5245bis] considerations for DTLS-protected media [I-D.ietf-ice-rfc5245bis] considerations for DTLS-protected media
are described in [RFCXXXX]. are described in [RFCXXXX].
9.3. Update to RFC 7345 9.3. Update to RFC 7345
9.3.1. Update to section 4 9.3.1. Update to section 4
skipping to change at page 18, line 5 skipping to change at page 18, line 5
NEW TEXT: NEW TEXT:
The Interactive Connectivity Establishment (ICE) The Interactive Connectivity Establishment (ICE)
[I-D.ietf-ice-rfc5245bis] considerations for DTLS-protected media [I-D.ietf-ice-rfc5245bis] considerations for DTLS-protected media
are described in [RFCXXXX]. are described in [RFCXXXX].
[RFC EDITOR NOTE: Throughout the document, please replace RFCXXXX [RFC EDITOR NOTE: Throughout the document, please replace RFCXXXX
with the RFC number of this document.] with the RFC number of this document.]
Internet-DrafSession Description Protocol (SDP) Offer/Answer August 2017
9.3.3. Update to section 10.1 9.3.3. Update to section 10.1
A reference to [RFC8122] is added to section 10.1 (Normative A reference to [RFC8122] is added to section 10.1 (Normative
References): References):
NEW TEXT: NEW TEXT:
[RFC8122] Lennox, J. and C. Holmberg, "Connection-Oriented Media [RFC8122] Lennox, J. and C. Holmberg, "Connection-Oriented Media
Transport over the Transport Layer Security (TLS) Protocol Transport over the Transport Layer Security (TLS) Protocol
in the Session Description Protocol (SDP)", RFC 8122, in the Session Description Protocol (SDP)", RFC 8122,
skipping to change at page 19, line 5 skipping to change at page 19, line 5
Attribute name: tls-id Attribute name: tls-id
Type of attribute: media-level Type of attribute: media-level
Subject to charset: no Subject to charset: no
Purpose: Indicates whether a new DTLS association or TLS connection Purpose: Indicates whether a new DTLS association or TLS connection
is to be established/re-established. is to be established/re-established.
Appropriate Values: see Section 4 Appropriate Values: see Section 4
Contact name: Christer Holmberg Contact name: Christer Holmberg
Mux Category: IDENTICAL Mux Category: IDENTICAL
Internet-DrafSession Description Protocol (SDP) Offer/Answer August 2017
12. Acknowledgements 12. Acknowledgements
Thanks to Justin Uberti, Martin Thomson, Paul Kyzivat, Jens Guballa, Thanks to Justin Uberti, Martin Thomson, Paul Kyzivat, Jens Guballa,
Charles Eckel, Gonzalo Salgueiro and Paul Jones for providing Charles Eckel, Gonzalo Salgueiro and Paul Jones for providing
comments and suggestions on the document. Ben Campbell performed an comments and suggestions on the document. Ben Campbell performed an
AD review. Paul Kyzivat performed a gen-art review. AD review. Paul Kyzivat performed a gen-art review.
13. Change Log 13. Change Log
[RFC EDITOR NOTE: Please remove this section when publishing] [RFC EDITOR NOTE: Please remove this section when publishing]
Changes from draft-ietf-mmusic-sdp-dtls-29
o Removal of ufrag value change as a trigger for a new DTLS
association
Changes from draft-ietf-mmusic-sdp-dtls-28 Changes from draft-ietf-mmusic-sdp-dtls-28
o Changes based on IESG review by Adam Roach, Eric Rescorla, Alexey o Changes based on IESG review by Adam Roach, Eric Rescorla, Alexey
Melnikov and Mirja Kuhlewind: Melnikov and Mirja Kuhlewind:
o - Document title changed o - Document title changed
o - Transport Protocol Considerations section removed o - Transport Protocol Considerations section removed
o - Additional text to Security Considerations section o - Additional text to Security Considerations section
skipping to change at page 20, line 5 skipping to change at page 20, line 10
o Changes based on 2nd WGLC comments from Roman S and Martin T: o Changes based on 2nd WGLC comments from Roman S and Martin T:
o - RFC update structure shortened (old text removed). o - RFC update structure shortened (old text removed).
o - Guidance regarding receiving ClientHello before SDP answer o - Guidance regarding receiving ClientHello before SDP answer
added. added.
o - Additional SIP condierations regarding forking. o - Additional SIP condierations regarding forking.
Internet-DrafSession Description Protocol (SDP) Offer/Answer August 2017
o - SDP setup attribute value restriction in initial and subsequent o - SDP setup attribute value restriction in initial and subsequent
offers based on comment from Ekr. offers based on comment from Ekr.
Changes from draft-ietf-mmusic-sdp-dtls-23 Changes from draft-ietf-mmusic-sdp-dtls-23
o Editrial change to make it clear that the document does not modify o Editrial change to make it clear that the document does not modify
the procedures in RFC 8122. the procedures in RFC 8122.
Changes from draft-ietf-mmusic-sdp-dtls-22 Changes from draft-ietf-mmusic-sdp-dtls-22
skipping to change at page 20, line 49 skipping to change at page 21, line 4
Changes from draft-ietf-mmusic-sdp-dtls-18 Changes from draft-ietf-mmusic-sdp-dtls-18
o Changes based on comments from Flemming. o Changes based on comments from Flemming.
o - Change in tls-id value definition. o - Change in tls-id value definition.
o - Editorial fixes. o - Editorial fixes.
Changes from draft-ietf-mmusic-sdp-dtls-17 Changes from draft-ietf-mmusic-sdp-dtls-17
o Reference fix. o Reference fix.
Changes from draft-ietf-mmusic-sdp-dtls-16 Changes from draft-ietf-mmusic-sdp-dtls-16
Internet-DrafSession Description Protocol (SDP) Offer/Answer August 2017
o Editorial changes based on 2nd WGLC comments from Christian Groves o Editorial changes based on 2nd WGLC comments from Christian Groves
and Nevenka Biondic. and Nevenka Biondic.
Changes from draft-ietf-mmusic-sdp-dtls-15 Changes from draft-ietf-mmusic-sdp-dtls-15
o tls-id attribute value made globally unique o tls-id attribute value made globally unique
Changes from draft-ietf-mmusic-sdp-dtls-14 Changes from draft-ietf-mmusic-sdp-dtls-14
o Changes based on comments from Flemming: o Changes based on comments from Flemming:
skipping to change at page 22, line 5 skipping to change at page 22, line 8
and Paul Kyzivat. and Paul Kyzivat.
Changes from draft-ietf-mmusic-sdp-dtls-08 Changes from draft-ietf-mmusic-sdp-dtls-08
o Offer/Answer section modified in order to allow sending of o Offer/Answer section modified in order to allow sending of
multiple SDP 'fingerprint' attributes. multiple SDP 'fingerprint' attributes.
o Terminology made consistent: 'DTLS connection' replaced with 'DTLS o Terminology made consistent: 'DTLS connection' replaced with 'DTLS
association'. association'.
Internet-DrafSession Description Protocol (SDP) Offer/Answer August 2017
o Editorial changes based on comments from Paul Kyzivat. o Editorial changes based on comments from Paul Kyzivat.
Changes from draft-ietf-mmusic-sdp-dtls-07 Changes from draft-ietf-mmusic-sdp-dtls-07
o Reference to RFC 7315 replaced with reference to RFC 7345. o Reference to RFC 7315 replaced with reference to RFC 7345.
Changes from draft-ietf-mmusic-sdp-dtls-06 Changes from draft-ietf-mmusic-sdp-dtls-06
o Text on restrictions regarding spanning a DTLS association over o Text on restrictions regarding spanning a DTLS association over
multiple transports added. multiple transports added.
skipping to change at page 23, line 5 skipping to change at page 23, line 8
o - Making note into normative text in o/a section. o - Making note into normative text in o/a section.
o Changes based on comments from Martin Thompson: o Changes based on comments from Martin Thompson:
o - Abbreviations section removed. o - Abbreviations section removed.
o - Clarify that a new DTLS association requires a new o/a o - Clarify that a new DTLS association requires a new o/a
transaction. transaction.
Internet-DrafSession Description Protocol (SDP) Offer/Answer August 2017
Changes from draft-ietf-mmusic-sdp-dtls-02 Changes from draft-ietf-mmusic-sdp-dtls-02
o - Updated RFCs added to boilerplate. o - Updated RFCs added to boilerplate.
Changes from draft-ietf-mmusic-sdp-dtls-01 Changes from draft-ietf-mmusic-sdp-dtls-01
o - Annex regarding 'tls-id-id' attribute removed. o - Annex regarding 'tls-id-id' attribute removed.
o - Additional SDP offer/answer procedures, related to certificates, o - Additional SDP offer/answer procedures, related to certificates,
added. added.
skipping to change at page 24, line 4 skipping to change at page 24, line 8
o - Section about multiple SDP fingerprint attributes added. o - Section about multiple SDP fingerprint attributes added.
Changes from draft-holmberg-mmusic-sdp-dtls-00 Changes from draft-holmberg-mmusic-sdp-dtls-00
o - Editorial changes and clarifications. o - Editorial changes and clarifications.
14. References 14. References
14.1. Normative References 14.1. Normative References
Internet-DrafSession Description Protocol (SDP) Offer/Answer August 2017
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, <https://www.rfc- DOI 10.17487/RFC2119, March 1997,
editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, <https://www.rfc- DOI 10.17487/RFC3261, June 2002,
editor.org/info/rfc3261>. <https://www.rfc-editor.org/info/rfc3261>.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
DOI 10.17487/RFC3264, June 2002, <https://www.rfc- DOI 10.17487/RFC3264, June 2002,
editor.org/info/rfc3264>. <https://www.rfc-editor.org/info/rfc3264>.
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in
the Session Description Protocol (SDP)", RFC 4145, the Session Description Protocol (SDP)", RFC 4145,
DOI 10.17487/RFC4145, September 2005, <https://www.rfc- DOI 10.17487/RFC4145, September 2005,
editor.org/info/rfc4145>. <https://www.rfc-editor.org/info/rfc4145>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, DOI 10.17487/RFC4566, Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
July 2006, <https://www.rfc-editor.org/info/rfc4566>. July 2006, <https://www.rfc-editor.org/info/rfc4566>.
[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
for Establishing a Secure Real-time Transport Protocol for Establishing a Secure Real-time Transport Protocol
(SRTP) Security Context Using Datagram Transport Layer (SRTP) Security Context Using Datagram Transport Layer
Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May
2010, <https://www.rfc-editor.org/info/rfc5763>. 2010, <https://www.rfc-editor.org/info/rfc5763>.
skipping to change at page 24, line 49 skipping to change at page 25, line 8
January 2012, <https://www.rfc-editor.org/info/rfc6347>. January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC7345] Holmberg, C., Sedlacek, I., and G. Salgueiro, "UDP [RFC7345] Holmberg, C., Sedlacek, I., and G. Salgueiro, "UDP
Transport Layer (UDPTL) over Datagram Transport Layer Transport Layer (UDPTL) over Datagram Transport Layer
Security (DTLS)", RFC 7345, DOI 10.17487/RFC7345, August Security (DTLS)", RFC 7345, DOI 10.17487/RFC7345, August
2014, <https://www.rfc-editor.org/info/rfc7345>. 2014, <https://www.rfc-editor.org/info/rfc7345>.
[RFC8122] Lennox, J. and C. Holmberg, "Connection-Oriented Media [RFC8122] Lennox, J. and C. Holmberg, "Connection-Oriented Media
Transport over the Transport Layer Security (TLS) Protocol Transport over the Transport Layer Security (TLS) Protocol
in the Session Description Protocol (SDP)", RFC 8122, in the Session Description Protocol (SDP)", RFC 8122,
DOI 10.17487/RFC8122, March 2017, <https://www.rfc- DOI 10.17487/RFC8122, March 2017,
editor.org/info/rfc8122>. <https://www.rfc-editor.org/info/rfc8122>.
Internet-DrafSession Description Protocol (SDP) Offer/Answer August 2017
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[I-D.ietf-ice-rfc5245bis] [I-D.ietf-ice-rfc5245bis]
Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
Connectivity Establishment (ICE): A Protocol for Network Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal", draft-ietf-ice- Address Translator (NAT) Traversal", draft-ietf-ice-
rfc5245bis-10 (work in progress), May 2017. rfc5245bis-10 (work in progress), May 2017.
skipping to change at page 25, line 33 skipping to change at page 25, line 37
Holmberg, C., Alvestrand, H., and C. Jennings, Holmberg, C., Alvestrand, H., and C. Jennings,
"Negotiating Media Multiplexing Using the Session "Negotiating Media Multiplexing Using the Session
Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-
negotiation-38 (work in progress), April 2017. negotiation-38 (work in progress), April 2017.
14.2. Informative References 14.2. Informative References
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for [RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, Initiation Protocol (SIP)", RFC 4474,
DOI 10.17487/RFC4474, August 2006, <https://www.rfc- DOI 10.17487/RFC4474, August 2006,
editor.org/info/rfc4474>. <https://www.rfc-editor.org/info/rfc4474>.
[RFC4572] Lennox, J., "Connection-Oriented Media Transport over the [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the
Transport Layer Security (TLS) Protocol in the Session Transport Layer Security (TLS) Protocol in the Session
Description Protocol (SDP)", RFC 4572, Description Protocol (SDP)", RFC 4572,
DOI 10.17487/RFC4572, July 2006, <https://www.rfc- DOI 10.17487/RFC4572, July 2006,
editor.org/info/rfc4572>. <https://www.rfc-editor.org/info/rfc4572>.
[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific
Media Attributes in the Session Description Protocol Media Attributes in the Session Description Protocol
(SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009,
<https://www.rfc-editor.org/info/rfc5576>. <https://www.rfc-editor.org/info/rfc5576>.
[RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram [RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram
Transport Layer Security (DTLS) for Stream Control Transport Layer Security (DTLS) for Stream Control
Transmission Protocol (SCTP)", RFC 6083, Transmission Protocol (SCTP)", RFC 6083,
DOI 10.17487/RFC6083, January 2011, <https://www.rfc- DOI 10.17487/RFC6083, January 2011,
editor.org/info/rfc6083>. <https://www.rfc-editor.org/info/rfc6083>.
Internet-DrafSession Description Protocol (SDP) Offer/Answer August 2017
[RFC7983] Petit-Huguenin, M. and G. Salgueiro, "Multiplexing Scheme [RFC7983] Petit-Huguenin, M. and G. Salgueiro, "Multiplexing Scheme
Updates for Secure Real-time Transport Protocol (SRTP) Updates for Secure Real-time Transport Protocol (SRTP)
Extension for Datagram Transport Layer Security (DTLS)", Extension for Datagram Transport Layer Security (DTLS)",
RFC 7983, DOI 10.17487/RFC7983, September 2016, RFC 7983, DOI 10.17487/RFC7983, September 2016,
<https://www.rfc-editor.org/info/rfc7983>. <https://www.rfc-editor.org/info/rfc7983>.
[I-D.ietf-stir-rfc4474bis] [I-D.ietf-stir-rfc4474bis]
Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
"Authenticated Identity Management in the Session "Authenticated Identity Management in the Session
skipping to change at page 27, line 4 skipping to change at page 27, line 4
Authors' Addresses Authors' Addresses
Christer Holmberg Christer Holmberg
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 Jorvas 02420
Finland Finland
Email: christer.holmberg@ericsson.com Email: christer.holmberg@ericsson.com
Internet-DrafSession Description Protocol (SDP) Offer/Answer August 2017
Roman Shpount Roman Shpount
TurboBridge TurboBridge
4905 Del Ray Avenue, Suite 300 4905 Del Ray Avenue, Suite 300
Bethesda, MD 20814 Bethesda, MD 20814
USA USA
Phone: +1 (240) 292-6632 Phone: +1 (240) 292-6632
Email: rshpount@turbobridge.com Email: rshpount@turbobridge.com
 End of changes. 38 change blocks. 
85 lines changed or deleted 34 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/