draft-ietf-mmusic-udptl-dtls-09.txt   draft-ietf-mmusic-udptl-dtls-10.txt 
MMUSIC Working Group C. Holmberg MMUSIC Working Group C. Holmberg
Internet-Draft I. Sedlacek Internet-Draft I. Sedlacek
Intended status: Standards Track Ericsson Intended status: Standards Track Ericsson
Expires: December 18, 2014 G. Salgueiro Expires: December 22, 2014 G. Salgueiro
Cisco Cisco
June 16, 2014 June 20, 2014
UDP Transport Layer (UDPTL) over Datagram Transport Layer Security UDP Transport Layer (UDPTL) over Datagram Transport Layer Security
(DTLS) (DTLS)
draft-ietf-mmusic-udptl-dtls-09 draft-ietf-mmusic-udptl-dtls-10
Abstract Abstract
This document specifies how the UDP Transport Layer (UDPTL) protocol, This document specifies how the UDP Transport Layer (UDPTL) protocol,
the predominant transport protocol for T.38 fax, can be transported the predominant transport protocol for T.38 fax, can be transported
over the Datagram Transport Layer Security (DTLS) protocol, how the over the Datagram Transport Layer Security (DTLS) protocol, how the
usage of UDPTL over DTLS is indicated in the Session Description usage of UDPTL over DTLS is indicated in the Session Description
Protocol (SDP), and how UDPTL over DTLS is negotiated in a session Protocol (SDP), and how UDPTL over DTLS is negotiated in a session
established using the Session Initiation Protocol (SIP). established using the Session Initiation Protocol (SIP).
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 http://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 December 18, 2014. This Internet-Draft will expire on December 22, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 (http://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
skipping to change at page 2, line 27 skipping to change at page 2, line 27
4.3. Generating the Answer . . . . . . . . . . . . . . . . . . 6 4.3. Generating the Answer . . . . . . . . . . . . . . . . . . 6
4.4. Offerer Processing of the Answer . . . . . . . . . . . . 7 4.4. Offerer Processing of the Answer . . . . . . . . . . . . 7
4.5. Modifying the Session . . . . . . . . . . . . . . . . . . 7 4.5. Modifying the Session . . . . . . . . . . . . . . . . . . 7
5. Miscellaneous Considerations . . . . . . . . . . . . . . . . 7 5. Miscellaneous Considerations . . . . . . . . . . . . . . . . 7
5.1. Anonymous Calls . . . . . . . . . . . . . . . . . . . . . 7 5.1. Anonymous Calls . . . . . . . . . . . . . . . . . . . . . 7
5.2. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 7 5.2. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 7
5.2.1. ICE Usage . . . . . . . . . . . . . . . . . . . . . . 7 5.2.1. ICE Usage . . . . . . . . . . . . . . . . . . . . . . 7
5.2.2. STUN Interaction . . . . . . . . . . . . . . . . . . 8 5.2.2. STUN Interaction . . . . . . . . . . . . . . . . . . 8
5.3. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . 8 5.3. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . 8
5.4. Compatibility With UDPTL over UDP . . . . . . . . . . . . 8 5.4. Compatibility With UDPTL over UDP . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . 13 10.1. Normative References . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . 14 10.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 14 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 14
A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 14 A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 14
A.2. Basic Message Flow . . . . . . . . . . . . . . . . . . . 14 A.2. Basic Message Flow . . . . . . . . . . . . . . . . . . . 15
A.3. Message Flow Of T.38 Fax Replacing Audio Media Stream in A.3. Message Flow Of T.38 Fax Replacing Audio Media Stream in
An Existing Audio-Only Session . . . . . . . . . . . . . 20 An Existing Audio-Only Session . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
While it is possible to transmit highly sensitive documents using While it is possible to transmit highly sensitive documents using
traditional telephony encryption devices, secure fax on the Public traditional telephony encryption devices, secure fax on the Public
Switched Telephone Network (PSTN) was never widely considered or Switched Telephone Network (PSTN) was never widely considered or
prioritized. This was mainly because of the challenges involved with prioritized. This was mainly because of the challenges involved with
skipping to change at page 8, line 18 skipping to change at page 8, line 18
5.2.2. STUN Interaction 5.2.2. STUN Interaction
The UA MUST send the STUN packets [RFC5389] directly over UDP, not The UA MUST send the STUN packets [RFC5389] directly over UDP, not
over DTLS. over DTLS.
The UA MUST support the following mechanism for demultiplexing The UA MUST support the following mechanism for demultiplexing
packets arriving on the IP address and port associated with the DTLS packets arriving on the IP address and port associated with the DTLS
association: association:
o If the value of the first byte of the packet is between 0 and 19 o If the value of the first byte of the packet is 0 or 1, then the
(inclusive), then the packet is STUN. packet is STUN.
o If the value of the first byte of the packet is between 20 and 63 o If the value of the first byte of the packet is between 20 and 63
(inclusive), then the packet is DTLS. (inclusive), the packet is DTLS.
o If the value of the first byte of the packet is between 64 and 127
(inclusive), then the packet is TURN channel.
5.3. Rekeying 5.3. Rekeying
During rekeying, packets protected by the previous set of keys can During rekeying, packets protected by the previous set of keys can
arrive after the DTLS handshake caused by rekeying has completed, arrive after the DTLS handshake caused by rekeying has completed,
because packets can be reordered on the wire. To compensate for this because packets can be reordered on the wire. To compensate for this
fact, receivers MUST maintain both sets of keys for some time in fact, receivers MUST maintain both sets of keys for some time in
order to be able to decrypt and verify older packets. The duration order to be able to decrypt and verify older packets. The duration
of maintaining the previous set of keys after the finish of the DTLS of maintaining the previous set of keys after the finish of the DTLS
handshake is out of scope for this document. handshake is out of scope for this document.
skipping to change at page 10, line 32 skipping to change at page 10, line 32
provided valuable feedback and input. Barry Leiba, Spencer Dawkins, provided valuable feedback and input. Barry Leiba, Spencer Dawkins,
Pete Resnick, Kathleen Moriarty and Stephen Farrell provided valuable Pete Resnick, Kathleen Moriarty and Stephen Farrell provided valuable
feedback during the IESG review. Thanks to Scott Brim for performing feedback during the IESG review. Thanks to Scott Brim for performing
the Gen-ART review. Thanks to Alissa Cooper for her help as the Gen-ART review. Thanks to Alissa Cooper for her help as
sponsoring Area Director. sponsoring Area Director.
9. Change Log 9. 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-udptl-dtls-09
o Removal of previous changes based on comments by Marc Petit-
Huguenin:
o - Future correction might be needed based on generic NAT traversal
work in IETF.
Changes from draft-ietf-mmusic-udptl-dtls-08 Changes from draft-ietf-mmusic-udptl-dtls-08
o Changes based on comments by Marc Petit-Huguenin: o Changes based on comments by Marc Petit-Huguenin:
o - Corrected text on how to distinguish STUN, TURN and DTLS o - Corrected text on how to distinguish STUN, TURN and DTLS
packets. packets.
Changes from draft-ietf-mmusic-udptl-dtls-07 Changes from draft-ietf-mmusic-udptl-dtls-07
o Changes based on IESG comments by Barry Leiba: o Changes based on IESG comments by Barry Leiba:
o - SHALL replaced with MUST. o - SHALL replaced with MUST.
 End of changes. 9 change blocks. 
11 lines changed or deleted 16 lines changed or added

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