summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7983.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7983.txt')
-rw-r--r--doc/rfc/rfc7983.txt731
1 files changed, 731 insertions, 0 deletions
diff --git a/doc/rfc/rfc7983.txt b/doc/rfc/rfc7983.txt
new file mode 100644
index 0000000..a915656
--- /dev/null
+++ b/doc/rfc/rfc7983.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) M. Petit-Huguenin
+Request for Comments: 7983 Impedance Mismatch
+Updates: 5764 G. Salgueiro
+Category: Standards Track Cisco Systems
+ISSN: 2070-1721 September 2016
+
+
+ Multiplexing Scheme Updates
+ for Secure Real-time Transport Protocol (SRTP) Extension
+ for Datagram Transport Layer Security (DTLS)
+
+Abstract
+
+ This document defines how Datagram Transport Layer Security (DTLS),
+ Real-time Transport Protocol (RTP), RTP Control Protocol (RTCP),
+ Session Traversal Utilities for NAT (STUN), Traversal Using Relays
+ around NAT (TURN), and ZRTP packets are multiplexed on a single
+ receiving socket. It overrides the guidance from RFC 5764 ("SRTP
+ Extension for DTLS"), which suffered from four issues described and
+ fixed in this document.
+
+ This document updates RFC 5764.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 7841.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc7983.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Petit-Huguenin & Salgueiro Standards Track [Page 1]
+
+RFC 7983 Multiplexing Scheme Updates for RFC 5764 September 2016
+
+
+Copyright Notice
+
+ Copyright (c) 2016 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
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+ This document may contain material from IETF Documents or IETF
+ Contributions published or made publicly available before November
+ 10, 2008. The person(s) controlling the copyright in some of this
+ material may not have granted the IETF Trust the right to allow
+ modifications of such material outside the IETF Standards Process.
+ Without obtaining an adequate license from the person(s) controlling
+ the copyright in such materials, this document may not be modified
+ outside the IETF Standards Process, and derivative works of it may
+ not be created outside the IETF Standards Process, except to format
+ it for publication as an RFC or to translate it into languages other
+ than English.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 3. Implicit Allocation of Codepoints for New STUN Methods . . . 4
+ 4. Multiplexing of ZRTP . . . . . . . . . . . . . . . . . . . . 5
+ 5. Implicit Allocation of New Codepoints for TLS ContentTypes . 5
+ 6. Multiplexing of TURN Channels . . . . . . . . . . . . . . . . 7
+ 7. Updates to RFC 5764 . . . . . . . . . . . . . . . . . . . . . 8
+ 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
+ 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
+ 9.1. STUN Methods . . . . . . . . . . . . . . . . . . . . . . 10
+ 9.2. TLS ContentType . . . . . . . . . . . . . . . . . . . . . 10
+ 9.3. Traversal Using Relays around NAT (TURN) Channel Numbers 11
+ 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
+ 10.1. Normative References . . . . . . . . . . . . . . . . . . 11
+ 10.2. Informative References . . . . . . . . . . . . . . . . . 12
+ Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
+
+
+
+
+
+Petit-Huguenin & Salgueiro Standards Track [Page 2]
+
+RFC 7983 Multiplexing Scheme Updates for RFC 5764 September 2016
+
+
+1. Introduction
+
+ Section 5.1.2 of "Datagram Transport Layer Security (DTLS) Extension
+ to Establish Keys for the Secure Real-time Transport Protocol (SRTP)"
+ [RFC5764] defines a scheme for a Real-time Transport Protocol (RTP)
+ [RFC3550] receiver to demultiplex DTLS [RFC6347], Session Traversal
+ Utilities for NAT (STUN) [RFC5389], and Secure Real-time Transport
+ Protocol (SRTP) / Secure Real-time Transport Control Protocol (SRTCP)
+ [RFC3711] packets that are arriving on the RTP port. Unfortunately,
+ this demultiplexing scheme has created problematic issues:
+
+ 1. It implicitly allocated codepoints for new STUN methods without
+ an IANA registry reflecting these new allocations.
+
+ 2. It did not take into account the fact that ZRTP [RFC6189] also
+ needs to be demultiplexed with the other packet types explicitly
+ mentioned in Section 5.1.2 of RFC 5764.
+
+ 3. It implicitly allocated codepoints for new Transport Layer
+ Security (TLS) ContentTypes without an IANA registry reflecting
+ these new allocations.
+
+ 4. It did not take into account the fact that the Traversal Using
+ Relays around NAT (TURN) usage of STUN can create TURN channels
+ that also need to be demultiplexed with the other packet types
+ explicitly mentioned in Section 5.1.2 of RFC 5764.
+
+ Having overlapping ranges between different IANA registries becomes
+ an issue when a new codepoint is allocated in one of these registries
+ without carefully analyzing the impact it could have on the other
+ registries when that codepoint is demultiplexed. Among other
+ downsides of the bad design of the demultiplexing algorithm detailed
+ in [RFC5764], it creates a requirement for coordination between
+ codepoint assignments where none should exist, and that is
+ organizationally and socially undesirable. However, RFC 5764 has
+ been widely deployed, so there must be an awareness of this issue and
+ how it must be dealt with. Thus, even if the feature related to a
+ codepoint is not initially thought to be useful in the context of
+ demultiplexing, the respective IANA registry expert should at least
+ raise a flag when the allocated codepoint irrevocably prevents
+ multiplexing.
+
+
+
+
+
+
+
+
+
+
+Petit-Huguenin & Salgueiro Standards Track [Page 3]
+
+RFC 7983 Multiplexing Scheme Updates for RFC 5764 September 2016
+
+
+ The first goal of this document is to make sure that future
+ allocations in any of the affected protocols are done with the full
+ knowledge of their impact on multiplexing. This is achieved by
+ updating [RFC5764], which includes modifying the IANA registries with
+ instructions for coordination between the protocols at risk.
+
+ A second goal is to permit the addition of new protocols to the list
+ of existing multiplexed protocols in a manner that does not break
+ existing implementations.
+
+ At the time of this writing, the flaws in the demultiplexing scheme
+ were unavoidably inherited by other documents, such as [RFC7345] and
+ [SDP-BUNDLE]. So in addition, these and any other affected documents
+ will need to be corrected with the updates this document provides.
+
+2. Terminology
+
+ 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].
+
+3. Implicit Allocation of Codepoints for New STUN Methods
+
+ The demultiplexing scheme in [RFC5764] states that the receiver can
+ identify the packet type by looking at the first byte. If the value
+ of this first byte is 0 or 1, the packet is identified to be STUN.
+ The problem with this implicit allocation is that it restricts the
+ codepoints for STUN methods (as described in Section 18.1 of
+ [RFC5389]) to values between 0x000 and 0x07F, which in turn reduces
+ the number of possible STUN method codepoints assigned by IETF Review
+ (i.e., the range 0x000 - 0x7FF) from 2048 to only 128 and eliminates
+ the possibility of having STUN method codepoints assigned by
+ Designated Expert (i.e., the range 0x800 - 0xFFF).
+
+ To preserve the Designated Expert range, this document allocates the
+ values 2 and 3 to also identify STUN methods.
+
+ The IANA Registry for STUN methods has been modified to mark the
+ codepoints from 0x100 to 0xFFF as Reserved. These codepoints can
+ still be allocated, but require IETF Review with a document that will
+ properly evaluate the risk of an assignment overlapping with other
+ registries.
+
+
+
+
+
+
+
+
+
+Petit-Huguenin & Salgueiro Standards Track [Page 4]
+
+RFC 7983 Multiplexing Scheme Updates for RFC 5764 September 2016
+
+
+ In addition, this document also updates the IANA registry such that
+ the STUN method codepoints assigned in the 0x080-0x0FF range are also
+ assigned via Designated Expert. The "STUN Methods" registry has been
+ changed as follows:
+
+ OLD:
+
+ 0x000-0x7FF IETF Review
+ 0x800-0xFFF Designated Expert
+
+ NEW:
+
+ 0x000-0x07F IETF Review
+ 0x080-0x0FF Designated Expert
+ 0x100-0xFFF Reserved
+
+4. Multiplexing of ZRTP
+
+ ZRTP [RFC6189] is a protocol for media path Diffie-Hellman exchange
+ to agree on a session key and parameters for establishing unicast
+ SRTP sessions for Voice over IP (VoIP) applications. The ZRTP
+ protocol is media path keying because it is multiplexed on the same
+ port as RTP and does not require support in the signaling protocol.
+
+ In order to prevent future documents from assigning values from the
+ unused range to a new protocol, this document modifies the [RFC5764]
+ demultiplexing algorithm to properly account for ZRTP [RFC6189] by
+ allocating the values from 16 to 19 for this purpose.
+
+5. Implicit Allocation of New Codepoints for TLS ContentTypes
+
+ The demultiplexing scheme in [RFC5764] dictates that if the value of
+ the first byte is between 20 and 63 (inclusive), then the packet is
+ identified to be DTLS. For DTLS 1.0 [RFC4347] and DTLS 1.2
+ [RFC6347], that first byte corresponds to the TLS ContentType field.
+ Considerations must be taken into account when assigning additional
+ ContentTypes in the codepoint ranges 0 to 19 and 64 to 255, so this
+ does not prevent demultiplexing when this functionality is desirable.
+ Note that [RFC5764] describes a narrow use of DTLS that works as long
+ as the specific DTLS version used abides by the restrictions on the
+ demultiplexing byte (the ones that this document imposes on the "TLS
+ ContentType Registry"). Any extension or revision to DTLS that
+ causes it to no longer meet these constraints should consider what
+ values may occur in the first byte of the DTLS message and what
+ impact it would have on the multiplexing that [RFC5764] describes.
+
+
+
+
+
+
+Petit-Huguenin & Salgueiro Standards Track [Page 5]
+
+RFC 7983 Multiplexing Scheme Updates for RFC 5764 September 2016
+
+
+ With respect to TLS packet identification, this document explicitly
+ adds a warning to the codepoints from 0 to 19 and from 64 to 255
+ indicating that allocations in these ranges require coordination, as
+ described in this document. The "TLS ContentType Registry" has been
+ changed as follows:
+
+ OLD:
+
+ 0-19 Unassigned
+ 20 change_cipher_spec
+ 21 alert
+ 22 handshake
+ 23 application_data
+ 24 heartbeat
+ 25-255 Unassigned
+
+ NEW:
+
+ 0-19 Unassigned (Requires coordination; see RFC 7983)
+ 20 change_cipher_spec
+ 21 alert
+ 22 handshake
+ 23 application_data
+ 24 heartbeat
+ 25-63 Unassigned
+ 64-255 Unassigned (Requires coordination; see RFC 7983)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Petit-Huguenin & Salgueiro Standards Track [Page 6]
+
+RFC 7983 Multiplexing Scheme Updates for RFC 5764 September 2016
+
+
+6. Multiplexing of TURN Channels
+
+ When used with Interactive Connectivity Establishment (ICE)
+ [RFC5245], an implementation of RFC 5764 can receive packets on the
+ same socket from three different paths, as shown in Figure 1:
+
+ 1. Directly from the source
+
+ 2. Through a NAT
+
+ 3. Relayed by a TURN server
+
+ +------+
+ | TURN |<------------------------+
+ +------+ |
+ | |
+ | +-------------------------+ |
+ | | | |
+ v v | |
+ NAT ----------- | |
+ | | +---------------------+ | |
+ | | | | | |
+ v v v | | |
+ +----------+ +----------+
+ | RFC 5764 | | RFC 5764 |
+ +----------+ +----------+
+
+ Figure 1: Packet Reception by an Implementation of RFC 5764
+
+ Even if the ICE algorithm succeeded in selecting a non-relayed path,
+ it is still possible to receive data from the TURN server. For
+ instance, when ICE is used with aggressive nomination, the media path
+ can quickly change until it stabilizes. Also, freeing ICE candidates
+ is optional, so the TURN server can restart forwarding STUN
+ connectivity checks during an ICE restart.
+
+ TURN channels are an optimization where data packets are exchanged
+ with a 4-byte prefix instead of the standard 36-byte STUN overhead
+ (see Section 2.5 of [RFC5766]). The problem is that the RFC 5764
+ demultiplexing scheme does not define what to do with packets
+ received over a TURN channel since these packets will start with a
+ first byte whose value will be between 64 and 127 (inclusive). If
+ the TURN server was instructed to send data over a TURN channel, then
+ the demultiplexing scheme specified in RFC 5764 will reject these
+ packets. Current implementations violate RFC 5764 for values 64 to
+ 127 (inclusive) and they instead parse packets with such values as
+ TURN.
+
+
+
+
+Petit-Huguenin & Salgueiro Standards Track [Page 7]
+
+RFC 7983 Multiplexing Scheme Updates for RFC 5764 September 2016
+
+
+ In order to prevent future documents from assigning values from the
+ unused range to a new protocol, this document modifies the
+ demultiplexing algorithm in RFC 5764 to properly account for TURN
+ channels by allocating the values from 64 to 79 for this purpose.
+ This modification restricts the TURN channel space to a more limited
+ set of possible channels when the TURN client does the channel
+ binding request in combination with the demultiplexing scheme
+ described in [RFC5764].
+
+7. Updates to RFC 5764
+
+ This document updates the text in Section 5.1.2 of [RFC5764] as
+ follows:
+
+ OLD TEXT
+
+ The process for demultiplexing a packet is as follows. The receiver
+ looks at the first byte of the packet. If the value of this byte is
+ 0 or 1, then the packet is STUN. If the value is in between 128 and
+ 191 (inclusive), then the packet is RTP (or RTCP, if both RTCP and
+ RTP are being multiplexed over the same destination port). If the
+ value is between 20 and 63 (inclusive), the packet is DTLS. This
+ process is summarized in Figure 3.
+
+ +----------------+
+ | 127 < B < 192 -+--> forward to RTP
+ | |
+ packet --> | 19 < B < 64 -+--> forward to DTLS
+ | |
+ | B < 2 -+--> forward to STUN
+ +----------------+
+
+ Figure 3: The DTLS-SRTP receiver's packet demultiplexing algorithm.
+ Here the field B denotes the leading byte of the packet.
+
+ END OLD TEXT
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Petit-Huguenin & Salgueiro Standards Track [Page 8]
+
+RFC 7983 Multiplexing Scheme Updates for RFC 5764 September 2016
+
+
+ NEW TEXT
+
+ The process for demultiplexing a packet is as follows. The receiver
+ looks at the first byte of the packet. If the value of this byte is
+ in between 0 and 3 (inclusive), then the packet is STUN. If the
+ value is between 16 and 19 (inclusive), then the packet is ZRTP. If
+ the value is between 20 and 63 (inclusive), then the packet is DTLS.
+ If the value is between 64 and 79 (inclusive), then the packet is
+ TURN Channel. If the value is in between 128 and 191 (inclusive),
+ then the packet is RTP (or RTCP, if both RTCP and RTP are being
+ multiplexed over the same destination port). If the value does not
+ match any known range, then the packet MUST be dropped and an alert
+ MAY be logged. This process is summarized in Figure 3.
+
+ +----------------+
+ | [0..3] -+--> forward to STUN
+ | |
+ | [16..19] -+--> forward to ZRTP
+ | |
+ packet --> | [20..63] -+--> forward to DTLS
+ | |
+ | [64..79] -+--> forward to TURN Channel
+ | |
+ | [128..191] -+--> forward to RTP/RTCP
+ +----------------+
+
+ Figure 3: The DTLS-SRTP receiver's packet demultiplexing algorithm.
+
+ END NEW TEXT
+
+8. Security Considerations
+
+ This document updates existing IANA registries and adds a new range
+ for TURN channels in the demultiplexing algorithm.
+
+ These modifications do not introduce any specific security
+ considerations beyond those detailed in [RFC5764].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Petit-Huguenin & Salgueiro Standards Track [Page 9]
+
+RFC 7983 Multiplexing Scheme Updates for RFC 5764 September 2016
+
+
+9. IANA Considerations
+
+9.1. STUN Methods
+
+ This specification contains the registration information for reserved
+ STUN Methods codepoints, as explained in Section 3 and in accordance
+ with the procedures defined in Section 18.1 of [RFC5389].
+
+ Value: 0x100-0xFFF
+
+ Name: Reserved (For DTLS-SRTP multiplexing collision avoidance, see
+ RFC 7983. Cannot be made available for assignment without IETF
+ Review.)
+
+ Reference: RFC 5764, RFC 7983
+
+ This specification also reassigns the ranges in the STUN Methods
+ Registry as follows:
+
+ Range: 0x000-0x07F
+
+ Registration Procedures: IETF Review
+
+ Range: 0x080-0x0FF
+
+ Registration Procedures: Designated Expert
+
+9.2. TLS ContentType
+
+ This specification contains the registration information for reserved
+ TLS ContentType codepoints, as explained in Section 5 and in
+ accordance with the procedures defined in Section 12 of [RFC5246].
+
+ Value: 0-19
+
+ Description: Unassigned (Requires coordination; see RFC 7983)
+
+ DTLS-OK: N/A
+
+ Reference: RFC 5764, RFC 7983
+
+ Value: 64-255
+
+ Description: Unassigned (Requires coordination; see RFC 7983)
+
+ DTLS-OK: N/A
+
+ Reference: RFC 5764, RFC 7983
+
+
+
+Petit-Huguenin & Salgueiro Standards Track [Page 10]
+
+RFC 7983 Multiplexing Scheme Updates for RFC 5764 September 2016
+
+
+9.3. Traversal Using Relays around NAT (TURN) Channel Numbers
+
+ This specification contains the registration information for reserved
+ codepoints in the "Traversal Using Relays around NAT (TURN) Channel
+ Numbers" registry, as explained in Section 6 and in accordance with
+ the procedures defined in Section 18 of [RFC5766].
+
+ Value: 0x5000-0xFFFF
+
+ Name: Reserved (For DTLS-SRTP multiplexing collision avoidance, see
+ RFC 7983.)
+
+ Reference: RFC 7983
+
+10. References
+
+10.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119,
+ DOI 10.17487/RFC2119, March 1997,
+ <http://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
+ Jacobson, "RTP: A Transport Protocol for Real-Time
+ Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
+ July 2003, <http://www.rfc-editor.org/info/rfc3550>.
+
+ [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
+ Norrman, "The Secure Real-time Transport Protocol (SRTP)",
+ RFC 3711, DOI 10.17487/RFC3711, March 2004,
+ <http://www.rfc-editor.org/info/rfc3711>.
+
+ [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
+ (ICE): A Protocol for Network Address Translator (NAT)
+ Traversal for Offer/Answer Protocols", RFC 5245,
+ DOI 10.17487/RFC5245, April 2010,
+ <http://www.rfc-editor.org/info/rfc5245>.
+
+ [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
+ (TLS) Protocol Version 1.2", RFC 5246,
+ DOI 10.17487/RFC5246, August 2008,
+ <http://www.rfc-editor.org/info/rfc5246>.
+
+ [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
+ "Session Traversal Utilities for NAT (STUN)", RFC 5389,
+ DOI 10.17487/RFC5389, October 2008,
+ <http://www.rfc-editor.org/info/rfc5389>.
+
+
+
+Petit-Huguenin & Salgueiro Standards Track [Page 11]
+
+RFC 7983 Multiplexing Scheme Updates for RFC 5764 September 2016
+
+
+ [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
+ Security (DTLS) Extension to Establish Keys for the Secure
+ Real-time Transport Protocol (SRTP)", RFC 5764,
+ DOI 10.17487/RFC5764, May 2010,
+ <http://www.rfc-editor.org/info/rfc5764>.
+
+ [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
+ Relays around NAT (TURN): Relay Extensions to Session
+ Traversal Utilities for NAT (STUN)", RFC 5766,
+ DOI 10.17487/RFC5766, April 2010,
+ <http://www.rfc-editor.org/info/rfc5766>.
+
+ [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
+ Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
+ January 2012, <http://www.rfc-editor.org/info/rfc6347>.
+
+10.2. Informative References
+
+ [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
+ Security", RFC 4347, DOI 10.17487/RFC4347, April 2006,
+ <http://www.rfc-editor.org/info/rfc4347>.
+
+ [RFC6189] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP:
+ Media Path Key Agreement for Unicast Secure RTP",
+ RFC 6189, DOI 10.17487/RFC6189, April 2011,
+ <http://www.rfc-editor.org/info/rfc6189>.
+
+ [RFC7345] Holmberg, C., Sedlacek, I., and G. Salgueiro, "UDP
+ Transport Layer (UDPTL) over Datagram Transport Layer
+ Security (DTLS)", RFC 7345, DOI 10.17487/RFC7345, August
+ 2014, <http://www.rfc-editor.org/info/rfc7345>.
+
+ [SDP-BUNDLE]
+ Holmberg, C., Alvestrand, H., and C. Jennings,
+ "Negotiating Media Multiplexing Using the Session
+ Description Protocol (SDP)", Work in Progress,
+ draft-ietf-mmusic-sdp-bundle-negotiation-32, August 2016.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Petit-Huguenin & Salgueiro Standards Track [Page 12]
+
+RFC 7983 Multiplexing Scheme Updates for RFC 5764 September 2016
+
+
+Acknowledgements
+
+ The implicit STUN Method codepoint allocations problem was first
+ reported by Martin Thomson in the RTCWEB mailing list and discussed
+ further with Magnus Westerlund.
+
+ Thanks to Simon Perreault, Colton Shields, Cullen Jennings, Colin
+ Perkins, Magnus Westerlund, Paul Jones, Jonathan Lennox, Varun Singh,
+ Justin Uberti, Joseph Salowey, Martin Thomson, Ben Campbell, Stephen
+ Farrell, Alan Johnston, Mehmet Ersue, Matt Miller, Spencer Dawkins,
+ Joel Halpern, and Paul Kyzivat for the comments, suggestions, and
+ questions that helped improve this document.
+
+Authors' Addresses
+
+ Marc Petit-Huguenin
+ Impedance Mismatch
+
+ Email: marc@petit-huguenin.org
+
+
+ Gonzalo Salgueiro
+ Cisco Systems
+ 7200-12 Kit Creek Road
+ Research Triangle Park, NC 27709
+ United States of America
+
+ Email: gsalguei@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Petit-Huguenin & Salgueiro Standards Track [Page 13]
+