draft-ietf-tram-stunbis-11.txt   draft-ietf-tram-stunbis-12.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: September 14, 2017 Cisco Expires: October 2, 2017 Cisco
D. Wing D. Wing
R. Mahy R. Mahy
Plantronics Plantronics
P. Matthews P. Matthews
Avaya Nokia
March 13, 2017 March 31, 2017
Session Traversal Utilities for NAT (STUN) Session Traversal Utilities for NAT (STUN)
draft-ietf-tram-stunbis-11 draft-ietf-tram-stunbis-12
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 September 14, 2017. This Internet-Draft will expire on October 2, 2017.
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 15 skipping to change at page 3, line 15
9.2.3.1. First Request . . . . . . . . . . . . . . . . . . 29 9.2.3.1. First Request . . . . . . . . . . . . . . . . . . 29
9.2.3.2. Subsequent Requests . . . . . . . . . . . . . . . 29 9.2.3.2. Subsequent Requests . . . . . . . . . . . . . . . 29
9.2.4. Receiving a Request . . . . . . . . . . . . . . . . . 29 9.2.4. Receiving a Request . . . . . . . . . . . . . . . . . 29
9.2.5. Receiving a Response . . . . . . . . . . . . . . . . 31 9.2.5. Receiving a Response . . . . . . . . . . . . . . . . 31
10. ALTERNATE-SERVER Mechanism . . . . . . . . . . . . . . . . . 33 10. ALTERNATE-SERVER Mechanism . . . . . . . . . . . . . . . . . 33
11. Backwards Compatibility with RFC 3489 . . . . . . . . . . . . 34 11. Backwards Compatibility with RFC 3489 . . . . . . . . . . . . 34
12. Basic Server Behavior . . . . . . . . . . . . . . . . . . . . 34 12. Basic Server Behavior . . . . . . . . . . . . . . . . . . . . 34
13. STUN Usages . . . . . . . . . . . . . . . . . . . . . . . . . 35 13. STUN Usages . . . . . . . . . . . . . . . . . . . . . . . . . 35
14. STUN Attributes . . . . . . . . . . . . . . . . . . . . . . . 36 14. STUN Attributes . . . . . . . . . . . . . . . . . . . . . . . 36
14.1. MAPPED-ADDRESS . . . . . . . . . . . . . . . . . . . . . 37 14.1. MAPPED-ADDRESS . . . . . . . . . . . . . . . . . . . . . 37
14.2. XOR-MAPPED-ADDRESS . . . . . . . . . . . . . . . . . . . 37 14.2. XOR-MAPPED-ADDRESS . . . . . . . . . . . . . . . . . . . 38
14.3. USERNAME . . . . . . . . . . . . . . . . . . . . . . . . 38 14.3. USERNAME . . . . . . . . . . . . . . . . . . . . . . . . 39
14.4. USERHASH . . . . . . . . . . . . . . . . . . . . . . . . 39 14.4. USERHASH . . . . . . . . . . . . . . . . . . . . . . . . 39
14.5. MESSAGE-INTEGRITY . . . . . . . . . . . . . . . . . . . 39 14.5. MESSAGE-INTEGRITY . . . . . . . . . . . . . . . . . . . 39
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
skipping to change at page 3, line 41 skipping to change at page 3, line 41
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 . . . 48
15.2.4. Attack IV: Eavesdropping . . . . . . . . . . . . . . 48 15.2.4. Attack IV: Eavesdropping . . . . . . . . . . . . . . 48
15.3. Hash Agility Plan . . . . . . . . . . . . . . . . . . . 49 15.3. Hash Agility Plan . . . . . . . . . . . . . . . . . . . 49
16. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 49 16. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 49
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 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 . . . . . . . . . . . . . . . . . 50
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 . . . . . . . . . . . . . . 51
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
skipping to change at page 4, line 15 skipping to change at page 4, line 15
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 . . . . . . . . . . . . . . . . . . . 52
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-11 and C.1. Modifications between draft-ietf-tram-stunbis-12 and
draft-ietf-tram-stunbis-11 . . . . . . . . . . . . . . . 60
C.2. Modifications between draft-ietf-tram-stunbis-11 and
draft-ietf-tram-stunbis-10 . . . . . . . . . . . . . . . 60 draft-ietf-tram-stunbis-10 . . . . . . . . . . . . . . . 60
C.2. Modifications between draft-ietf-tram-stunbis-10 and C.3. Modifications between draft-ietf-tram-stunbis-10 and
draft-ietf-tram-stunbis-09 . . . . . . . . . . . . . . . 60 draft-ietf-tram-stunbis-09 . . . . . . . . . . . . . . . 60
C.3. Modifications between draft-ietf-tram-stunbis-09 and
draft-ietf-tram-stunbis-08 . . . . . . . . . . . . . . . 60
C.4. Modifications between draft-ietf-tram-stunbis-09 and C.4. Modifications between draft-ietf-tram-stunbis-09 and
draft-ietf-tram-stunbis-08 . . . . . . . . . . . . . . . 61 draft-ietf-tram-stunbis-08 . . . . . . . . . . . . . . . 61
C.5. Modifications between draft-ietf-tram-stunbis-08 and C.5. Modifications between draft-ietf-tram-stunbis-09 and
draft-ietf-tram-stunbis-07 . . . . . . . . . . . . . . . 61 draft-ietf-tram-stunbis-08 . . . . . . . . . . . . . . . 61
C.6. Modifications between draft-ietf-tram-stunbis-07 and C.6. Modifications between draft-ietf-tram-stunbis-08 and
draft-ietf-tram-stunbis-07 . . . . . . . . . . . . . . . 62
C.7. Modifications between draft-ietf-tram-stunbis-07 and
draft-ietf-tram-stunbis-06 . . . . . . . . . . . . . . . 62 draft-ietf-tram-stunbis-06 . . . . . . . . . . . . . . . 62
C.7. Modifications between draft-ietf-tram-stunbis-06 and C.8. Modifications between draft-ietf-tram-stunbis-06 and
draft-ietf-tram-stunbis-05 . . . . . . . . . . . . . . . 62 draft-ietf-tram-stunbis-05 . . . . . . . . . . . . . . . 62
C.8. Modifications between draft-ietf-tram-stunbis-05 and C.9. Modifications between draft-ietf-tram-stunbis-05 and
draft-ietf-tram-stunbis-04 . . . . . . . . . . . . . . . 62 draft-ietf-tram-stunbis-04 . . . . . . . . . . . . . . . 63
C.9. Modifications between draft-ietf-tram-stunbis-04 and C.10. Modifications between draft-ietf-tram-stunbis-04 and
draft-ietf-tram-stunbis-03 . . . . . . . . . . . . . . . 62 draft-ietf-tram-stunbis-03 . . . . . . . . . . . . . . . 63
C.10. Modifications between draft-ietf-tram-stunbis-03 and C.11. Modifications between draft-ietf-tram-stunbis-03 and
draft-ietf-tram-stunbis-02 . . . . . . . . . . . . . . . 63 draft-ietf-tram-stunbis-02 . . . . . . . . . . . . . . . 63
C.11. Modifications between draft-ietf-tram-stunbis-02 and C.12. Modifications between draft-ietf-tram-stunbis-02 and
draft-ietf-tram-stunbis-01 . . . . . . . . . . . . . . . 63 draft-ietf-tram-stunbis-01 . . . . . . . . . . . . . . . 63
C.12. Modifications between draft-ietf-tram-stunbis-01 and C.13. Modifications between draft-ietf-tram-stunbis-01 and
draft-ietf-tram-stunbis-00 . . . . . . . . . . . . . . . 64
C.13. Modifications between draft-salgueiro-tram-stunbis-02 and
draft-ietf-tram-stunbis-00 . . . . . . . . . . . . . . . 64 draft-ietf-tram-stunbis-00 . . . . . . . . . . . . . . . 64
C.14. Modifications between draft-salgueiro-tram-stunbis-02 and C.14. Modifications between draft-salgueiro-tram-stunbis-02 and
draft-salgueiro-tram-stunbis-01 . . . . . . . . . . . . . 64 draft-ietf-tram-stunbis-00 . . . . . . . . . . . . . . . 65
C.15. Modifications between draft-salgueiro-tram-stunbis-01 and C.15. Modifications between draft-salgueiro-tram-stunbis-02 and
draft-salgueiro-tram-stunbis-01 . . . . . . . . . . . . . 65
C.16. Modifications between draft-salgueiro-tram-stunbis-01 and
draft-salgueiro-tram-stunbis-00 . . . . . . . . . . . . . 65 draft-salgueiro-tram-stunbis-00 . . . . . . . . . . . . . 65
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 65 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 66
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 65 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
port. It also provides a way for an endpoint to keep a NAT binding port. It also provides a way for an endpoint to keep a NAT binding
alive. With some extensions, the protocol can be used to do alive. With some extensions, the protocol can be used to do
skipping to change at page 22, line 31 skipping to change at page 22, line 31
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
is sorted and then tried. However, RFC 2782 only states that the is sorted and then tried. However, RFC 2782 only states that the
client should "try to connect to the (protocol, address, service)" client should "try to connect to the (protocol, address, service)"
without giving any details on what happens in the event of failure. without giving any details on what happens in the event of failure.
When following these procedures, if the STUN transaction times out When following these procedures, if the STUN transaction times out
without receipt of a response, the client SHOULD retry the request to without receipt of a response, the client SHOULD retry the request to
the next server in the ordered defined by RFC 2782. Such a retry is the next server in the ordered defined by RFC 2782. Such a retry is
only possible for request/response transmissions, since indication only possible for request/response transmissions, since indication
transactions generate no response or timeout. transactions generate no response or timeout.
In addition, instead of querying either the A or the AAAA resource
records for a domain name, the client MUST query both and try the
requests with all the IP addresses received, as specified in
[RFC6555].
The default port for STUN requests is 3478, for both TCP and UDP. The default port for STUN requests is 3478, for both TCP and UDP.
The default port for STUN over TLS and STUN over DTLS requests is The default port for STUN over TLS and STUN over DTLS requests is
5349. Servers can run STUN over DTLS on the same port as STUN over 5349. Servers can run STUN over DTLS on the same port as STUN over
UDP if the server software supports determining whether the initial UDP if the server software supports determining whether the initial
message is a DTLS or STUN message. Servers can run STUN over TLS on message is a DTLS or STUN message. Servers can run STUN over TLS on
the same port as STUN over TCP if the server software supports the same port as STUN over TCP if the server software supports
determining whether the initial message is a TLS or STUN message. determining whether the initial message is a TLS or STUN message.
Administrators of STUN servers SHOULD use these ports in their SRV Administrators of STUN servers SHOULD use these ports in their SRV
records for UDP and TCP. In all cases, the port in DNS MUST reflect records for UDP and TCP. In all cases, the port in DNS MUST reflect
the one on which the server is listening. the one on which the server is listening.
If no SRV records were found, the client performs an A or AAAA record If no SRV records were found, the client performs both an A and AAAA
lookup of the domain name. The result will be a list of IP record lookup of the domain name, as described in [RFC6555]. The
addresses, each of which can be contacted at the default port using result will be a list of IP addresses, each of which can be
UDP or TCP, independent of the STUN usage. For usages that require simultaneously contacted at the default port using UDP or TCP,
TLS, the client connects to one of the IP addresses using the default independent of the STUN usage. For usages that require TLS, the
STUN over TLS port. For usages that require DTLS, the client client connects to the IP addresses using the default STUN over TLS
connects to one of the IP addresses using the default STUN over DTLS port. For usages that require DTLS, the client connects to the IP
port. addresses using the default STUN over DTLS port.
9. Authentication and Message-Integrity Mechanisms 9. Authentication and Message-Integrity Mechanisms
This section defines two mechanisms for STUN that a client and server This section defines two mechanisms for STUN that a client and server
can use to provide authentication and message integrity; these two can use to provide authentication and message integrity; these two
mechanisms are known as the short-term credential mechanism and the mechanisms are known as the short-term credential mechanism and the
long-term credential mechanism. These two mechanisms are optional, long-term credential mechanism. These two mechanisms are optional,
and each usage must specify if and when these mechanisms are used. and each usage must specify if and when these mechanisms are used.
Consequently, both clients and servers will know which mechanism (if Consequently, both clients and servers will know which mechanism (if
any) to follow based on knowledge of which usage applies. For any) to follow based on knowledge of which usage applies. For
skipping to change at page 27, line 12 skipping to change at page 27, line 12
invalid by the server, in which case the rejection provides a new invalid by the server, in which case the rejection provides a new
nonce to the client. nonce to the client.
Note that the long-term credential mechanism cannot be used to Note that the long-term credential mechanism cannot be used to
protect indications, since indications cannot be challenged. Usages protect indications, since indications cannot be challenged. Usages
utilizing indications must either use a short-term credential or omit utilizing indications must either use a short-term credential or omit
authentication and message integrity for them. authentication and message integrity for them.
To indicate that it supports this specification, a server MUST To indicate that it supports this specification, a server MUST
prepend the NONCE attribute value with the character string composed prepend the NONCE attribute value with the character string composed
of "obMatJos2" concatenated with the Base64 encoding of the 24 bit of "obMatJos2" concatenated with the Base64 [RFC4648] encoding of the
STUN Security Features as defined in Section 17.1. The 24 bit 24 bit STUN Security Features as defined in Section 17.1. The 24 bit
Security Feature set is encoded as a 24 bit integer in network order. Security Feature set is encoded as a 24 bit integer in network order.
If no security features are used, then the value 0 MUST be encoded If no security features are used, then the value 0 MUST be encoded
instead. For the remainder of this document the term "nonce cookie" instead. For the remainder of this document the term "nonce cookie"
will refer to the complete 13 character string prepended to the NONCE will refer to the complete 13 character string prepended to the NONCE
attribute value. attribute value.
Since the long-term credential mechanism is susceptible to offline Since the long-term credential mechanism is susceptible to offline
dictionary attacks, deployments SHOULD utilize passwords that are dictionary attacks, deployments SHOULD utilize passwords that are
difficult to guess. In cases where the credentials are not entered difficult to guess. In cases where the credentials are not entered
by the user, but are rather placed on a client device during device by the user, but are rather placed on a client device during device
skipping to change at page 34, line 50 skipping to change at page 34, line 50
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,
FINGERPRINT provides no benefit. Requiring it would break FINGERPRINT provides no benefit. Requiring it would break
compatibility with RFC 3489, and such compatibility is desirable in a compatibility with RFC 3489, and such compatibility is desirable in a
stand-alone server. Stand-alone STUN servers SHOULD support stand-alone server. Stand-alone STUN servers SHOULD support
backwards compatibility with [RFC3489] clients, as described in backwards compatibility with [RFC3489] clients, as described in
Section 11. Section 11.
It is RECOMMENDED that administrators of STUN servers provide DNS It is RECOMMENDED that administrators of STUN servers provide DNS
entries for those servers as described in Section 8. entries for those servers as described in Section 8. If both A and
AAAA Resource Records are returned then the client can simultaneously
send STUN Binding requests to the IPv4 and IPv6 addresses (as
specified in [RFC6555]), as the Binding request is idempotent. Note
that the MAPPED-ADDRESS or XOR-MAPPED-ADDRESS attributes that are
returned will not necessarily match the address family of the server
address used.
A basic STUN server is not a solution for NAT traversal by itself. A basic STUN server is not a solution for NAT traversal by itself.
However, it can be utilized as part of a solution through STUN However, it can be utilized as part of a solution through STUN
usages. This is discussed further in Section 13. usages. This is discussed further in Section 13.
13. STUN Usages 13. STUN Usages
STUN by itself is not a solution to the NAT traversal problem. STUN by itself is not a solution to the NAT traversal problem.
Rather, STUN defines a tool that can be used inside a larger Rather, STUN defines a tool that can be used inside a larger
solution. The term "STUN usage" is used for any solution that uses solution. The term "STUN usage" is used for any solution that uses
skipping to change at page 35, line 39 skipping to change at page 35, line 44
o The considerations around manual vs. automatic key derivation for o The considerations around manual vs. automatic key derivation for
the integrity mechanism, as discussed in [RFC4107]. the integrity mechanism, as discussed in [RFC4107].
o What mechanisms are used to distinguish STUN messages from other o What mechanisms are used to distinguish STUN messages from other
messages. When STUN is run over TCP, a framing mechanism may be messages. When STUN is run over TCP, a framing mechanism may be
required. required.
o How a STUN client determines the IP address and port of the STUN o How a STUN client determines the IP address and port of the STUN
server. server.
o How simultaneous use of IPv4 and IPv6 addresses (Happy Eyeballs
[RFC6555]) works with non-idempotent transactions when both
address families are found for the STUN server.
o Whether backwards compatibility to RFC 3489 is required. o Whether backwards compatibility to RFC 3489 is required.
o What optional attributes defined here (such as FINGERPRINT and o What optional attributes defined here (such as FINGERPRINT and
ALTERNATE-SERVER) or in other extensions are required. ALTERNATE-SERVER) or in other extensions are required.
o If MESSAGE-INTEGRITY-256 truncation is permitted, and the limits o If MESSAGE-INTEGRITY-256 truncation is permitted, and the limits
permitted for truncation. permitted for truncation.
In addition, any STUN usage must consider the security implications In addition, any STUN usage must consider the security implications
of using STUN in that usage. A number of attacks against STUN are of using STUN in that usage. A number of attacks against STUN are
skipping to change at page 49, line 15 skipping to change at page 49, line 15
the attacker could already observe packets sent to the client. This the attacker could already observe packets sent to the client. This
attack is, as a result, only useful for observing traffic by attack is, as a result, only useful for observing traffic by
attackers on the path from the client to the STUN server, but not attackers on the path from the client to the STUN server, but not
generally on the path of packets being routed towards the client. generally on the path of packets being routed towards the client.
15.3. Hash Agility Plan 15.3. Hash Agility Plan
This specification uses both HMAC-SHA-1 and HMAC-SHA-256 for This specification uses both HMAC-SHA-1 and HMAC-SHA-256 for
computation of the message integrity. If, at a later time, HMAC- computation of the message integrity. If, at a later time, HMAC-
SHA-256 is found to be compromised, the following is the remedy that SHA-256 is found to be compromised, the following is the remedy that
will be applied. will be applied:
We will define a STUN extension that introduces a new message- o Both a new message-integrity attribute and a new STUN Security
integrity attribute, computed using a new hash. Clients would be Feature bit will be allocated in a Standard Track document. The
required to include both the new and old message-integrity attributes new message-integrity attribute will have its value computed using
in their requests or indications. A new server will utilize the new a new hash. The STUN Security Feature bit will be used to
message-integrity attribute, and an old one, the old. After a simultaneously signal to a STUN client using the Long Term
transition period where mixed implementations are in deployment, the Credential Mechanism that this server supports this new hash
old message-integrity attribute will be deprecated by another algorithm, and will prevent bid down attacks on the new message-
specification, and clients will cease including it in requests. integrity attribute.
After a transition period, a new document updating this document will o STUN Client and Server using the Short Term Credential Mechanism
remove the usage of HMAC-SHA-1 for computation of the message- will need to get an updated external mechanism that they can use
integrity. to signal what message-integrity attributes are in use.
The bid down protection mechanism described in this document is new,
and thus cannot currently protect against a bid down attack that
lowers the strength of the hash algorithm to HMAC-SHA-1. This is
why, after a transition period, a new document updating this document
will assign a new STUN Security Feature bit for deprecating HMAC-SHA-
1. When used, this bit will signal that HMAC-SHA-1 is deprecated and
should no longer be used.
16. IAB Considerations 16. IAB Considerations
The IAB has studied the problem of Unilateral Self-Address Fixing The IAB has studied the problem of Unilateral Self-Address Fixing
(UNSAF), which is the general process by which a client attempts to (UNSAF), which is the general process by which a client attempts to
determine its address in another realm on the other side of a NAT determine its address in another realm on the other side of a NAT
through a collaborative protocol reflection mechanism ([RFC3424]). through a collaborative protocol reflection mechanism ([RFC3424]).
STUN can be used to perform this function using a Binding request/ STUN can be used to perform this function using a Binding request/
response transaction if one agent is behind a NAT and the other is on response transaction if one agent is behind a NAT and the other is on
the public side of the NAT. the public side of the NAT.
skipping to change at page 54, line 34 skipping to change at page 54, line 34
[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,
<http://www.rfc-editor.org/info/rfc2782>. <http://www.rfc-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, <http://www.rfc-editor.org/info/rfc3629>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<http://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,
<http://www.rfc-editor.org/info/rfc5246>. <http://www.rfc-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
skipping to change at page 55, line 9 skipping to change at page 55, line 14
[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,
<http://www.rfc-editor.org/info/rfc6298>. <http://www.rfc-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, <http://www.rfc-editor.org/info/rfc6347>.
[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April
2012, <http://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, <http://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, <http://www.rfc-editor.org/info/rfc7350>.
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-11 and draft-ietf- C.1. Modifications between draft-ietf-tram-stunbis-12 and draft-ietf-
tram-stunbis-11
o Clarifies the procedure to define a new hash algorithm for
message-integrity.
o Explain the procedure to deprecate SHA1 as message-integrity.
o Added procedure for Happy Eyeballs (RFC 6555).
o Added verification that Happy Eyeballs works in the STUN Usage
checklist.
o Add reference to Base64 RFC.
o Changed co-author affiliation.
C.2. 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.2. Modifications between draft-ietf-tram-stunbis-10 and draft-ietf- C.3. 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 trancation 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.
o Fixed bugs in truncation boundary text. o Fixed bugs in truncation boundary text.
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.3. Modifications between draft-ietf-tram-stunbis-09 and draft-ietf- C.4. 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 trancation 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.
o Fixed bugs in truncation boundary text. o Fixed bugs in truncation boundary text.
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 attrbute. 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 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 61, line 47 skipping to change at page 62, line 17
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.5. Modifications between draft-ietf-tram-stunbis-08 and draft-ietf- C.6. 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 attribuet 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.6. Modifications between draft-ietf-tram-stunbis-07 and draft-ietf- C.7. 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.7. Modifications between draft-ietf-tram-stunbis-06 and draft-ietf- C.8. 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.8. Modifications between draft-ietf-tram-stunbis-05 and draft-ietf- C.9. 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.9. Modifications between draft-ietf-tram-stunbis-04 and draft-ietf- C.10. 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.10. Modifications between draft-ietf-tram-stunbis-03 and draft-ietf- C.11. 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.11. Modifications between draft-ietf-tram-stunbis-02 and draft-ietf- C.12. 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 5 skipping to change at page 64, line 25
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.12. Modifications between draft-ietf-tram-stunbis-01 and draft-ietf- C.13. 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 64, line 40 skipping to change at page 65, line 12
* 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.13. Modifications between draft-salgueiro-tram-stunbis-02 and draft- C.14. 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.14. Modifications between draft-salgueiro-tram-stunbis-02 and draft- C.15. 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 25 skipping to change at page 65, line 46
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.15. Modifications between draft-salgueiro-tram-stunbis-01 and draft- C.16. 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,
skipping to change at page 66, line 41 skipping to change at page 67, line 17
Rohan Mahy Rohan Mahy
Plantronics Plantronics
345 Encinal Street 345 Encinal Street
Santa Cruz, CA 95060 Santa Cruz, CA 95060
US US
Email: rohan@ekabal.com Email: rohan@ekabal.com
Philip Matthews Philip Matthews
Avaya Nokia
1135 Innovation Drive 600 March Road
Ottawa, Ontario K2K 3G7 Ottawa, Ontario K2K 2T6
Canada Canada
Phone: +1 613 592 4343 x224 Phone: 613-784-3139
Email: philip_matthews@magma.ca Email: philip_matthews@magma.ca
 End of changes. 48 change blocks. 
76 lines changed or deleted 127 lines changed or added

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