< draft-petithuguenin-avtcore-rfc5764-mux-fixes-01.txt   draft-petithuguenin-avtcore-rfc5764-mux-fixes-02.txt >
AVTCORE M. Petit-Huguenin AVTCORE M. Petit-Huguenin
Internet-Draft Impedance Mismatch Internet-Draft Impedance Mismatch
Updates: 5764 (if approved) G. Salgueiro Updates: 5764 (if approved) G. Salgueiro
Intended status: Standards Track Cisco Systems Intended status: Standards Track Cisco Systems
Expires: April 27, 2015 October 24, 2014 Expires: September 7, 2015 March 6, 2015
Multiplexing Scheme Updates for Secure Real-time Transport Protocol Multiplexing Scheme Updates for Secure Real-time Transport Protocol
(SRTP) Extension for Datagram Transport Layer Security (DTLS) (SRTP) Extension for Datagram Transport Layer Security (DTLS)
draft-petithuguenin-avtcore-rfc5764-mux-fixes-01 draft-petithuguenin-avtcore-rfc5764-mux-fixes-02
Abstract Abstract
This document defines how Datagram Transport Layer Security (DTLS), This document defines how Datagram Transport Layer Security (DTLS),
Real-time Transport Protocol (RTP), Real-time Transport Control Real-time Transport Protocol (RTP), Real-time Transport Control
Protocol (RTCP), Session Traversal Utilities for NAT (STUN), and Protocol (RTCP), Session Traversal Utilities for NAT (STUN), and
Traversal Using Relays around NAT (TURN) packets are multiplexed on a Traversal Using Relays around NAT (TURN) packets are multiplexed on a
single receiving socket. It overrides the guidance from SRTP single receiving socket. It overrides the guidance from SRTP
Extension for DTLS [RFC5764], which suffered from three issues Extension for DTLS [RFC5764], which suffered from three issues
described and fixed in this document. described and fixed in this document.
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 April 27, 2015. This Internet-Draft will expire on September 7, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 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
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
skipping to change at page 3, line 32 skipping to change at page 3, line 32
that this restricts the codepoints for STUN methods (as described in that this restricts the codepoints for STUN methods (as described in
Section 18.1 of [RFC5389]) to values between 0x000 and 0x07F, which Section 18.1 of [RFC5389]) to values between 0x000 and 0x07F, which
in turn reduces the number of possible STUN method codepoints in turn reduces the number of possible STUN method codepoints
assigned by IETF Review (i.e., the range from (0x000 - 0x7FF) from assigned by IETF Review (i.e., the range from (0x000 - 0x7FF) from
2048 to only 128 and entirely obliterating those STUN method 2048 to only 128 and entirely obliterating those STUN method
codepoints assigned by Designated Expert (i.e., the range 0x800 - codepoints assigned by Designated Expert (i.e., the range 0x800 -
0xFFF). In fact, RFC 5764 implicitly (and needlessly) allocated a 0xFFF). In fact, RFC 5764 implicitly (and needlessly) allocated a
very large range of STUN methods, but at a minimum the IANA STUN very large range of STUN methods, but at a minimum the IANA STUN
Methods registry should properly reflect this. Methods registry should properly reflect this.
There are only a few STUN method codepoints currently allocated, but There are only a few STUN method codepoints currently allocated. For
this is largely attributed to the fact that STUN did not see much this reason, simply marking the implicit allocations made by RFC 5764
deployment until the development of WebRTC. For this reason, simply in the STUN Method registry may create a shortage of codepoints at a
marking the implicit allocations made by RFC 5764 in the STUN Method time when interest in STUN and STUN Usages (especially TURN) is
registry may create a shortage of codepoints at a time when interest growing rapidly. Consequently, this document also changes the RFC
in STUN and STUN Usages (especially TURN) is growing rapidly. 5764 packet identification algorithm to expand the range assigned to
Consequently, this document also changes the RFC 5764 packet the STUN protocol from 0 - 1 to 0 - 19, as the values 2-19 are
identification algorithm to expand the range assigned to the STUN unused.
protocol from 0 - 1 to 0 - 19, as the values 2-19 are unused.
In addition to explicitly allocating STUN methods codepoints from In addition to explicitly allocating STUN methods codepoints from
0x500 to 0xFFF as Reserved values, this document also updates the 0x500 to 0xFFF as Reserved values, this document also updates the
IANA registry such that the STUN method codepoints assigned via IETF IANA registry such that the STUN method codepoints assigned via IETF
Review are in the 0x000-0x27F range and those assigned via Designated Review are in the 0x000-0x27F range and those assigned via Designated
Expert are in the 0x280-0x4FF range. The proposed changes to the Expert are in the 0x280-0x4FF range. The proposed changes to the
STUN Method Registry is: STUN Method Registry is:
OLD: OLD:
skipping to change at page 9, line 29 skipping to change at page 9, line 29
[RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this
document.] document.]
7. Acknowledgements 7. Acknowledgements
The implicit STUN Method codepoint allocations problem was first The implicit STUN Method codepoint allocations problem was first
reported by Martin Thomson in the RTCWEB mailing-list and discussed reported by Martin Thomson in the RTCWEB mailing-list and discussed
further with Magnus Westerlund. further with Magnus Westerlund.
Thanks to Simon Perreault and Colton Shields for the comments, Thanks to Simon Perreault, Colton Shields and Cullen Jennings for the
suggestions, and questions that helped improve this document. comments, suggestions, and questions that helped improve this
document.
8. References 8. References
8.1. Normative References 8.1. Normative References
[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, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
 End of changes. 6 change blocks. 
15 lines changed or deleted 15 lines changed or added

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