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