draft-ietf-tram-stunbis-12.txt   draft-ietf-tram-stunbis-13.txt 
TRAM M. Petit-Huguenin TRAM M. Petit-Huguenin
Internet-Draft Impedance Mismatch Internet-Draft Impedance Mismatch
Obsoletes: 5389 (if approved) G. Salgueiro Obsoletes: 5389 (if approved) G. Salgueiro
Intended status: Standards Track J. Rosenberg Intended status: Standards Track J. Rosenberg
Expires: October 2, 2017 Cisco Expires: June 21, 2018 Cisco
D. Wing D. Wing
R. Mahy R. Mahy
Plantronics Unaffiliated
P. Matthews P. Matthews
Nokia Nokia
March 31, 2017 December 18, 2017
Session Traversal Utilities for NAT (STUN) Session Traversal Utilities for NAT (STUN)
draft-ietf-tram-stunbis-12 draft-ietf-tram-stunbis-13
Abstract Abstract
Session Traversal Utilities for NAT (STUN) is a protocol that serves Session Traversal Utilities for NAT (STUN) is a protocol that serves
as a tool for other protocols in dealing with Network Address as a tool for other protocols in dealing with Network Address
Translator (NAT) traversal. It can be used by an endpoint to Translator (NAT) traversal. It can be used by an endpoint to
determine the IP address and port allocated to it by a NAT. It can determine the IP address and port allocated to it by a NAT. It can
also be used to check connectivity between two endpoints, and as a also be used to check connectivity between two endpoints, and as a
keep-alive protocol to maintain NAT bindings. STUN works with many keep-alive protocol to maintain NAT bindings. STUN works with many
existing NATs, and does not require any special behavior from them. existing NATs, and does not require any special behavior from them.
skipping to change at page 1, line 49 skipping to change at page 1, line 49
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 October 2, 2017. This Internet-Draft will expire on June 21, 2018.
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 (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 3, line 29 skipping to change at page 3, line 29
14.6. MESSAGE-INTEGRITY-SHA256 . . . . . . . . . . . . . . . . 40 14.6. MESSAGE-INTEGRITY-SHA256 . . . . . . . . . . . . . . . . 40
14.7. FINGERPRINT . . . . . . . . . . . . . . . . . . . . . . 41 14.7. FINGERPRINT . . . . . . . . . . . . . . . . . . . . . . 41
14.8. ERROR-CODE . . . . . . . . . . . . . . . . . . . . . . . 41 14.8. ERROR-CODE . . . . . . . . . . . . . . . . . . . . . . . 41
14.9. REALM . . . . . . . . . . . . . . . . . . . . . . . . . 43 14.9. REALM . . . . . . . . . . . . . . . . . . . . . . . . . 43
14.10. NONCE . . . . . . . . . . . . . . . . . . . . . . . . . 43 14.10. NONCE . . . . . . . . . . . . . . . . . . . . . . . . . 43
14.11. PASSWORD-ALGORITHMS . . . . . . . . . . . . . . . . . . 43 14.11. PASSWORD-ALGORITHMS . . . . . . . . . . . . . . . . . . 43
14.12. PASSWORD-ALGORITHM . . . . . . . . . . . . . . . . . . . 44 14.12. PASSWORD-ALGORITHM . . . . . . . . . . . . . . . . . . . 44
14.13. UNKNOWN-ATTRIBUTES . . . . . . . . . . . . . . . . . . . 45 14.13. UNKNOWN-ATTRIBUTES . . . . . . . . . . . . . . . . . . . 45
14.14. SOFTWARE . . . . . . . . . . . . . . . . . . . . . . . . 45 14.14. SOFTWARE . . . . . . . . . . . . . . . . . . . . . . . . 45
14.15. ALTERNATE-SERVER . . . . . . . . . . . . . . . . . . . . 45 14.15. ALTERNATE-SERVER . . . . . . . . . . . . . . . . . . . . 45
14.16. ALTERNATE-DOMAIN . . . . . . . . . . . . . . . . . . . . 45 14.16. ALTERNATE-DOMAIN . . . . . . . . . . . . . . . . . . . . 46
15. Security Considerations . . . . . . . . . . . . . . . . . . . 46 15. Security Considerations . . . . . . . . . . . . . . . . . . . 46
15.1. Attacks against the Protocol . . . . . . . . . . . . . . 46 15.1. Attacks against the Protocol . . . . . . . . . . . . . . 46
15.1.1. Outside Attacks . . . . . . . . . . . . . . . . . . 46 15.1.1. Outside Attacks . . . . . . . . . . . . . . . . . . 46
15.1.2. Inside Attacks . . . . . . . . . . . . . . . . . . . 47 15.1.2. Inside Attacks . . . . . . . . . . . . . . . . . . . 47
15.2. Attacks Affecting the Usage . . . . . . . . . . . . . . 47 15.2. Attacks Affecting the Usage . . . . . . . . . . . . . . 47
15.2.1. Attack I: Distributed DoS (DDoS) against a Target . 48 15.2.1. Attack I: Distributed DoS (DDoS) against a Target . 48
15.2.2. Attack II: Silencing a Client . . . . . . . . . . . 48 15.2.2. Attack II: Silencing a Client . . . . . . . . . . . 48
15.2.3. Attack III: Assuming the Identity of a Client . . . 48 15.2.3. Attack III: Assuming the Identity of a Client . . . 49
15.2.4. Attack IV: Eavesdropping . . . . . . . . . . . . . . 48 15.2.4. Attack IV: Eavesdropping . . . . . . . . . . . . . . 49
15.3. Hash Agility Plan . . . . . . . . . . . . . . . . . . . 49 15.3. Hash Agility Plan . . . . . . . . . . . . . . . . . . . 49
16. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 49 16. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 50
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50
17.1. STUN Security Features Registry . . . . . . . . . . . . 50 17.1. STUN Security Features Registry . . . . . . . . . . . . 50
17.2. STUN Methods Registry . . . . . . . . . . . . . . . . . 50 17.2. STUN Methods Registry . . . . . . . . . . . . . . . . . 50
17.3. STUN Attribute Registry . . . . . . . . . . . . . . . . 50 17.3. STUN Attribute Registry . . . . . . . . . . . . . . . . 50
17.3.1. Updated Attributes . . . . . . . . . . . . . . . . . 50 17.3.1. Updated Attributes . . . . . . . . . . . . . . . . . 51
17.3.2. New Attributes . . . . . . . . . . . . . . . . . . . 51 17.3.2. New Attributes . . . . . . . . . . . . . . . . . . . 51
17.4. STUN Error Code Registry . . . . . . . . . . . . . . . . 51 17.4. STUN Error Code Registry . . . . . . . . . . . . . . . . 51
17.5. Password Algorithm Registry . . . . . . . . . . . . . . 51 17.5. Password Algorithm Registry . . . . . . . . . . . . . . 52
17.5.1. Password Algorithms . . . . . . . . . . . . . . . . 52 17.5.1. Password Algorithms . . . . . . . . . . . . . . . . 52
17.5.1.1. MD5 . . . . . . . . . . . . . . . . . . . . . . 52 17.5.1.1. MD5 . . . . . . . . . . . . . . . . . . . . . . 52
17.5.1.2. SHA256 . . . . . . . . . . . . . . . . . . . . . 52 17.5.1.2. SHA256 . . . . . . . . . . . . . . . . . . . . . 52
17.6. STUN UDP and TCP Port Numbers . . . . . . . . . . . . . 52 17.6. STUN UDP and TCP Port Numbers . . . . . . . . . . . . . 52
18. Changes since RFC 5389 . . . . . . . . . . . . . . . . . . . 52 18. Changes since RFC 5389 . . . . . . . . . . . . . . . . . . . 53
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 53 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 53
19.1. Normative References . . . . . . . . . . . . . . . . . . 53 19.1. Normative References . . . . . . . . . . . . . . . . . . 53
19.2. Informative References . . . . . . . . . . . . . . . . . 55 19.2. Informative References . . . . . . . . . . . . . . . . . 55
Appendix A. C Snippet to Determine STUN Message Types . . . . . 57 Appendix A. C Snippet to Determine STUN Message Types . . . . . 57
Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 58 Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 58
B.1. Sample Request with Long-Term Authentication with B.1. Sample Request with Long-Term Authentication with
MESSAGE-INTEGRITY-SHA256 and USERHASH . . . . . . . . . . 58 MESSAGE-INTEGRITY-SHA256 and USERHASH . . . . . . . . . . 58
Appendix C. Release notes . . . . . . . . . . . . . . . . . . . 60 Appendix C. Release notes . . . . . . . . . . . . . . . . . . . 60
C.1. Modifications between draft-ietf-tram-stunbis-12 and C.1. Modifications between draft-ietf-tram-stunbis-13 and
draft-ietf-tram-stunbis-12 . . . . . . . . . . . . . . . 60
C.2. Modifications between draft-ietf-tram-stunbis-12 and
draft-ietf-tram-stunbis-11 . . . . . . . . . . . . . . . 60 draft-ietf-tram-stunbis-11 . . . . . . . . . . . . . . . 60
C.2. Modifications between draft-ietf-tram-stunbis-11 and C.3. Modifications between draft-ietf-tram-stunbis-11 and
draft-ietf-tram-stunbis-10 . . . . . . . . . . . . . . . 60 draft-ietf-tram-stunbis-10 . . . . . . . . . . . . . . . 60
C.3. Modifications between draft-ietf-tram-stunbis-10 and C.4. Modifications between draft-ietf-tram-stunbis-10 and
draft-ietf-tram-stunbis-09 . . . . . . . . . . . . . . . 60 draft-ietf-tram-stunbis-09 . . . . . . . . . . . . . . . 61
C.4. Modifications between draft-ietf-tram-stunbis-09 and
draft-ietf-tram-stunbis-08 . . . . . . . . . . . . . . . 61
C.5. Modifications between draft-ietf-tram-stunbis-09 and C.5. Modifications between draft-ietf-tram-stunbis-09 and
draft-ietf-tram-stunbis-08 . . . . . . . . . . . . . . . 61 draft-ietf-tram-stunbis-08 . . . . . . . . . . . . . . . 61
C.6. Modifications between draft-ietf-tram-stunbis-08 and C.6. Modifications between draft-ietf-tram-stunbis-09 and
draft-ietf-tram-stunbis-08 . . . . . . . . . . . . . . . 62
C.7. Modifications between draft-ietf-tram-stunbis-08 and
draft-ietf-tram-stunbis-07 . . . . . . . . . . . . . . . 62 draft-ietf-tram-stunbis-07 . . . . . . . . . . . . . . . 62
C.7. Modifications between draft-ietf-tram-stunbis-07 and C.8. Modifications between draft-ietf-tram-stunbis-07 and
draft-ietf-tram-stunbis-06 . . . . . . . . . . . . . . . 62 draft-ietf-tram-stunbis-06 . . . . . . . . . . . . . . . 63
C.8. Modifications between draft-ietf-tram-stunbis-06 and C.9. Modifications between draft-ietf-tram-stunbis-06 and
draft-ietf-tram-stunbis-05 . . . . . . . . . . . . . . . 62 draft-ietf-tram-stunbis-05 . . . . . . . . . . . . . . . 63
C.9. Modifications between draft-ietf-tram-stunbis-05 and C.10. Modifications between draft-ietf-tram-stunbis-05 and
draft-ietf-tram-stunbis-04 . . . . . . . . . . . . . . . 63 draft-ietf-tram-stunbis-04 . . . . . . . . . . . . . . . 63
C.10. Modifications between draft-ietf-tram-stunbis-04 and C.11. Modifications between draft-ietf-tram-stunbis-04 and
draft-ietf-tram-stunbis-03 . . . . . . . . . . . . . . . 63 draft-ietf-tram-stunbis-03 . . . . . . . . . . . . . . . 63
C.11. Modifications between draft-ietf-tram-stunbis-03 and C.12. Modifications between draft-ietf-tram-stunbis-03 and
draft-ietf-tram-stunbis-02 . . . . . . . . . . . . . . . 63 draft-ietf-tram-stunbis-02 . . . . . . . . . . . . . . . 64
C.12. Modifications between draft-ietf-tram-stunbis-02 and C.13. Modifications between draft-ietf-tram-stunbis-02 and
draft-ietf-tram-stunbis-01 . . . . . . . . . . . . . . . 63 draft-ietf-tram-stunbis-01 . . . . . . . . . . . . . . . 64
C.13. Modifications between draft-ietf-tram-stunbis-01 and C.14. Modifications between draft-ietf-tram-stunbis-01 and
draft-ietf-tram-stunbis-00 . . . . . . . . . . . . . . . 64 draft-ietf-tram-stunbis-00 . . . . . . . . . . . . . . . 64
C.14. Modifications between draft-salgueiro-tram-stunbis-02 and
draft-ietf-tram-stunbis-00 . . . . . . . . . . . . . . . 65
C.15. Modifications between draft-salgueiro-tram-stunbis-02 and C.15. Modifications between draft-salgueiro-tram-stunbis-02 and
draft-ietf-tram-stunbis-00 . . . . . . . . . . . . . . . 65
C.16. Modifications between draft-salgueiro-tram-stunbis-02 and
draft-salgueiro-tram-stunbis-01 . . . . . . . . . . . . . 65 draft-salgueiro-tram-stunbis-01 . . . . . . . . . . . . . 65
C.16. Modifications between draft-salgueiro-tram-stunbis-01 and C.17. Modifications between draft-salgueiro-tram-stunbis-01 and
draft-salgueiro-tram-stunbis-00 . . . . . . . . . . . . . 65 draft-salgueiro-tram-stunbis-00 . . . . . . . . . . . . . 66
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 66 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 66
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 66 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 66
1. Introduction 1. Introduction
The protocol defined in this specification, Session Traversal The protocol defined in this specification, Session Traversal
Utilities for NAT, provides a tool for dealing with NATs. It Utilities for NAT, provides a tool for dealing with NATs. It
provides a means for an endpoint to determine the IP address and port provides a means for an endpoint to determine the IP address and port
allocated by a NAT that corresponds to its private IP address and allocated by a NAT that corresponds to its private IP address and
skipping to change at page 8, line 14 skipping to change at page 8, line 14
for demultiplexing, and two authentication and message-integrity for demultiplexing, and two authentication and message-integrity
exchanges. The authentication mechanisms revolve around the use of a exchanges. The authentication mechanisms revolve around the use of a
username, password, and message-integrity value. Two authentication username, password, and message-integrity value. Two authentication
mechanisms, the long-term credential mechanism and the short-term mechanisms, the long-term credential mechanism and the short-term
credential mechanism, are defined in this specification. Each usage credential mechanism, are defined in this specification. Each usage
specifies the mechanisms allowed with that usage. specifies the mechanisms allowed with that usage.
In the long-term credential mechanism, the client and server share a In the long-term credential mechanism, the client and server share a
pre-provisioned username and password and perform a digest challenge/ pre-provisioned username and password and perform a digest challenge/
response exchange inspired by (but differing in details) to the one response exchange inspired by (but differing in details) to the one
defined for HTTP [RFC2617]. In the short-term credential mechanism, defined for HTTP [RFC7616]. In the short-term credential mechanism,
the client and the server exchange a username and password through the client and the server exchange a username and password through
some out-of-band method prior to the STUN exchange. For example, in some out-of-band method prior to the STUN exchange. For example, in
the ICE usage [I-D.ietf-ice-rfc5245bis] the two endpoints use out-of- the ICE usage [I-D.ietf-ice-rfc5245bis] the two endpoints use out-of-
band signaling to exchange a username and password. These are used band signaling to exchange a username and password. These are used
to integrity protect and authenticate the request and response. to integrity protect and authenticate the request and response.
There is no challenge or nonce used. There is no challenge or nonce used.
3. Terminology 3. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", In this document, the key words "MUST", "MUST NOT", "REQUIRED",
skipping to change at page 13, line 13 skipping to change at page 13, line 13
discuss whether SOFTWARE is useful in new indications. discuss whether SOFTWARE is useful in new indications.
For the Binding method with no authentication, no attributes are For the Binding method with no authentication, no attributes are
required unless the usage specifies otherwise. required unless the usage specifies otherwise.
All STUN messages sent over UDP or DTLS-over-UDP [RFC6347] SHOULD be All STUN messages sent over UDP or DTLS-over-UDP [RFC6347] SHOULD be
less than the path MTU, if known. less than the path MTU, if known.
If the path MTU is unknown for UDP, messages SHOULD be the smaller of If the path MTU is unknown for UDP, messages SHOULD be the smaller of
576 bytes and the first-hop MTU for IPv4 [RFC1122] and 1280 bytes for 576 bytes and the first-hop MTU for IPv4 [RFC1122] and 1280 bytes for
IPv6 [RFC2460]. This value corresponds to the overall size of the IP IPv6 [RFC8200]. This value corresponds to the overall size of the IP
packet. Consequently, for IPv4, the actual STUN message would need packet. Consequently, for IPv4, the actual STUN message would need
to be less than 548 bytes (576 minus 20-byte IP header, minus 8-byte to be less than 548 bytes (576 minus 20-byte IP header, minus 8-byte
UDP header, assuming no IP options are used). UDP header, assuming no IP options are used).
If the path MTU is unknown for DTLS-over-UDP, the rules described in If the path MTU is unknown for DTLS-over-UDP, the rules described in
the previous paragraph need to be adjusted to take into account the the previous paragraph need to be adjusted to take into account the
size of the (13-byte) DTLS Record header, the MAC size, and the size of the (13-byte) DTLS Record header, the MAC size, and the
padding size. padding size.
STUN provides no ability to handle the case where the request is STUN provides no ability to handle the case where the request is
skipping to change at page 16, line 42 skipping to change at page 16, line 42
based on (single) DES and RC4, MUST NOT be used. Implementations based on (single) DES and RC4, MUST NOT be used. Implementations
MUST disable TLS-level compression. MUST disable TLS-level compression.
When it receives the TLS Certificate message, the client SHOULD When it receives the TLS Certificate message, the client SHOULD
verify the certificate and inspect the site identified by the verify the certificate and inspect the site identified by the
certificate. If the certificate is invalid or revoked, or if it does certificate. If the certificate is invalid or revoked, or if it does
not identify the appropriate party, the client MUST NOT send the STUN not identify the appropriate party, the client MUST NOT send the STUN
message or otherwise proceed with the STUN transaction. The client message or otherwise proceed with the STUN transaction. The client
MUST verify the identity of the server. To do that, it follows the MUST verify the identity of the server. To do that, it follows the
identification procedures defined in [RFC6125]. Alternatively, a identification procedures defined in [RFC6125]. Alternatively, a
client MAY be configured with a set of domains or IP addresses that client MAY be configured with a set of IP addresses that are trusted;
are trusted; if a certificate is received that identifies one of if a certificate is received that identifies one of those IP
those domains or IP addresses, the client considers the identity of addresses, the client considers the identity of the server to be
the server to be verified. verified.
When STUN is run multiplexed with other protocols over a TLS-over-TCP When STUN is run multiplexed with other protocols over a TLS-over-TCP
connection or a DTLS-over-UDP association, the mandatory ciphersuites connection or a DTLS-over-UDP association, the mandatory ciphersuites
and TLS handling procedures operate as defined by those protocols. and TLS handling procedures operate as defined by those protocols.
6.3. Receiving a STUN Message 6.3. Receiving a STUN Message
This section specifies the processing of a STUN message. The This section specifies the processing of a STUN message. The
processing specified here is for STUN messages as defined in this processing specified here is for STUN messages as defined in this
specification; additional rules for backwards compatibility are specification; additional rules for backwards compatibility are
skipping to change at page 22, line 7 skipping to change at page 22, line 7
that accepts Binding request/response transactions, the STUN URI that accepts Binding request/response transactions, the STUN URI
scheme is "stun". When it wishes to locate a STUN server that scheme is "stun". When it wishes to locate a STUN server that
accepts Binding request/response transactions over a TLS, or DTLS accepts Binding request/response transactions over a TLS, or DTLS
session, the URI scheme is "stuns". session, the URI scheme is "stuns".
The syntax of the "stun" and "stuns" URIs are defined in Section 3.1 The syntax of the "stun" and "stuns" URIs are defined in Section 3.1
of [RFC7064]. STUN usages MAY define additional URI schemes. of [RFC7064]. STUN usages MAY define additional URI schemes.
8.1. STUN URI Scheme Semantics 8.1. STUN URI Scheme Semantics
If the <host> part contains an IP address, then this IP address is If the <host> part of a "stun" URI contains an IP address, then this
used directly to contact the server. A "stuns" URI containing an IP IP address is used directly to contact the server. A "stuns" URI
address MUST be rejected, unless the domain name is provided by the containing an IP address MUST be rejected, unless the domain name is
same mechanism that provided the STUN URI, and that domain name can provided by the same mechanism that provided the STUN URI, and that
be passed to the verification code. domain name can be passed to the verification code.
If the URI does not contain an IP address, the domain name contained If the URI does not contain an IP address, the domain name contained
in the <host> part is resolved to a transport address using the SRV in the <host> part is resolved to a transport address using the SRV
procedures specified in [RFC2782]. The DNS SRV service name is the procedures specified in [RFC2782]. The DNS SRV service name is the
content of the <scheme> part. The protocol in the SRV lookup is the content of the <scheme> part. The protocol in the SRV lookup is the
transport protocol the client will run STUN over: "udp" for UDP and transport protocol the client will run STUN over: "udp" for UDP and
"tcp" for TCP. "tcp" for TCP.
The procedures of RFC 2782 are followed to determine the server to The procedures of RFC 2782 are followed to determine the server to
contact. RFC 2782 spells out the details of how a set of SRV records contact. RFC 2782 spells out the details of how a set of SRV records
skipping to change at page 25, line 44 skipping to change at page 25, line 44
Section 14.6, respectively, using the same password it utilized for Section 14.6, respectively, using the same password it utilized for
the request. If the resulting value matches the contents of the the request. If the resulting value matches the contents of the
MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 attribute, MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 attribute,
respectively, the response is considered authenticated. If the value respectively, the response is considered authenticated. If the value
does not match, or if both MESSAGE-INTEGRITY and MESSAGE-INTEGRITY- does not match, or if both MESSAGE-INTEGRITY and MESSAGE-INTEGRITY-
SHA256 were absent, the processing depends on the request been sent SHA256 were absent, the processing depends on the request been sent
over a reliable or an unreliable transport. over a reliable or an unreliable transport.
If the request was sent over an unreliable transport, the response If the request was sent over an unreliable transport, the response
MUST be discarded, as if it was never received. This means that MUST be discarded, as if it was never received. This means that
retransmits, if applicable, will continue. If all the reponses retransmits, if applicable, will continue. If all the responses
received are discarded then instead of signalling a timeout after received are discarded then instead of signalling a timeout after
ending the transaction the layer MUST signal that an attack took ending the transaction the layer MUST signal that an attack took
place. place.
If the request was sent over a reliable transport, the response MUST If the request was sent over a reliable transport, the response MUST
be discarded and the layer MUST immediately end the transaction and be discarded and the layer MUST immediately end the transaction and
signal that an attack took place. signal that an attack took place.
If the client only sent only one of MESSAGE-INTEGRITY or MESSAGE- If the client only sent only one of MESSAGE-INTEGRITY or MESSAGE-
INTEGRITY-SHA256 attributes in the request (because of the external INTEGRITY-SHA256 attributes in the request (because of the external
skipping to change at page 31, line 12 skipping to change at page 31, line 12
MESSAGE-INTEGRITY-SHA256 attribute, using the previous NONCE to MESSAGE-INTEGRITY-SHA256 attribute, using the previous NONCE to
calculate it. calculate it.
o If the NONCE is no longer valid, the server MUST generate an error o If the NONCE is no longer valid, the server MUST generate an error
response with an error code of 438 (Stale Nonce). This response response with an error code of 438 (Stale Nonce). This response
MUST include NONCE, REALM, and PASSWORD-ALGORITHMS attributes and MUST include NONCE, REALM, and PASSWORD-ALGORITHMS attributes and
SHOULD NOT include the USERNAME, USERHASH attribute, The response SHOULD NOT include the USERNAME, USERHASH attribute, The response
MAY include a MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 MAY include a MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256
attribute, using the previous NONCE to calculate it. Servers can attribute, using the previous NONCE to calculate it. Servers can
invalidate nonces in order to provide additional security. See invalidate nonces in order to provide additional security. See
Section 4.3 of [RFC2617] for guidelines. Section 4.3 of [RFC7616] for guidelines.
o If the username in the USERNAME or USERHASH attribute is not o If the username in the USERNAME or USERHASH attribute is not
valid, the server MUST generate an error response with an error valid, the server MUST generate an error response with an error
code of 401 (Unauthenticated). This response MUST include a REALM code of 401 (Unauthenticated). This response MUST include a REALM
value. It is RECOMMENDED that the REALM value be the domain name value. It is RECOMMENDED that the REALM value be the domain name
of the provider of the STUN server. The response MUST include a of the provider of the STUN server. The response MUST include a
NONCE, selected by the server. The response MUST include a NONCE, selected by the server. The response MUST include a
PASSWORD-ALGORITHMS attribute. The response SHOULD NOT contain a PASSWORD-ALGORITHMS attribute. The response SHOULD NOT contain a
USERNAME, USERHASH attribute. The response MAY include a MESSAGE- USERNAME, USERHASH attribute. The response MAY include a MESSAGE-
INTEGRITY or MESSAGE-INTEGRITY-SHA256 attribute, using the INTEGRITY or MESSAGE-INTEGRITY-SHA256 attribute, using the
skipping to change at page 34, line 22 skipping to change at page 34, line 22
same domain that was used for the original request MUST be used to same domain that was used for the original request MUST be used to
validate the certificate. If the client has been redirected to a validate the certificate. If the client has been redirected to a
server on which it has already tried this request within the last server on which it has already tried this request within the last
five minutes, it MUST ignore the redirection and consider the five minutes, it MUST ignore the redirection and consider the
transaction to have failed. This prevents infinite ping-ponging transaction to have failed. This prevents infinite ping-ponging
between servers in case of redirection loops. between servers in case of redirection loops.
11. Backwards Compatibility with RFC 3489 11. Backwards Compatibility with RFC 3489
In addition to the backward compatibility already described in In addition to the backward compatibility already described in
Section 12 of [RFC5389], DTLS MUST NOT be used with STUN [RFC3489] Section 12 of [RFC5389], DTLS MUST NOT be used with [RFC3489] (also
(also referred to as "classic STUN"). Any STUN request or indication referred to as "classic STUN"). Any STUN request or indication
without the magic cookie (see Section 6 of [RFC5389]) over DTLS MUST without the magic cookie (see Section 6 of [RFC5389]) over DTLS MUST
always result in an error. always result in an error.
12. Basic Server Behavior 12. Basic Server Behavior
This section defines the behavior of a basic, stand-alone STUN This section defines the behavior of a basic, stand-alone STUN
server. A basic STUN server provides clients with server reflexive server.
transport addresses by receiving and replying to STUN Binding
requests. Historically, "classic STUN [RFC3489]" only defined the behavior of a
server that was providing clients with server reflexive transport
addresses by receiving and replying to STUN Binding requests.
[RFC5389] redefined the protocol as an extensible framework and the
server functionality became the sole STUN Usage defined in that
document. This STUN Usage is also known as Basic STUN Server.
The STUN server MUST support the Binding method. It SHOULD NOT The STUN server MUST support the Binding method. It SHOULD NOT
utilize the short-term or long-term credential mechanism. This is utilize the short-term or long-term credential mechanism. This is
because the work involved in authenticating the request is more than because the work involved in authenticating the request is more than
the work in simply processing it. It SHOULD NOT utilize the the work in simply processing it. It SHOULD NOT utilize the
ALTERNATE-SERVER mechanism for the same reason. It MUST support UDP ALTERNATE-SERVER mechanism for the same reason. It MUST support UDP
and TCP. It MAY support STUN over TCP/TLS or STUN over UDP/DTLS; and TCP. It MAY support STUN over TCP/TLS or STUN over UDP/DTLS;
however, DTLS and TLS provide minimal security benefits in this basic however, DTLS and TLS provide minimal security benefits in this basic
mode of operation. It MAY utilize the FINGERPRINT mechanism but MUST mode of operation. It MAY utilize the FINGERPRINT mechanism but MUST
NOT require it. Since the stand-alone server only runs STUN, NOT require it. Since the stand-alone server only runs STUN,
skipping to change at page 41, line 15 skipping to change at page 41, line 22
necessary when attributes, such as FINGERPRINT, appear after MESSAGE- necessary when attributes, such as FINGERPRINT, appear after MESSAGE-
INTEGRITY-SHA256. INTEGRITY-SHA256.
14.7. FINGERPRINT 14.7. FINGERPRINT
The FINGERPRINT attribute MAY be present in all STUN messages. The The FINGERPRINT attribute MAY be present in all STUN messages. The
value of the attribute is computed as the CRC-32 of the STUN message value of the attribute is computed as the CRC-32 of the STUN message
up to (but excluding) the FINGERPRINT attribute itself, XOR'ed with up to (but excluding) the FINGERPRINT attribute itself, XOR'ed with
the 32-bit value 0x5354554e (the XOR helps in cases where an the 32-bit value 0x5354554e (the XOR helps in cases where an
application packet is also using CRC-32 in it). The 32-bit CRC is application packet is also using CRC-32 in it). The 32-bit CRC is
the one defined in ITU V.42 [ITU.V42.2002], which has a generator the one defined in ITU V.42 [ITU.V42.1994], which has a generator
polynomial of x32+x26+x23+x22+x16+x12+x11+x10+x8+x7+x5+x4+x2+x+1. polynomial of x32+x26+x23+x22+x16+x12+x11+x10+x8+x7+x5+x4+x2+x+1.
See the sample code for the CRC-32 in Section 8 of [RFC1952]. See the sample code for the CRC-32 in Section 8 of [RFC1952].
When present, the FINGERPRINT attribute MUST be the last attribute in When present, the FINGERPRINT attribute MUST be the last attribute in
the message, and thus will appear after MESSAGE-INTEGRITY. the message, and thus will appear after MESSAGE-INTEGRITY.
The FINGERPRINT attribute can aid in distinguishing STUN packets from The FINGERPRINT attribute can aid in distinguishing STUN packets from
packets of other protocols. See Section 7. packets of other protocols. See Section 7.
As with MESSAGE-INTEGRITY, the CRC used in the FINGERPRINT attribute As with MESSAGE-INTEGRITY, the CRC used in the FINGERPRINT attribute
skipping to change at page 41, line 42 skipping to change at page 41, line 49
attribute is also present, then it must be present with the correct attribute is also present, then it must be present with the correct
message-integrity value before the CRC is computed, since the CRC is message-integrity value before the CRC is computed, since the CRC is
done over the value of the MESSAGE-INTEGRITY attribute as well. done over the value of the MESSAGE-INTEGRITY attribute as well.
14.8. ERROR-CODE 14.8. ERROR-CODE
The ERROR-CODE attribute is used in error response messages. It The ERROR-CODE attribute is used in error response messages. It
contains a numeric error code value in the range of 300 to 699 plus a contains a numeric error code value in the range of 300 to 699 plus a
textual reason phrase encoded in UTF-8 [RFC3629], and is consistent textual reason phrase encoded in UTF-8 [RFC3629], and is consistent
in its code assignments and semantics with SIP [RFC3261] and HTTP in its code assignments and semantics with SIP [RFC3261] and HTTP
[RFC2616]. The reason phrase is meant for user consumption, and can [RFC7231]. The reason phrase is meant for user consumption, and can
be anything appropriate for the error code. Recommended reason be anything appropriate for the error code. Recommended reason
phrases for the defined error codes are included in the IANA registry phrases for the defined error codes are included in the IANA registry
for error codes. The reason phrase MUST be a UTF-8 [RFC3629] encoded for error codes. The reason phrase MUST be a UTF-8 [RFC3629] encoded
sequence of less than 128 characters (which can be as long as 763 sequence of less than 128 characters (which can be as long as 763
bytes). bytes).
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved, should be 0 |Class| Number | | Reserved, should be 0 |Class| Number |
skipping to change at page 43, line 35 skipping to change at page 43, line 41
Presence of the REALM attribute in a request indicates that long-term Presence of the REALM attribute in a request indicates that long-term
credentials are being used for authentication. Presence in certain credentials are being used for authentication. Presence in certain
error responses indicates that the server wishes the client to use a error responses indicates that the server wishes the client to use a
long-term credential for authentication. long-term credential for authentication.
14.10. NONCE 14.10. NONCE
The NONCE attribute may be present in requests and responses. It The NONCE attribute may be present in requests and responses. It
contains a sequence of qdtext or quoted-pair, which are defined in contains a sequence of qdtext or quoted-pair, which are defined in
RFC 3261 [RFC3261]. Note that this means that the NONCE attribute RFC 3261 [RFC3261]. Note that this means that the NONCE attribute
will not contain actual quote characters. See [RFC2617], will not contain actual quote characters. See [RFC7616],
Section 4.3, for guidance on selection of nonce values in a server. Section 5.4, for guidance on selection of nonce values in a server.
It MUST be less than 128 characters (which can be as long as 763 It MUST be less than 128 characters (which can be as long as 763
bytes). bytes).
14.11. PASSWORD-ALGORITHMS 14.11. PASSWORD-ALGORITHMS
The PASSWORD-ALGORITHMS attribute may be present in requests and The PASSWORD-ALGORITHMS attribute may be present in requests and
responses. It contains the list of algorithms that the server can responses. It contains the list of algorithms that the server can
use to derive the long-term password. use to derive the long-term password.
The set of known algorithms is maintained by IANA. The initial set The set of known algorithms is maintained by IANA. The initial set
skipping to change at page 50, line 22 skipping to change at page 50, line 36
IANA is requested to create a new registry containing the STUN IANA is requested to create a new registry containing the STUN
Security Features that are protected by the bid down attack Security Features that are protected by the bid down attack
prevention mechanism described in section Section 9.2.1. prevention mechanism described in section Section 9.2.1.
The initial STUN Security Features are: The initial STUN Security Features are:
0x000001: Password algorithms 0x000001: Password algorithms
0x000002: Username anonymity 0x000002: Username anonymity
New Security Features are assigned by a Standard Action [RFC5226]. New Security Features are assigned by a Standard Action [RFC8126].
17.2. STUN Methods Registry 17.2. STUN Methods Registry
IANA is requested to update the reference from RFC 5389 to RFC-to-be IANA is requested to update the reference from RFC 5389 to RFC-to-be
for the following STUN methods: for the following STUN methods:
0x000: (Reserved) 0x000: (Reserved)
0x001: Binding 0x001: Binding
0x002: (Reserved; was SharedSecret) 0x002: (Reserved; was SharedSecret)
skipping to change at page 52, line 9 skipping to change at page 52, line 17
IANA is requested to create a new registry for Password Algorithm. IANA is requested to create a new registry for Password Algorithm.
A Password Algorithm is a hex number in the range 0x0000 - 0xFFFF. A Password Algorithm is a hex number in the range 0x0000 - 0xFFFF.
The initial Password Algorithms are: The initial Password Algorithms are:
0x0001: MD5 0x0001: MD5
0x0002: SHA256 0x0002: SHA256
Password Algorithms in the first half of the range (0x0000 - 0x7FFF) Password Algorithms in the first half of the range (0x0000 - 0x7FFF)
are assigned by IETF Review [RFC5226]. Password Algorithms in the are assigned by IETF Review [RFC8126]. Password Algorithms in the
second half of the range (0x8000 - 0xFFFF) are assigned by Designated second half of the range (0x8000 - 0xFFFF) are assigned by Designated
Expert [RFC5226]. Expert [RFC8126].
17.5.1. Password Algorithms 17.5.1. Password Algorithms
17.5.1.1. MD5 17.5.1.1. MD5
This password algorithm is taken from [RFC1321]. This password algorithm is taken from [RFC1321].
The key length is 20 bytes and the parameters value is empty. The key length is 20 bytes and the parameters value is empty.
Note: This algorithm MUST only be used for compatibility with legacy Note: This algorithm MUST only be used for compatibility with legacy
skipping to change at page 53, line 35 skipping to change at page 53, line 45
server mechanism. server mechanism.
o Added more C snippets. o Added more C snippets.
o Added test vector. o Added test vector.
19. References 19. References
19.1. Normative References 19.1. Normative References
[ITU.V42.2002] [ITU.V42.1994]
International Telecommunications Union, "Error-correcting International Telecommunications Union, "Error-correcting
Procedures for DCEs Using Asynchronous-to-Synchronous Procedures for DCEs Using Asynchronous-to-Synchronous
Conversion", ITU-T Recommendation V.42, 2002. Conversion", ITU-T Recommendation V.42, 1994.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981, DOI 10.17487/RFC0791, September 1981, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc791>. editor.org/info/rfc791>.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989, DOI 10.17487/RFC1122, October 1989, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc1122>. editor.org/info/rfc1122>.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
DOI 10.17487/RFC1321, April 1992, DOI 10.17487/RFC1321, April 1992, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc1321>. editor.org/info/rfc1321>.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997, DOI 10.17487/RFC2104, February 1997, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc2104>. editor.org/info/rfc2104>.
[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, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication",
RFC 2617, DOI 10.17487/RFC2617, June 1999,
<http://www.rfc-editor.org/info/rfc2617>.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782, specifying the location of services (DNS SRV)", RFC 2782,
DOI 10.17487/RFC2782, February 2000, DOI 10.17487/RFC2782, February 2000, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc2782>. editor.org/info/rfc2782>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <http://www.rfc-editor.org/info/rfc3629>. 2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<http://www.rfc-editor.org/info/rfc4648>. <https://www.rfc-editor.org/info/rfc4648>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc5246>. editor.org/info/rfc5246>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509 within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer (PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
2011, <http://www.rfc-editor.org/info/rfc6125>. 2011, <https://www.rfc-editor.org/info/rfc6125>.
[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent,
"Computing TCP's Retransmission Timer", RFC 6298, "Computing TCP's Retransmission Timer", RFC 6298,
DOI 10.17487/RFC6298, June 2011, DOI 10.17487/RFC6298, June 2011, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc6298>. editor.org/info/rfc6298>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <http://www.rfc-editor.org/info/rfc6347>. January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April
2012, <http://www.rfc-editor.org/info/rfc6555>. 2012, <https://www.rfc-editor.org/info/rfc6555>.
[RFC7064] Nandakumar, S., Salgueiro, G., Jones, P., and M. Petit- [RFC7064] Nandakumar, S., Salgueiro, G., Jones, P., and M. Petit-
Huguenin, "URI Scheme for the Session Traversal Utilities Huguenin, "URI Scheme for the Session Traversal Utilities
for NAT (STUN) Protocol", RFC 7064, DOI 10.17487/RFC7064, for NAT (STUN) Protocol", RFC 7064, DOI 10.17487/RFC7064,
November 2013, <http://www.rfc-editor.org/info/rfc7064>. November 2013, <https://www.rfc-editor.org/info/rfc7064>.
[RFC7350] Petit-Huguenin, M. and G. Salgueiro, "Datagram Transport [RFC7350] Petit-Huguenin, M. and G. Salgueiro, "Datagram Transport
Layer Security (DTLS) as Transport for Session Traversal Layer Security (DTLS) as Transport for Session Traversal
Utilities for NAT (STUN)", RFC 7350, DOI 10.17487/RFC7350, Utilities for NAT (STUN)", RFC 7350, DOI 10.17487/RFC7350,
August 2014, <http://www.rfc-editor.org/info/rfc7350>. August 2014, <https://www.rfc-editor.org/info/rfc7350>.
[RFC7613] Saint-Andre, P. and A. Melnikov, "Preparation, [RFC7613] Saint-Andre, P. and A. Melnikov, "Preparation,
Enforcement, and Comparison of Internationalized Strings Enforcement, and Comparison of Internationalized Strings
Representing Usernames and Passwords", RFC 7613, Representing Usernames and Passwords", RFC 7613,
DOI 10.17487/RFC7613, August 2015, DOI 10.17487/RFC7613, August 2015, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc7613>. editor.org/info/rfc7613>.
[RFC7616] Shekh-Yusef, R., Ahrens, D., and S. Bremer, "HTTP Digest
Access Authentication", RFC 7616, DOI 10.17487/RFC7616,
September 2015, <https://www.rfc-editor.org/info/rfc7616>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 8200, STD 86,
DOI 10.17487/RFC8200, July 2017, <https://www.rfc-
editor.org/info/rf8200>.
19.2. Informative References 19.2. Informative References
[I-D.ietf-ice-rfc5245bis] [I-D.ietf-ice-rfc5245bis]
Keranen, A. and J. Rosenberg, "Interactive Connectivity Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
Establishment (ICE): A Protocol for Network Address Connectivity Establishment (ICE): A Protocol for Network
Translator (NAT) Traversal", draft-ietf-ice-rfc5245bis-01 Address Translator (NAT) Traversal", draft-ietf-ice-
(work in progress), December 2015. rfc5245bis-15 (work in progress), November 2017.
[KARN87] Karn, P. and C. Partridge, "Improving Round-Trip Time [KARN87] Karn, P. and C. Partridge, "Improving Round-Trip Time
Estimates in Reliable Transport Protocols", SIGCOMM 1987, Estimates in Reliable Transport Protocols", August 1987.
August 1987.
[RFC1952] Deutsch, P., "GZIP file format specification version 4.3", [RFC1952] Deutsch, P., "GZIP file format specification version 4.3",
RFC 1952, DOI 10.17487/RFC1952, May 1996, RFC 1952, DOI 10.17487/RFC1952, May 1996,
<http://www.rfc-editor.org/info/rfc1952>. <https://www.rfc-editor.org/info/rfc1952>.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616,
DOI 10.17487/RFC2616, June 1999,
<http://www.rfc-editor.org/info/rfc2616>.
[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, DOI 10.17487/RFC3261, June 2002, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc3261>. editor.org/info/rfc3261>.
[RFC3424] Daigle, L., Ed. and IAB, "IAB Considerations for [RFC3424] Daigle, L., Ed. and IAB, "IAB Considerations for
UNilateral Self-Address Fixing (UNSAF) Across Network UNilateral Self-Address Fixing (UNSAF) Across Network
Address Translation", RFC 3424, DOI 10.17487/RFC3424, Address Translation", RFC 3424, DOI 10.17487/RFC3424,
November 2002, <http://www.rfc-editor.org/info/rfc3424>. November 2002, <https://www.rfc-editor.org/info/rfc3424>.
[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
"STUN - Simple Traversal of User Datagram Protocol (UDP) "STUN - Simple Traversal of User Datagram Protocol (UDP)
Through Network Address Translators (NATs)", RFC 3489, Through Network Address Translators (NATs)", RFC 3489,
DOI 10.17487/RFC3489, March 2003, DOI 10.17487/RFC3489, March 2003, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc3489>. editor.org/info/rfc3489>.
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic
Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107, Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107,
June 2005, <http://www.rfc-editor.org/info/rfc4107>. June 2005, <https://www.rfc-editor.org/info/rfc4107>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389, "Session Traversal Utilities for NAT (STUN)", RFC 5389,
DOI 10.17487/RFC5389, October 2008, DOI 10.17487/RFC5389, October 2008, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc5389>. editor.org/info/rfc5389>.
[RFC5626] Jennings, C., Ed., Mahy, R., Ed., and F. Audet, Ed., [RFC5626] Jennings, C., Ed., Mahy, R., Ed., and F. Audet, Ed.,
"Managing Client-Initiated Connections in the Session "Managing Client-Initiated Connections in the Session
Initiation Protocol (SIP)", RFC 5626, Initiation Protocol (SIP)", RFC 5626,
DOI 10.17487/RFC5626, October 2009, DOI 10.17487/RFC5626, October 2009, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc5626>. editor.org/info/rfc5626>.
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)", RFC 5766, Traversal Utilities for NAT (STUN)", RFC 5766,
DOI 10.17487/RFC5766, April 2010, DOI 10.17487/RFC5766, April 2010, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc5766>. editor.org/info/rfc5766>.
[RFC5769] Denis-Courmont, R., "Test Vectors for Session Traversal [RFC5769] Denis-Courmont, R., "Test Vectors for Session Traversal
Utilities for NAT (STUN)", RFC 5769, DOI 10.17487/RFC5769, Utilities for NAT (STUN)", RFC 5769, DOI 10.17487/RFC5769,
April 2010, <http://www.rfc-editor.org/info/rfc5769>. April 2010, <https://www.rfc-editor.org/info/rfc5769>.
[RFC5780] MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery [RFC5780] MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery
Using Session Traversal Utilities for NAT (STUN)", Using Session Traversal Utilities for NAT (STUN)",
RFC 5780, DOI 10.17487/RFC5780, May 2010, RFC 5780, DOI 10.17487/RFC5780, May 2010,
<http://www.rfc-editor.org/info/rfc5780>. <https://www.rfc-editor.org/info/rfc5780>.
[RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach,
"TCP Candidates with Interactive Connectivity "TCP Candidates with Interactive Connectivity
Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544, Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544,
March 2012, <http://www.rfc-editor.org/info/rfc6544>. March 2012, <https://www.rfc-editor.org/info/rfc6544>.
[RFC7231] Fielding, R. and R. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014, <https://www.rfc-
editor.org/info/rfc7231>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <http://www.rfc-editor.org/info/rfc7525>. 2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Digest Access Authentication", RFC 7616, Writing an IANA Considerations Section in RFCs", BCP 26,
DOI 10.17487/RFC7616, September 2015, RFC 8126, DOI 10.17487/RFC8126, May 2008,
<http://www.rfc-editor.org/info/rfc7616>. <https://www.rfc-editor.org/info/rfc8126>.
Appendix A. C Snippet to Determine STUN Message Types Appendix A. C Snippet to Determine STUN Message Types
Given a 16-bit STUN message type value in host byte order in msg_type Given a 16-bit STUN message type value in host byte order in msg_type
parameter, below are C macros to determine the STUN message types: parameter, below are C macros to determine the STUN message types:
<CODE BEGINS> <CODE BEGINS>
#define IS_REQUEST(msg_type) (((msg_type) & 0x0110) == 0x0000) #define IS_REQUEST(msg_type) (((msg_type) & 0x0110) == 0x0000)
#define IS_INDICATION(msg_type) (((msg_type) & 0x0110) == 0x0010) #define IS_INDICATION(msg_type) (((msg_type) & 0x0110) == 0x0010)
#define IS_SUCCESS_RESP(msg_type) (((msg_type) & 0x0110) == 0x0100) #define IS_SUCCESS_RESP(msg_type) (((msg_type) & 0x0110) == 0x0100)
skipping to change at page 60, line 9 skipping to change at page 60, line 9
Note: Before publication, the XX XX placeholder must be replaced by Note: Before publication, the XX XX placeholder must be replaced by
the value assigned to MESSAGE-INTEGRITY-SHA256 and USERHASH by the value assigned to MESSAGE-INTEGRITY-SHA256 and USERHASH by
IANA. The MESSAGE-INTEGRITY-SHA256 attribute value will need to IANA. The MESSAGE-INTEGRITY-SHA256 attribute value will need to
be updated after this. be updated after this.
Appendix C. Release notes Appendix C. Release notes
This section must be removed before publication as an RFC. This section must be removed before publication as an RFC.
C.1. Modifications between draft-ietf-tram-stunbis-12 and draft-ietf- C.1. Modifications between draft-ietf-tram-stunbis-13 and draft-ietf-
tram-stunbis-12
o Update references.
o Fixes some text following Shepherd review.
o Update co-author info.
C.2. Modifications between draft-ietf-tram-stunbis-12 and draft-ietf-
tram-stunbis-11 tram-stunbis-11
o Clarifies the procedure to define a new hash algorithm for o Clarifies the procedure to define a new hash algorithm for
message-integrity. message-integrity.
o Explain the procedure to deprecate SHA1 as message-integrity. o Explain the procedure to deprecate SHA1 as message-integrity.
o Added procedure for Happy Eyeballs (RFC 6555). o Added procedure for Happy Eyeballs (RFC 6555).
o Added verification that Happy Eyeballs works in the STUN Usage o Added verification that Happy Eyeballs works in the STUN Usage
checklist. checklist.
o Add reference to Base64 RFC. o Add reference to Base64 RFC.
o Changed co-author affiliation. o Changed co-author affiliation.
C.2. Modifications between draft-ietf-tram-stunbis-11 and draft-ietf- C.3. Modifications between draft-ietf-tram-stunbis-11 and draft-ietf-
tram-stunbis-10 tram-stunbis-10
o Made clear that the same HMAC than received in response of short o Made clear that the same HMAC than received in response of short
term credential must be used for subsequent transactions. term credential must be used for subsequent transactions.
o s/URL/URI/ o s/URL/URI/
o The "nonce cookie" is now mandatory to signal that SHA256 must be o The "nonce cookie" is now mandatory to signal that SHA256 must be
used in the next transaction. used in the next transaction.
o s/SHA1/SHA256/ o s/SHA1/SHA256/
o Changed co-author affiliation. o Changed co-author affiliation.
C.3. Modifications between draft-ietf-tram-stunbis-10 and draft-ietf- C.4. Modifications between draft-ietf-tram-stunbis-10 and draft-ietf-
tram-stunbis-09 tram-stunbis-09
o Removed the reserved value in the security registry, as it does o Removed the reserved value in the security registry, as it does
not make sense in a bitset. not make sense in a bitset.
o Updated change list. o Updated change list.
o Updated the minimum truncation size for M-I-256 to 16 bytes. o Updated the minimum truncation size for M-I-256 to 16 bytes.
o Changed the truncation order to match RFC 7518. o Changed the truncation order to match RFC 7518.
skipping to change at page 61, line 16 skipping to change at page 61, line 28
o Stated that STUN Usages have to explicitly state that they can use o Stated that STUN Usages have to explicitly state that they can use
truncation. truncation.
o Removed truncation from the MESSAGE-INTEGRITY attribute. o Removed truncation from the MESSAGE-INTEGRITY attribute.
o Add reference to C code in RFC 1952. o Add reference to C code in RFC 1952.
o Replaced RFC 2818 reference to RFC 6125. o Replaced RFC 2818 reference to RFC 6125.
C.4. Modifications between draft-ietf-tram-stunbis-09 and draft-ietf- C.5. Modifications between draft-ietf-tram-stunbis-09 and draft-ietf-
tram-stunbis-08 tram-stunbis-08
o Removed the reserved value in the security registry, as it does o Removed the reserved value in the security registry, as it does
not make sense in a bitset. not make sense in a bitset.
o Updated change list. o Updated change list.
o Updated the minimum truncation size for M-I-256 to 16 bytes. o Updated the minimum truncation size for M-I-256 to 16 bytes.
o Changed the truncation order to match RFC 7518. o Changed the truncation order to match RFC 7518.
skipping to change at page 61, line 39 skipping to change at page 62, line 5
o Stated that STUN Usages have to explicitly state that they can use o Stated that STUN Usages have to explicitly state that they can use
truncation. truncation.
o Removed truncation from the MESSAGE-INTEGRITY attribute. o Removed truncation from the MESSAGE-INTEGRITY attribute.
o Add reference to C code in RFC 1952. o Add reference to C code in RFC 1952.
o Replaced RFC 2818 reference to RFC 6125. o Replaced RFC 2818 reference to RFC 6125.
C.5. Modifications between draft-ietf-tram-stunbis-09 and draft-ietf- C.6. Modifications between draft-ietf-tram-stunbis-09 and draft-ietf-
tram-stunbis-08 tram-stunbis-08
o Packets discarded in a reliable or unreliable transaction triggers o Packets discarded in a reliable or unreliable transaction triggers
an attack error instead of a timeout error. An attack error on a an attack error instead of a timeout error. An attack error on a
reliable transport is signaled immediately instead of waiting for reliable transport is signaled immediately instead of waiting for
the timeout. the timeout.
o Explicitly state that a received 400 response without o Explicitly state that a received 400 response without
authentication will be dropped until timeout. authentication will be dropped until timeout.
skipping to change at page 62, line 17 skipping to change at page 62, line 30
o The 401 and 438 error response to subsequent requests may use the o The 401 and 438 error response to subsequent requests may use the
previous NONCE/password to authenticate, if they are still previous NONCE/password to authenticate, if they are still
available. available.
o Change "401 Unauthorized" to "401 Unauthenticated" o Change "401 Unauthorized" to "401 Unauthenticated"
o Make clear that in some cases it is impossible to add a MI or MI2 o Make clear that in some cases it is impossible to add a MI or MI2
even if the text says SHOULD NOT. even if the text says SHOULD NOT.
C.6. Modifications between draft-ietf-tram-stunbis-08 and draft-ietf- C.7. Modifications between draft-ietf-tram-stunbis-08 and draft-ietf-
tram-stunbis-07 tram-stunbis-07
o Updated list of changes since RFC 5389. o Updated list of changes since RFC 5389.
o More examples are automatically generated. o More examples are automatically generated.
o Message integrity truncation is fixed at a multiple of 4 bytes, o Message integrity truncation is fixed at a multiple of 4 bytes,
because the padding will not decrease by more than this. because the padding will not decrease by more than this.
o USERHASH contains the 32 bytes of the hash, not a character o USERHASH contains the 32 bytes of the hash, not a character
string. string.
o Updated the example to use the USERHASH attribute and the modified o Updated the example to use the USERHASH attribute and the modified
NONCE attribute. NONCE attribute.
o Updated ICEbis reference. o Updated ICEbis reference.
C.7. Modifications between draft-ietf-tram-stunbis-07 and draft-ietf- C.8. Modifications between draft-ietf-tram-stunbis-07 and draft-ietf-
tram-stunbis-06 tram-stunbis-06
o Add USERHASH attribute to carry the hashed version of the o Add USERHASH attribute to carry the hashed version of the
username. username.
o Add IANA registry and nonce encoding for Security Features that o Add IANA registry and nonce encoding for Security Features that
need to be protected from bid down attacks. need to be protected from bid down attacks.
o Modified MESSAGE-INTEGRITY and MESSAGE-INTEGRITY-SHA256 to support o Modified MESSAGE-INTEGRITY and MESSAGE-INTEGRITY-SHA256 to support
truncation limits (pending cryptographic review), truncation limits (pending cryptographic review),
C.8. Modifications between draft-ietf-tram-stunbis-06 and draft-ietf- C.9. Modifications between draft-ietf-tram-stunbis-06 and draft-ietf-
tram-stunbis-05 tram-stunbis-05
o Changed I-D references to RFC references. o Changed I-D references to RFC references.
o Changed CHANGE-ADDRESS to CHANGE-REQUEST (Errata #4233). o Changed CHANGE-ADDRESS to CHANGE-REQUEST (Errata #4233).
o Added test vector for MESSAGE-INTEGRITY-SHA256. o Added test vector for MESSAGE-INTEGRITY-SHA256.
o Address additional review comments from Jonathan Lennox and o Address additional review comments from Jonathan Lennox and
Brandon Williams. Brandon Williams.
C.9. Modifications between draft-ietf-tram-stunbis-05 and draft-ietf- C.10. Modifications between draft-ietf-tram-stunbis-05 and draft-ietf-
tram-stunbis-04 tram-stunbis-04
o Address review comments from Jonathan Lennox and Brandon Williams. o Address review comments from Jonathan Lennox and Brandon Williams.
C.10. Modifications between draft-ietf-tram-stunbis-04 and draft-ietf- C.11. Modifications between draft-ietf-tram-stunbis-04 and draft-ietf-
tram-stunbis-03 tram-stunbis-03
o Remove SCTP. o Remove SCTP.
o Remove DANE. o Remove DANE.
o s/MESSAGE-INTEGRITY2/MESSAGE-INTEGRITY-SHA256/ o s/MESSAGE-INTEGRITY2/MESSAGE-INTEGRITY-SHA256/
o Remove Salted SHA256 password hash. o Remove Salted SHA256 password hash.
o The RTO delay between transactions is removed. o The RTO delay between transactions is removed.
o Make clear that reusing NONCE will trigger a wasted round trip. o Make clear that reusing NONCE will trigger a wasted round trip.
C.11. Modifications between draft-ietf-tram-stunbis-03 and draft-ietf- C.12. Modifications between draft-ietf-tram-stunbis-03 and draft-ietf-
tram-stunbis-02 tram-stunbis-02
o SCTP prefix is now 0b00000101 instead of 0x11. o SCTP prefix is now 0b00000101 instead of 0x11.
o Add SCTP at various places it was needed. o Add SCTP at various places it was needed.
o Update the hash agility plan to take in account HMAC-SHA-256. o Update the hash agility plan to take in account HMAC-SHA-256.
o Adds the bid down attack on message-integrity in the security o Adds the bid down attack on message-integrity in the security
section. section.
C.12. Modifications between draft-ietf-tram-stunbis-02 and draft-ietf- C.13. Modifications between draft-ietf-tram-stunbis-02 and draft-ietf-
tram-stunbis-01 tram-stunbis-01
o STUN hash algorithm agility (currently only SHA-1 is allowed). o STUN hash algorithm agility (currently only SHA-1 is allowed).
o Clarify terminology, text and guidance for STUN fragmentation. o Clarify terminology, text and guidance for STUN fragmentation.
o Clarify whether it's valid to share nonces across TURN o Clarify whether it's valid to share nonces across TURN
allocations. allocations.
o Prevent the server to allocate the same NONCE to clients with o Prevent the server to allocate the same NONCE to clients with
skipping to change at page 64, line 25 skipping to change at page 64, line 47
transactions, not to serial transactions. That prevents a 3RTT transactions, not to serial transactions. That prevents a 3RTT
delay between the first transaction and the second transaction delay between the first transaction and the second transaction
with long term authentication. with long term authentication.
o Add text saying ORIGIN can increase a request size beyond the MTU o Add text saying ORIGIN can increase a request size beyond the MTU
and so require an SCTPoUDP transport. and so require an SCTPoUDP transport.
o Move the Acknowledgments and Contributor sections to the end of o Move the Acknowledgments and Contributor sections to the end of
the document, in accordance with RFC 7322 section 4. the document, in accordance with RFC 7322 section 4.
C.13. Modifications between draft-ietf-tram-stunbis-01 and draft-ietf- C.14. Modifications between draft-ietf-tram-stunbis-01 and draft-ietf-
tram-stunbis-00 tram-stunbis-00
o Add negotiation mechanism for new password algorithms. o Add negotiation mechanism for new password algorithms.
o Describe the MESSAGE-INTEGRITY/MESSAGE-INTEGRITY2 protocol. o Describe the MESSAGE-INTEGRITY/MESSAGE-INTEGRITY2 protocol.
o Add support for SCTP to solve the fragmentation problem. o Add support for SCTP to solve the fragmentation problem.
o Merge RFC 7350: o Merge RFC 7350:
skipping to change at page 65, line 12 skipping to change at page 65, line 33
* DNS discovery is done from the URI. * DNS discovery is done from the URI.
* Reorganized the text about default ports. * Reorganized the text about default ports.
o Add more C snippets. o Add more C snippets.
o Make clear that the cached RTO is discarded only if there is no o Make clear that the cached RTO is discarded only if there is no
new transations for 10 minutes. new transations for 10 minutes.
C.14. Modifications between draft-salgueiro-tram-stunbis-02 and draft- C.15. Modifications between draft-salgueiro-tram-stunbis-02 and draft-
ietf-tram-stunbis-00 ietf-tram-stunbis-00
o Draft adopted as WG item. o Draft adopted as WG item.
C.15. Modifications between draft-salgueiro-tram-stunbis-02 and draft- C.16. Modifications between draft-salgueiro-tram-stunbis-02 and draft-
salgueiro-tram-stunbis-01 salgueiro-tram-stunbis-01
o Add definition of MESSAGE-INTEGRITY2. o Add definition of MESSAGE-INTEGRITY2.
o Update text and reference from RFC 2988 to RFC 6298. o Update text and reference from RFC 2988 to RFC 6298.
o s/The IAB has mandated/The IAB has suggested/ (Errata #3737). o s/The IAB has mandated/The IAB has suggested/ (Errata #3737).
o Fix the figure for the UNKNOWN-ATTRIBUTES (Errata #2972). o Fix the figure for the UNKNOWN-ATTRIBUTES (Errata #2972).
skipping to change at page 65, line 46 skipping to change at page 66, line 19
o Update text and reference from RFC 2988 to RFC 6298. o Update text and reference from RFC 2988 to RFC 6298.
o s/The IAB has mandated/The IAB has suggested/ (Errata #3737). o s/The IAB has mandated/The IAB has suggested/ (Errata #3737).
o Fix the figure for the UNKNOWN-ATTRIBUTES (Errata #2972). o Fix the figure for the UNKNOWN-ATTRIBUTES (Errata #2972).
o Fix section number and make clear that the original domain name is o Fix section number and make clear that the original domain name is
used for the server certificate verification. This is consistent used for the server certificate verification. This is consistent
with what RFC 5922 (section 4) is doing. (Errata #2010) with what RFC 5922 (section 4) is doing. (Errata #2010)
C.16. Modifications between draft-salgueiro-tram-stunbis-01 and draft- C.17. Modifications between draft-salgueiro-tram-stunbis-01 and draft-
salgueiro-tram-stunbis-00 salgueiro-tram-stunbis-00
o Restore the RFC 5389 text. o Restore the RFC 5389 text.
o Add list of open issues. o Add list of open issues.
Acknowledgements Acknowledgements
Thanks to Michael Tuexen, Tirumaleswar Reddy, Oleg Moskalenko, Simon Thanks to Michael Tuexen, Tirumaleswar Reddy, Oleg Moskalenko, Simon
Perreault, Benjamin Schwartz, Rifaat Shekh-Yusef, Alan Johnston, Perreault, Benjamin Schwartz, Rifaat Shekh-Yusef, Alan Johnston,
Jonathan Lennox, Brandon Williams, Olle Johansson, Martin Thomson, Jonathan Lennox, Brandon Williams, Olle Johansson, Martin Thomson,
and Mihaly Meszaros for the comments, suggestions, and questions that Mihaly Meszaros and Tolga Asveren for the comments, suggestions, and
helped improve this document. questions that helped improve this document.
The authors of RFC 5389 would like to thank Cedric Aoun, Pete The authors of RFC 5389 would like to thank Cedric Aoun, Pete
Cordell, Cullen Jennings, Bob Penfield, Xavier Marjou, Magnus Cordell, Cullen Jennings, Bob Penfield, Xavier Marjou, Magnus
Westerlund, Miguel Garcia, Bruce Lowekamp, and Chris Sullivan for Westerlund, Miguel Garcia, Bruce Lowekamp, and Chris Sullivan for
their comments, and Baruch Sterman and Alan Hawrylyshen for initial their comments, and Baruch Sterman and Alan Hawrylyshen for initial
implementations. Thanks for Leslie Daigle, Allison Mankin, Eric implementations. Thanks for Leslie Daigle, Allison Mankin, Eric
Rescorla, and Henning Schulzrinne for IESG and IAB input on this Rescorla, and Henning Schulzrinne for IESG and IAB input on this
work. work.
Contributors Contributors
skipping to change at page 67, line 4 skipping to change at page 67, line 19
Email: gsalguei@cisco.com Email: gsalguei@cisco.com
Jonathan Rosenberg Jonathan Rosenberg
Cisco Cisco
Edison, NJ Edison, NJ
US US
Email: jdrosen@cisco.com Email: jdrosen@cisco.com
URI: http://www.jdrosen.net URI: http://www.jdrosen.net
Dan Wing Dan Wing
Email: dwing-ietf@fuggles.com Email: dwing-ietf@fuggles.com
Rohan Mahy Rohan Mahy
Plantronics Unaffiliated
345 Encinal Street
Santa Cruz, CA 95060
US
Email: rohan@ekabal.com Email: rohan.ietf@gmail.com
Philip Matthews Philip Matthews
Nokia Nokia
600 March Road 600 March Road
Ottawa, Ontario K2K 2T6 Ottawa, Ontario K2K 2T6
Canada Canada
Phone: 613-784-3139 Phone: 613-784-3139
Email: philip_matthews@magma.ca Email: philip_matthews@magma.ca
 End of changes. 88 change blocks. 
156 lines changed or deleted 162 lines changed or added

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