draft-ietf-behave-rfc3489bis-15.txt   draft-ietf-behave-rfc3489bis-16.txt 
BEHAVE Working Group J. Rosenberg BEHAVE Working Group J. Rosenberg
Internet-Draft Cisco Internet-Draft Cisco
Obsoletes: 3489 (if approved) R. Mahy Obsoletes: 3489 (if approved) R. Mahy
Intended status: Standards Track Plantronics Intended status: Standards Track Plantronics
Expires: August 26, 2008 P. Matthews Expires: January 3, 2009 P. Matthews
Avaya Avaya
D. Wing D. Wing
Cisco Cisco
February 23, 2008 July 2, 2008
Session Traversal Utilities for (NAT) (STUN) Session Traversal Utilities for (NAT) (STUN)
draft-ietf-behave-rfc3489bis-15 draft-ietf-behave-rfc3489bis-16
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 26, 2008. This Internet-Draft will expire on January 3, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
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 NAT traversal. It can as a tool for other protocols in dealing with NAT traversal. It can
be used by an endpoint to determine the IP address and port allocated be used by an endpoint to determine the IP address and port allocated
skipping to change at page 2, line 31 skipping to change at page 2, line 31
4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. STUN Message Structure . . . . . . . . . . . . . . . . . . . . 10 6. STUN Message Structure . . . . . . . . . . . . . . . . . . . . 10
7. Base Protocol Procedures . . . . . . . . . . . . . . . . . . . 12 7. Base Protocol Procedures . . . . . . . . . . . . . . . . . . . 12
7.1. Forming a Request or an Indication . . . . . . . . . . . 12 7.1. Forming a Request or an Indication . . . . . . . . . . . 12
7.2. Sending the Request or Indication . . . . . . . . . . . . 13 7.2. Sending the Request or Indication . . . . . . . . . . . . 13
7.2.1. Sending over UDP . . . . . . . . . . . . . . . . . . . 13 7.2.1. Sending over UDP . . . . . . . . . . . . . . . . . . . 13
7.2.2. Sending over TCP or TLS-over-TCP . . . . . . . . . . . 14 7.2.2. Sending over TCP or TLS-over-TCP . . . . . . . . . . . 14
7.3. Receiving a STUN Message . . . . . . . . . . . . . . . . 16 7.3. Receiving a STUN Message . . . . . . . . . . . . . . . . 16
7.3.1. Processing a Request . . . . . . . . . . . . . . . . . 17 7.3.1. Processing a Request . . . . . . . . . . . . . . . . . 17
7.3.1.1. Forming a Success or Error Response . . . . . . . 17 7.3.1.1. Forming a Success or Error Response . . . . . . . 18
7.3.1.2. Sending the Success or Error Response . . . . . . 18 7.3.1.2. Sending the Success or Error Response . . . . . . 18
7.3.2. Processing an Indication . . . . . . . . . . . . . . . 18 7.3.2. Processing an Indication . . . . . . . . . . . . . . . 19
7.3.3. Processing a Success Response . . . . . . . . . . . . 19 7.3.3. Processing a Success Response . . . . . . . . . . . . 19
7.3.4. Processing an Error Response . . . . . . . . . . . . . 19 7.3.4. Processing an Error Response . . . . . . . . . . . . . 19
8. FINGERPRINT Mechanism . . . . . . . . . . . . . . . . . . . . 20 8. FINGERPRINT Mechanism . . . . . . . . . . . . . . . . . . . . 20
9. DNS Discovery of a Server . . . . . . . . . . . . . . . . . . 20 9. DNS Discovery of a Server . . . . . . . . . . . . . . . . . . 21
10. Authentication and Message-Integrity Mechanisms . . . . . . . 21 10. Authentication and Message-Integrity Mechanisms . . . . . . . 22
10.1. Short-Term Credential Mechanism . . . . . . . . . . . . . 22 10.1. Short-Term Credential Mechanism . . . . . . . . . . . . . 22
10.1.1. Forming a Request or Indication . . . . . . . . . . . 22 10.1.1. Forming a Request or Indication . . . . . . . . . . . 22
10.1.2. Receiving a Request or Indication . . . . . . . . . . 22 10.1.2. Receiving a Request or Indication . . . . . . . . . . 23
10.1.3. Receiving a Response . . . . . . . . . . . . . . . . . 23 10.1.3. Receiving a Response . . . . . . . . . . . . . . . . . 24
10.2. Long-term Credential Mechanism . . . . . . . . . . . . . 24 10.2. Long-term Credential Mechanism . . . . . . . . . . . . . 24
10.2.1. Forming a Request . . . . . . . . . . . . . . . . . . 25 10.2.1. Forming a Request . . . . . . . . . . . . . . . . . . 25
10.2.1.1. First Request . . . . . . . . . . . . . . . . . . 25 10.2.1.1. First Request . . . . . . . . . . . . . . . . . . 25
10.2.1.2. Subsequent Requests . . . . . . . . . . . . . . . 25 10.2.1.2. Subsequent Requests . . . . . . . . . . . . . . . 25
10.2.2. Receiving a Request . . . . . . . . . . . . . . . . . 25 10.2.2. Receiving a Request . . . . . . . . . . . . . . . . . 25
10.2.3. Receiving a Response . . . . . . . . . . . . . . . . . 26 10.2.3. Receiving a Response . . . . . . . . . . . . . . . . . 26
11. ALTERNATE-SERVER Mechanism . . . . . . . . . . . . . . . . . . 27 11. ALTERNATE-SERVER Mechanism . . . . . . . . . . . . . . . . . . 27
12. Backwards Compatibility with RFC 3489 . . . . . . . . . . . . 28 12. Backwards Compatibility with RFC 3489 . . . . . . . . . . . . 28
12.1. Changes to Client Processing . . . . . . . . . . . . . . 28 12.1. Changes to Client Processing . . . . . . . . . . . . . . 28
12.2. Changes to Server Processing . . . . . . . . . . . . . . 28 12.2. Changes to Server Processing . . . . . . . . . . . . . . 29
13. Basic Server Behavior . . . . . . . . . . . . . . . . . . . . 29 13. Basic Server Behavior . . . . . . . . . . . . . . . . . . . . 29
14. STUN Usages . . . . . . . . . . . . . . . . . . . . . . . . . 29 14. STUN Usages . . . . . . . . . . . . . . . . . . . . . . . . . 30
15. STUN Attributes . . . . . . . . . . . . . . . . . . . . . . . 31 15. STUN Attributes . . . . . . . . . . . . . . . . . . . . . . . 31
15.1. MAPPED-ADDRESS . . . . . . . . . . . . . . . . . . . . . 32 15.1. MAPPED-ADDRESS . . . . . . . . . . . . . . . . . . . . . 32
15.2. XOR-MAPPED-ADDRESS . . . . . . . . . . . . . . . . . . . 33 15.2. XOR-MAPPED-ADDRESS . . . . . . . . . . . . . . . . . . . 32
15.3. USERNAME . . . . . . . . . . . . . . . . . . . . . . . . 34 15.3. USERNAME . . . . . . . . . . . . . . . . . . . . . . . . 33
15.4. MESSAGE-INTEGRITY . . . . . . . . . . . . . . . . . . . . 34 15.4. MESSAGE-INTEGRITY . . . . . . . . . . . . . . . . . . . . 34
15.5. FINGERPRINT . . . . . . . . . . . . . . . . . . . . . . . 35 15.5. FINGERPRINT . . . . . . . . . . . . . . . . . . . . . . . 35
15.6. ERROR-CODE . . . . . . . . . . . . . . . . . . . . . . . 36 15.6. ERROR-CODE . . . . . . . . . . . . . . . . . . . . . . . 35
15.7. REALM . . . . . . . . . . . . . . . . . . . . . . . . . . 37 15.7. REALM . . . . . . . . . . . . . . . . . . . . . . . . . . 37
15.8. NONCE . . . . . . . . . . . . . . . . . . . . . . . . . . 38 15.8. NONCE . . . . . . . . . . . . . . . . . . . . . . . . . . 37
15.9. UNKNOWN-ATTRIBUTES . . . . . . . . . . . . . . . . . . . 38 15.9. UNKNOWN-ATTRIBUTES . . . . . . . . . . . . . . . . . . . 37
15.10. SERVER . . . . . . . . . . . . . . . . . . . . . . . . . 38 15.10. SERVER . . . . . . . . . . . . . . . . . . . . . . . . . 38
15.11. ALTERNATE-SERVER . . . . . . . . . . . . . . . . . . . . 38 15.11. CLIENT . . . . . . . . . . . . . . . . . . . . . . . . . 38
15.12. ALTERNATE-SERVER . . . . . . . . . . . . . . . . . . . . 38
16. Security Considerations . . . . . . . . . . . . . . . . . . . 39 16. Security Considerations . . . . . . . . . . . . . . . . . . . 39
16.1. Attacks against the Protocol . . . . . . . . . . . . . . 39 16.1. Attacks against the Protocol . . . . . . . . . . . . . . 39
16.1.1. Outside Attacks . . . . . . . . . . . . . . . . . . . 39 16.1.1. Outside Attacks . . . . . . . . . . . . . . . . . . . 39
16.1.2. Inside Attacks . . . . . . . . . . . . . . . . . . . . 40 16.1.2. Inside Attacks . . . . . . . . . . . . . . . . . . . . 40
16.2. Attacks Affecting the Usage . . . . . . . . . . . . . . . 40 16.2. Attacks Affecting the Usage . . . . . . . . . . . . . . . 40
16.2.1. Attack I: DDoS Against a Target . . . . . . . . . . . 41 16.2.1. Attack I: DDoS Against a Target . . . . . . . . . . . 41
16.2.2. Attack II: Silencing a Client . . . . . . . . . . . . 41 16.2.2. Attack II: Silencing a Client . . . . . . . . . . . . 41
16.2.3. Attack III: Assuming the Identity of a Client . . . . 41 16.2.3. Attack III: Assuming the Identity of a Client . . . . 41
16.2.4. Attack IV: Eavesdropping . . . . . . . . . . . . . . . 41 16.2.4. Attack IV: Eavesdropping . . . . . . . . . . . . . . . 41
16.3. Hash Agility Plan . . . . . . . . . . . . . . . . . . . . 42 16.3. Hash Agility Plan . . . . . . . . . . . . . . . . . . . . 42
skipping to change at page 12, line 47 skipping to change at page 12, line 47
When formulating a request or indication message, the agent MUST When formulating a request or indication message, the agent MUST
follow the rules in Section 6 when creating the header. In addition, follow the rules in Section 6 when creating the header. In addition,
the message class MUST be either "Request" or "Indication" (as the message class MUST be either "Request" or "Indication" (as
appropriate), and the method must be either Binding or some method appropriate), and the method must be either Binding or some method
defined in another document. defined in another document.
The agent then adds any attributes specified by the method or the The agent then adds any attributes specified by the method or the
usage. For example, some usages may specify that the agent use an usage. For example, some usages may specify that the agent use an
authentication method (Section 10) or the FINGERPRINT attribute authentication method (Section 10) or the FINGERPRINT attribute
(Section 8). (Section 8). In addition, the client SHOULD add a CLIENT attribute
to the message.
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 requests and responses sent over UDP SHOULD be less than the All STUN messages sent over UDP SHOULD be less than the path MTU, if
path MTU, if known. If the path MTU is unknown, requests and known. If the path MTU is unknown, messages SHOULD be the smaller of
responses SHOULD be the smaller of 576 bytes and the first-hop MTU 576 bytes and the first-hop MTU for IPv4 [RFC1122] and 1280 bytes for
for IPv4 [RFC1122] and 1280 bytes for IPv6 [RFC2460]. This value IPv6 [RFC2460]. This value corresponds to the overall size of the IP
corresponds to the overall size of the IP packet. Consequently, for packet. Consequently, for IPv4, the actual STUN message would need
IPv4, the actual STUN message would need to be less than 548 bytes to be less than 548 bytes (576 minus 20 bytes IP header, minus 8 byte
(576 minus 20 bytes IP header, minus 8 byte UDP header, assuming no UDP header, assuming no IP options are used). STUN provides no
IP options are used). STUN provides no ability to handle the case ability to handle the case where the request is under the MTU but the
where the request is under the MTU but the response would be larger response would be larger than the MTU. It is not envisioned that
than the MTU. It is not envisioned that this limitation will be an this limitation will be an issue for STUN. The MTU limitation is a
issue for STUN. The MTU limitation is a SHOULD, and not a MUST, to SHOULD, and not a MUST, to account for cases where STUN itself is
account for cases where STUN itself is being used to probe for MTU being used to probe for MTU characteristics
characteristics [I-D.ietf-behave-nat-behavior-discovery]. Outside of [I-D.ietf-behave-nat-behavior-discovery]. Outside of this or similar
this or similar applications, the MTU constraint MUST be followed. applications, the MTU constraint MUST be followed.
7.2. Sending the Request or Indication 7.2. Sending the Request or Indication
The agent then sends the request or indication. This document The agent then sends the request or indication. This document
specifies how to send STUN messages over UDP, TCP, or TLS-over-TCP; specifies how to send STUN messages over UDP, TCP, or TLS-over-TCP;
other transport protocols may be added in the future. The STUN usage other transport protocols may be added in the future. The STUN usage
must specify which transport protocol is used, and how the agent must specify which transport protocol is used, and how the agent
determines the IP address and port of the recipient. Section 9 determines the IP address and port of the recipient. Section 9
describes a DNS-based method of determining the IP address and port describes a DNS-based method of determining the IP address and port
of a server which a usage may elect to use. STUN may be used with of a server which a usage may elect to use. STUN may be used with
anycast addresses, but only with UDP and in usages where anycast addresses, but only with UDP and in usages where
authentication is not used. authentication is not used.
At any time, a client MAY have multiple outstanding STUN requests At any time, a client MAY have multiple outstanding STUN requests
with the same STUN server (that is, multiple transactions in with the same STUN server (that is, multiple transactions in
progress, with different transaction ids). Absent other limits to progress, with different transaction ids). Absent other limits to
the rate of new transactions (such as those specified by ICE for the rate of new transactions (such as those specified by ICE for
connectivity checks), a client SHOULD space new transactions to a connectivity checks), a client SHOULD space new transactions to a
server by RTO and SHOULD limit itself to ten outstanding transactions server by RTO and SHOULD limit itself to ten outstanding transactions
to the same sevrer. to the same server.
7.2.1. Sending over UDP 7.2.1. Sending over UDP
When running STUN over UDP it is possible that the STUN message might When running STUN over UDP it is possible that the STUN message might
be dropped by the network. Reliability of STUN request/response be dropped by the network. Reliability of STUN request/response
transactions is accomplished through retransmissions of the request transactions is accomplished through retransmissions of the request
message by the client application itself. STUN indications are not message by the client application itself. STUN indications are not
retransmitted; thus indication transactions over UDP are not retransmitted; thus indication transactions over UDP are not
reliable. reliable.
skipping to change at page 14, line 27 skipping to change at page 14, line 28
The value for RTO SHOULD be cached by a client after the completion The value for RTO SHOULD be cached by a client after the completion
of the transaction, and used as the starting value for RTO for the of the transaction, and used as the starting value for RTO for the
next transaction to the same server (based on equality of IP next transaction to the same server (based on equality of IP
address). The value SHOULD be considered stale and discarded after address). The value SHOULD be considered stale and discarded after
10 minutes. 10 minutes.
Retransmissions continue until a response is received, or until a Retransmissions continue until a response is received, or until a
total of Rc requests have been sent. Rc SHOULD be configurable and total of Rc requests have been sent. Rc SHOULD be configurable and
SHOULD have a default of 7. If, after the last request, a duration SHOULD have a default of 7. If, after the last request, a duration
equal to 16 times the RTO has passed without a response (providing equal to Rm times the RTO has passed without a response (providing
ample time to get a response if only this final request actually ample time to get a response if only this final request actually
succeeds), the client SHOULD consider the transaction to have failed. succeeds), the client SHOULD consider the transaction to have failed.
A STUN transaction over UDP is also considered failed if there has Rm SHOULD be configurable and SHOULD have a default of 16. A STUN
been a hard ICMP error [RFC1122]. For example, assuming an RTO of transaction over UDP is also considered failed if there has been a
500ms, requests would be sent at times 0ms, 500ms, 1500ms, 3500ms, hard ICMP error [RFC1122]. For example, assuming an RTO of 500ms,
7500ms, 15500ms, and 31500ms. If the client has not received a requests would be sent at times 0ms, 500ms, 1500ms, 3500ms, 7500ms,
response after 39500ms, the client will consider the transaction to 15500ms, and 31500ms. If the client has not received a response
have timed out. after 39500ms, the client will consider the transaction to have timed
out.
7.2.2. Sending over TCP or TLS-over-TCP 7.2.2. Sending over TCP or TLS-over-TCP
For TCP and TLS-over-TCP, the client opens a TCP connection to the For TCP and TLS-over-TCP, the client opens a TCP connection to the
server. server.
In some usages of STUN, STUN is sent as the only protocol over the In some usages of STUN, STUN is sent as the only protocol over the
TCP connection. In this case, it can be sent without the aid of any TCP connection. In this case, it can be sent without the aid of any
additional framing or demultiplexing. In other usages, or with other additional framing or demultiplexing. In other usages, or with other
extensions, it may be multiplexed with other data over a TCP extensions, it may be multiplexed with other data over a TCP
skipping to change at page 15, line 22 skipping to change at page 15, line 25
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, revoked, or if it does certificate. If the certificate is invalid, 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 Section 3.1 of RFC 2818 identification procedures defined in Section 3.1 of RFC 2818
[RFC2818]. Those procedures assume the client is dereferencing a [RFC2818]. Those procedures assume the client is dereferencing a
URI. For purposes of usage with this specification, the client URI. For purposes of usage with this specification, the client
treats the domain name or IP address used in Section 8.1 as the host treats the domain name or IP address used in Section 8.1 as the host
portion of the URI that has been dereferenced. If DNS was not used, portion of the URI that has been dereferenced. Alternatively, a
the client MUST be configured with a set of authorized domains whose client MAY be configured with a set of domains or IP addresses that
certificates will be accepted. are trusted; if a certificate is received that identifies one of
those domains or IP addresses, the client considers the identity of
the server to be 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, the mandatory ciphersuites and TLS handling procedures connection, the mandatory ciphersuites and TLS handling procedures
operate as defined by those protocols. operate as defined by those protocols.
Reliability of STUN over TCP and TLS-over-TCP is handled by TCP Reliability of STUN over TCP and TLS-over-TCP is handled by TCP
itself, and there are no retransmissions at the STUN protocol level. itself, and there are no retransmissions at the STUN protocol level.
However, for a request/response transaction, if the client has not However, for a request/response transaction, if the client has not
received a response 39500ms after it sent the SYN to establish the received a response by Ti seconds after it sent the SYN to establish
connection, it considers the transaction to have timed out. This the connection, it considers the transaction to have timed out. Ti
SHOULD be configurable and SHOULD have a default of 39.5s. This
value has been chosen to equalize the TCP and UDP timeouts for the value has been chosen to equalize the TCP and UDP timeouts for the
default initial RTO. default initial RTO.
In addition, if the client is unable to establish the TCP connection, In addition, if the client is unable to establish the TCP connection,
or the TCP connection is reset or fails before a response is or the TCP connection is reset or fails before a response is
received, any request/response transaction in progress is considered received, any request/response transaction in progress is considered
to have failed to have failed
The client MAY send multiple transactions over a single TCP (or TLS- The client MAY send multiple transactions over a single TCP (or TLS-
over-TCP) connection, and it MAY send another request before over-TCP) connection, and it MAY send another request before
skipping to change at page 16, line 17 skipping to change at page 16, line 22
sent over that connection, and; sent over that connection, and;
o if multiplexing other application protocols over that port, has o if multiplexing other application protocols over that port, has
finished using that other application, and; finished using that other application, and;
o if using that learned port with a remote peer, has established o if using that learned port with a remote peer, has established
communications with that remote peer, as is required by some TCP communications with that remote peer, as is required by some TCP
NAT traversal techniques (e.g., [I-D.ietf-mmusic-ice-tcp]). NAT traversal techniques (e.g., [I-D.ietf-mmusic-ice-tcp]).
At the server end, the server SHOULD keep the connection open, and At the server end, the server SHOULD keep the connection open, and
let the client close it. Bindings learned by the client will remain let the client close it, unless the server has determined that the
valid in intervening NATs only while the connection remains open. connection has timed out (for example, due to the client
Only the client knows how long it needs the binding. The server disconnecting from the network). Bindings learned by the client will
SHOULD NOT close a connection if a request was received over that remain valid in intervening NATs only while the connection remains
connection for which a response was not sent. A server MUST NOT ever open. Only the client knows how long it needs the binding. The
open a connection back towards the client in order to send a server SHOULD NOT close a connection if a request was received over
that connection for which a response was not sent. A server MUST NOT
ever open a connection back towards the client in order to send a
response. Servers SHOULD follow best practices regarding connection response. Servers SHOULD follow best practices regarding connection
management in cases of overload. management in cases of overload.
7.3. Receiving a STUN Message 7.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
defined in in Section 12. Those additional procedures are optional, defined in in Section 12. Those additional procedures are optional,
and usages can elect to utilize them. First, a set of processing and usages can elect to utilize them. First, a set of processing
skipping to change at page 17, line 34 skipping to change at page 17, line 41
The server then does any additional checking that the method or the The server then does any additional checking that the method or the
specific usage requires. If all the checks succeed, the server specific usage requires. If all the checks succeed, the server
formulates a success response as described below. formulates a success response as described below.
If the request uses UDP transport and is a retransmission of a If the request uses UDP transport and is a retransmission of a
request for which the server has already generated a success response request for which the server has already generated a success response
within the last 40 seconds, the server MUST retransmit the same within the last 40 seconds, the server MUST retransmit the same
success response. One way for a server to do this is to remember all success response. One way for a server to do this is to remember all
transaction IDs received over UDP and their corresponding responses transaction IDs received over UDP and their corresponding responses
in the last 10 seconds. Another way is to reprocess the request and in the last 40 seconds. Another way is to reprocess the request and
recompute the response. The latter technique MUST only be applied to recompute the response. The latter technique MUST only be applied to
requests which are idempotent (a request is considered idempotent requests which are idempotent (a request is considered idempotent
when the same request can be safely repeated without impacting the when the same request can be safely repeated without impacting the
overall state of the system) and result in the same success response overall state of the system) and result in the same success response
for the same request. The Binding method is considered to idempotent for the same request. The Binding method is considered to idempotent
in this way (even though certain rare network events could cause the in this way (even though certain rare network events could cause the
reflexive transport address value to change). Extensions to STUN reflexive transport address value to change). Extensions to STUN
SHOULD state whether their request types have this property or not. SHOULD state whether their request types have this property or not.
7.3.1.1. Forming a Success or Error Response 7.3.1.1. Forming a Success or Error Response
skipping to change at page 21, line 43 skipping to change at page 22, line 5
the one the server is listening on. The default port for STUN over the one the server is listening on. The default port for STUN over
TLS is XXXX [[NOTE TO RFC EDITOR: Replace with IANA registered port TLS is XXXX [[NOTE TO RFC EDITOR: Replace with IANA registered port
number for stuns]]. Servers can run STUN over TLS on the same port number for stuns]]. Servers can run STUN over TLS on the same port
as STUN over TCP if the server software supports determining whether as STUN over TCP if the server software supports determining whether
the initial message is a TLS or STUN message. the initial message is a TLS or STUN message.
If no SRV records were found, the client performs an A or AAAA record If no SRV records were found, the client performs an A or AAAA record
lookup of the domain name. The result will be a list of IP lookup of the domain name. The result will be a list of IP
addresses, each of which can be contacted at the default port using addresses, each of which can be contacted at the default port using
UDP or TCP, independent of the STUN usage. For usages that require UDP or TCP, independent of the STUN usage. For usages that require
TLS, lack of SRV records is equivalent to a failure of the TLS, the client connects to one of the IP addresses using the default
transaction, since the request or indication MUST NOT be sent unless STUN over TLS port.
SRV records provided a transport address specifically for TLS.
10. Authentication and Message-Integrity Mechanisms 10. 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 28, line 7 skipping to change at page 28, line 14
used for the previous request. The client SHOULD reuse any used for the previous request. The client SHOULD reuse any
authentication credentials from the old request in the new authentication credentials from the old request in the new
transaction. If the server has been redirected to a server on which transaction. If the server has been redirected to a server on which
it has already tried this request within the last five minutes, it it has already tried this request within the last five minutes, it
MUST ignore the redirection and consider the transaction to have MUST ignore the redirection and consider the transaction to have
failed. This prevents infinite ping-ponging between servers in case failed. This prevents infinite ping-ponging between servers in case
of redirection loops. of redirection loops.
12. Backwards Compatibility with RFC 3489 12. Backwards Compatibility with RFC 3489
This section define procedures that allow a degree of backwards This section defines procedures that allow a degree of backwards
compatible with the original protocol defined in RFC 3489 [RFC3489]. compatible with the original protocol defined in RFC 3489 [RFC3489].
This mechanism is optional, meant to be utilized only in cases where This mechanism is optional, meant to be utilized only in cases where
a new client can connect to an old server, or vice-a-versa. A usage a new client can connect to an old server, or vice-a-versa. A usage
must define if and when this procedure is used. must define if and when this procedure is used.
Section 19 lists all the changes between this specification and RFC Section 19 lists all the changes between this specification and RFC
3489 [RFC3489]. However, not all of these differences are important, 3489 [RFC3489]. However, not all of these differences are important,
because "classic STUN" was only used in a few specific ways. For the because "classic STUN" was only used in a few specific ways. For the
purposes of this extension, the important changes are the following. purposes of this extension, the important changes are the following.
In RFC 3489: In RFC 3489:
skipping to change at page 28, line 41 skipping to change at page 28, line 48
* These attributes are now part of the NAT Behavior Discovery * These attributes are now part of the NAT Behavior Discovery
usage. [I-D.ietf-behave-nat-behavior-discovery] usage. [I-D.ietf-behave-nat-behavior-discovery]
12.1. Changes to Client Processing 12.1. Changes to Client Processing
A client that wants to interoperate with a [RFC3489] server SHOULD A client that wants to interoperate with a [RFC3489] server SHOULD
send a request message that uses the Binding method, contains no send a request message that uses the Binding method, contains no
attributes, and uses UDP as the transport protocol to the server. If attributes, and uses UDP as the transport protocol to the server. If
successful, the success response received from the server will successful, the success response received from the server will
contain a MAPPED-ADDRESS attribute rather than an XOR-MAPPED-ADDRESS contain a MAPPED-ADDRESS attribute rather than an XOR-MAPPED-ADDRESS
attribute; other than this change, the processing of the response is attribute. A client seeking to interoperate with an older server
identical to the procedures described above. MUST be prepared to receive either. Furthermore, the client MUST
ignore any Reserved comprehension-required attributes which might
appear in the response. Of the Reserved attributes in in
Section 18.2, 0x0002,0x0004,0x0005 and 0x000B may appear in Binding
Responses from a server compliant to RFC 3489. Other than this
change, the processing of the response is identical to the procedures
described above.
12.2. Changes to Server Processing 12.2. Changes to Server Processing
A STUN server can detect when a given Binding Request message was A STUN server can detect when a given Binding Request message was
sent from an RFC 3489 [RFC3489] client by the absence of the correct sent from an RFC 3489 [RFC3489] client by the absence of the correct
value in the Magic Cookie field. When the server detects an RFC 3489 value in the Magic Cookie field. When the server detects an RFC 3489
client, it SHOULD copy the value seen in the Magic Cookie field in client, it SHOULD copy the value seen in the Magic Cookie field in
the Binding Request to the Magic Cookie field in the Binding Response the Binding Request to the Magic Cookie field in the Binding Response
message, and insert a MAPPED-ADDRESS attribute instead of an XOR- message, and insert a MAPPED-ADDRESS attribute instead of an XOR-
MAPPED-ADDRESS attribute. MAPPED-ADDRESS attribute.
skipping to change at page 32, line 5 skipping to change at page 32, line 7
To allow future revisions of this specification to add new attributes To allow future revisions of this specification to add new attributes
if needed, the attribute space is divided into two ranges. if needed, the attribute space is divided into two ranges.
Attributes with type values between 0x0000 and 0x7FFF are Attributes with type values between 0x0000 and 0x7FFF are
comprehension-required attributes, which means that the STUN agent comprehension-required attributes, which means that the STUN agent
cannot successfully process the message unless it understands the cannot successfully process the message unless it understands the
attribute. Attributes with type values between 0x8000 and 0xFFFF are attribute. Attributes with type values between 0x8000 and 0xFFFF are
comprehension-optional attributes, which means that those attributes comprehension-optional attributes, which means that those attributes
can be ignored by the STUN agent if it does not understand them. can be ignored by the STUN agent if it does not understand them.
The STUN Attribute types defined by this specification are: The set of STUN attribute types is maintained by IANA. The initial
set defined by this specification is found in Section 18.2.
Comprehension-required range (0x0000-0x7FFF):
0x0000: (Reserved)
0x0001: MAPPED-ADDRESS
0x0006: USERNAME
0x0007: (Reserved; was PASSWORD)
0x0008: MESSAGE-INTEGRITY
0x0009: ERROR-CODE
0x000A: UNKNOWN-ATTRIBUTES
0x0014: REALM
0x0015: NONCE
0x0020: XOR-MAPPED-ADDRESS
Comprehension-optional range (0x8000-0xFFFF)
0x8022: SERVER
0x8023: ALTERNATE-SERVER
0x8028: FINGERPRINT
The rest of this section describes the format of the various The rest of this section describes the format of the various
attributes defined in this specification. attributes defined in this specification.
15.1. MAPPED-ADDRESS 15.1. MAPPED-ADDRESS
The MAPPED-ADDRESS attribute indicates a reflexive transport address The MAPPED-ADDRESS attribute indicates a reflexive transport address
of the client. It consists of an eight bit address family, and a of the client. It consists of an eight bit address family, and a
sixteen bit port, followed by a fixed length value representing the sixteen bit port, followed by a fixed length value representing the
IP address. If the address family is IPv4, the address MUST be 32 IP address. If the address family is IPv4, the address MUST be 32
skipping to change at page 32, line 48 skipping to change at page 32, line 34
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0| Family | Port | |0 0 0 0 0 0 0 0| Family | Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Address (32 bits or 128 bits) | | Address (32 bits or 128 bits) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Format of MAPPED-ADDRESS attribute Figure 5: Format of MAPPED-ADDRESS attribute
The address family can take on the following values: The address family can take on the following values:
0x01:IPv4 0x01:IPv4
0x02:IPv6 0x02:IPv6
The first 8 bits of the MAPPED-ADDRESS MUST be set to 0 and MUST be The first 8 bits of the MAPPED-ADDRESS MUST be set to 0 and MUST be
ignored by receivers. These bits are present for aligning parameters ignored by receivers. These bits are present for aligning parameters
on natural 32 bit boundaries. on natural 32 bit boundaries.
This attribute is used only by servers for achieving backwards This attribute is used only by servers for achieving backwards
skipping to change at page 33, line 32 skipping to change at page 33, line 16
The format of the XOR-MAPPED-ADDRESS is: The format of the XOR-MAPPED-ADDRESS is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x x x x x x x x| Family | X-Port | |x x x x x x x x| Family | X-Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| X-Address (Variable) | X-Address (Variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Format of XOR-MAPPED-ADDRESS Attribute Figure 7: Format of XOR-MAPPED-ADDRESS Attribute
The Family represents the IP address family, and is encoded The Family represents the IP address family, and is encoded
identically to the Family in MAPPED-ADDRESS. identically to the Family in MAPPED-ADDRESS.
X-Port is computed by taking the mapped port in host byte order, X-Port is computed by taking the mapped port in host byte order,
XOR'ing it with the most significant 16 bits of the magic cookie, and XOR'ing it with the most significant 16 bits of the magic cookie, and
then the converting the result to network byte order. If the IP then the converting the result to network byte order. If the IP
address family is IPv4, X-Address is computed by taking the mapped IP address family is IPv4, X-Address is computed by taking the mapped IP
address in host byte order, XOR'ing it with the magic cookie, and address in host byte order, XOR'ing it with the magic cookie, and
converting the result to network byte order. If the IP address converting the result to network byte order. If the IP address
skipping to change at page 34, line 45 skipping to change at page 34, line 29
all other attributes that follow MESSAGE-INTEGRITY. all other attributes that follow MESSAGE-INTEGRITY.
The key for the HMAC depends on whether long term or short term The key for the HMAC depends on whether long term or short term
credentials are in use. For long term credentials, the key is 16 credentials are in use. For long term credentials, the key is 16
bytes: bytes:
key = MD5(username ":" realm ":" SASLPrep(password)) key = MD5(username ":" realm ":" SASLPrep(password))
That is, the 16 byte key is formed by taking the MD5 hash of the That is, the 16 byte key is formed by taking the MD5 hash of the
result of concatenating the following five fields: (1) The username, result of concatenating the following five fields: (1) The username,
with any quotes and trailing nulls removed, (2) A single colon, (3) with any quotes and trailing nulls removed, as taken from the
The realm, with any quotes and trailing nulls removed, (4) A single USERNAME attribute (in which case SASLPrep has already been applied)
colon, and (5) the password, with any trailing nulls removed and (2) A single colon, (3) The realm, with any quotes and trailing nulls
after processing using SASLPrep. For example, if the username was removed, (4) A single colon, and (5) the password, with any trailing
'user', the realm was 'realm', and the password was 'pass', then the nulls removed and after processing using SASLPrep. For example, if
16-byte HMAC key would be the result of performing an MD5 hash on the the username was 'user', the realm was 'realm', and the password was
string 'user:realm:pass', the resulting hash being 'pass', then the 16-byte HMAC key would be the result of performing
an MD5 hash on the string 'user:realm:pass', the resulting hash being
0x8493fbc53ba582fb4c044c456bdc40eb. 0x8493fbc53ba582fb4c044c456bdc40eb.
For short term credentials: For short term credentials:
key = SASLPrep(password) key = SASLPrep(password)
Where MD5 is defined in RFC 1321 [RFC1321] and SASLPrep() is defined Where MD5 is defined in RFC 1321 [RFC1321] and SASLPrep() is defined
in [RFC4013]. in [RFC4013].
The structure of the key when used with long term credentials The structure of the key when used with long term credentials
skipping to change at page 36, line 29 skipping to change at page 36, line 16
characters (which can be as long as 763 bytes). characters (which can be as long as 763 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason Phrase (variable) .. | Reason Phrase (variable) ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: ERROR-CODE Attribute Figure 10: ERROR-CODE Attribute
To facilitate processing, the class of the error code (the hundreds To facilitate processing, the class of the error code (the hundreds
digit) is encoded separately from the rest of the code, as shown in digit) is encoded separately from the rest of the code, as shown in
Figure 11. Figure 10.
The Reserved bits SHOULD be 0, and are for alignment on 32-bit The Reserved bits SHOULD be 0, and are for alignment on 32-bit
boundaries. Receivers MUST ignore these bits. The Class represents boundaries. Receivers MUST ignore these bits. The Class represents
the hundreds digit of the error code. The value MUST be between 3 the hundreds digit of the error code. The value MUST be between 3
and 6. The number represents the error code modulo 100, and its and 6. The number represents the error code modulo 100, and its
value MUST be between 0 and 99. value MUST be between 0 and 99.
The following error codes, along with their recommended reason The following error codes, along with their recommended reason
phrases are defined: phrases are defined:
skipping to change at page 38, line 31 skipping to change at page 38, line 16
represents an attribute type that was not understood by the server. represents an attribute type that was not understood by the server.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute 1 Type | Attribute 2 Type | | Attribute 1 Type | Attribute 2 Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute 3 Type | Attribute 4 Type ... | Attribute 3 Type | Attribute 4 Type ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Format of UNKNOWN-ATTRIBUTES attribute Figure 11: Format of UNKNOWN-ATTRIBUTES attribute
Note: In [RFC3489], this field was padded to 32 by duplicating the Note: In [RFC3489], this field was padded to 32 by duplicating the
last attribute. In this version of the specification, the normal last attribute. In this version of the specification, the normal
padding rules for attributes are used instead. padding rules for attributes are used instead.
15.10. SERVER 15.10. SERVER
The server attribute contains a textual description of the software The server attribute contains a textual description of the software
being used by the server, including manufacturer and version number. being used by the server. This SHOULD include manufacturer and
The attribute has no impact on operation of the protocol, and serves version number. The attribute has no impact on operation of the
only as a tool for diagnostic and debugging purposes. The value of protocol, and serves only as a tool for diagnostic and debugging
SERVER is variable length. It MUST be a UTF-8 [RFC3629] encoded purposes. The value of SERVER is variable length. It MUST be a
sequence of less than 128 characters (which can be as long as 763 UTF-8 [RFC3629] encoded sequence of less than 128 characters (which
bytes). can be as long as 763 bytes).
15.11. ALTERNATE-SERVER 15.11. CLIENT
The client attribute contains a textual description of the software
being used by the client. This SHOULD include manufacturer and
version number. The attribute has no impact on operation of the
protocol, and serves only as a tool for diagnostic and debugging
purposes. The value of CLIENT is variable length. It MUST be a
UTF-8 [RFC3629] encoded sequence of less than 128 characters (which
can be as long as 763 bytes).
15.12. ALTERNATE-SERVER
The alternate server represents an alternate transport address The alternate server represents an alternate transport address
identifying a different STUN server which the STUN client should try. identifying a different STUN server which the STUN client should try.
It is encoded in the same way as MAPPED-ADDRESS, and thus refers to a It is encoded in the same way as MAPPED-ADDRESS, and thus refers to a
single server by IP address. The IP address family MUST be identical single server by IP address. The IP address family MUST be identical
to that of the source IP address of the request. to that of the source IP address of the request.
This attribute MUST only appear in an error response that contains a This attribute MUST only appear in an error response that contains a
MESSAGE-INTEGRITY attribute. This prevents it from being used in MESSAGE-INTEGRITY attribute. This prevents it from being used in
skipping to change at page 40, line 24 skipping to change at page 40, line 21
A rogue client may use a STUN server as a reflector, sending it A rogue client may use a STUN server as a reflector, sending it
requests with a falsified source IP address and port. In such a requests with a falsified source IP address and port. In such a
case, the response would be delivered to that source IP and port. case, the response would be delivered to that source IP and port.
There is no amplification of the number of packets with this attack There is no amplification of the number of packets with this attack
(the STUN server sends one packet for each packet sent by the (the STUN server sends one packet for each packet sent by the
client), though there is a small increase in the amount of data, client), though there is a small increase in the amount of data,
since STUN responses are typically larger than requests. This attack since STUN responses are typically larger than requests. This attack
is mitigated by ingress source address filtering. is mitigated by ingress source address filtering.
Revealing the specific software version of the server or client
through the SERVER and CLIENT attributes might allow them to become
more vulnerable to attacks against software that is known to contain
security holes. Implementers SHOULD make the CLIENT and SERVER
attributes a configurable option.
16.2. Attacks Affecting the Usage 16.2. Attacks Affecting the Usage
This section lists attacks that might be launched against a usage of This section lists attacks that might be launched against a usage of
STUN. Each STUN usage must consider whether these attacks are STUN. Each STUN usage must consider whether these attacks are
applicable to it, and if so, discuss counter-measures. applicable to it, and if so, discuss counter-measures.
Most of the attacks in this section revolve around an attacker Most of the attacks in this section revolve around an attacker
modifying the reflexive address learned by a STUN client through a modifying the reflexive address learned by a STUN client through a
Binding Request/Binding Response transaction. Since the usage of the Binding Request/Binding Response transaction. Since the usage of the
reflexive address is a function of the usage, the applicability and reflexive address is a function of the usage, the applicability and
skipping to change at page 42, line 39 skipping to change at page 42, line 41
The IAB has mandated that protocols developed for this purpose The IAB has mandated that protocols developed for this purpose
document a specific set of considerations. Because some STUN usages document a specific set of considerations. Because some STUN usages
provide UNSAF functions (such as ICE [I-D.ietf-mmusic-ice] ), and provide UNSAF functions (such as ICE [I-D.ietf-mmusic-ice] ), and
others do not (such as SIP Outbound [I-D.ietf-sip-outbound]), answers others do not (such as SIP Outbound [I-D.ietf-sip-outbound]), answers
to these considerations need to be addressed by the usages to these considerations need to be addressed by the usages
themselves. themselves.
18. IANA Considerations 18. IANA Considerations
IANA is hereby requested to create three new registries: a STUN IANA is hereby requested to create three new registries: a "STUN
methods registry, a STUN Attributes registry, and a STUN Error Codes Methods Registry", a "STUN Attributes Registry", and a "STUN Error
registry. IANA is also requested to change the name of the assigned Codes registry". IANA is also requested to change the name of the
IANA port for STUN from "nat-stun-port" to "stun". assigned IANA port for STUN from "nat-stun-port" to "stun".
18.1. STUN Methods Registry 18.1. STUN Methods Registry
A STUN method is a hex number in the range 0x000 - 0x3FF. The A STUN method is a hex number in the range 0x000 - 0x3FF. The
encoding of STUN method into a STUN message is described in encoding of STUN method into a STUN message is described in
Section 6. Section 6.
The initial STUN methods are: The initial STUN methods are:
0x000: (Reserved) 0x000: (Reserved)
0x001: Binding 0x001: Binding
0x002: (Reserved; was SharedSecret) 0x002: (Reserved; was SharedSecret)
STUN methods in the range 0x000 - 0x1FF are assigned by IETF STUN methods in the range 0x000 - 0x1FF are assigned by IETF Review
Consensus [RFC2434]. STUN methods in the range 0x200 - 0x3FF are [RFC5226]. STUN methods in the range 0x200 - 0x3FF are assigned by
assigned on a First Come First Served basis [RFC2434] Designated Expert [RFC5226]
18.2. STUN Attribute Registry 18.2. STUN Attribute Registry
A STUN Attribute type is a hex number in the range 0x0000 - 0xFFFF. A STUN Attribute type is a hex number in the range 0x0000 - 0xFFFF.
STUN attribute types in the range 0x0000 - 0x7FFF are considered STUN attribute types in the range 0x0000 - 0x7FFF are considered
comprehension-required; STUN attribute types in the range 0x8000 - comprehension-required; STUN attribute types in the range 0x8000 -
0xFFFF are considered comprehension-optional. A STUN agent handles 0xFFFF are considered comprehension-optional. A STUN agent handles
unknown comprehension-required and comprehension-optional attributes unknown comprehension-required and comprehension-optional attributes
differently. differently.
The initial STUN Attributes types are: The initial STUN Attributes types are:
Comprehension-required range (0x0000-0x7FFF): Comprehension-required range (0x0000-0x7FFF):
0x0000: (Reserved) 0x0000: (Reserved)
0x0001: MAPPED-ADDRESS 0x0001: MAPPED-ADDRESS
0x0002: (Reserved; was RESPONSE-ADDRESS) 0x0002: (Reserved; was RESPONSE-ADDRESS)
0x0004: (Reserved; was SOURCE-ADDRESS)
0x0005: (Reserved; was CHANGED-ADDRESS)
0x0006: USERNAME 0x0006: USERNAME
0x0007: (Reserved; was PASSWORD) 0x0007: (Reserved; was PASSWORD)
0x0008: MESSAGE-INTEGRITY 0x0008: MESSAGE-INTEGRITY
0x0009: ERROR-CODE 0x0009: ERROR-CODE
0x000A: UNKNOWN-ATTRIBUTES 0x000A: UNKNOWN-ATTRIBUTES
0x000B: (Reserved; was REFLECTED-FROM)
0x0014: REALM 0x0014: REALM
0x0015: NONCE 0x0015: NONCE
0x0020: XOR-MAPPED-ADDRESS 0x0020: XOR-MAPPED-ADDRESS
Comprehension-optional range (0x8000-0xFFFF) Comprehension-optional range (0x8000-0xFFFF)
0x8022: SERVER 0x8022: SERVER
0x8023: ALTERNATE-SERVER 0x8023: ALTERNATE-SERVER
0x8028: FINGERPRINT 0x8028: FINGERPRINT
0x8030: CLIENT
STUN Attribute types in the first half of the comprehension-required STUN Attribute types in the first half of the comprehension-required
range (0x0000 - 0x3FFF) and in the first half of the comprehension- range (0x0000 - 0x3FFF) and in the first half of the comprehension-
optional range (0x8000 - 0xBFFF) are assigned by IETF Consensus optional range (0x8000 - 0xBFFF) are assigned by IETF Review
[RFC2434]. STUN Attribute types in the second half of the [RFC5226]. STUN Attribute types in the second half of the
comprehension-required range (0x4000 - 0x7FFF) and in the second half comprehension-required range (0x4000 - 0x7FFF) and in the second half
of the comprehension-optional range (0xC000 - 0xFFFF) are assigned on of the comprehension-optional range (0xC000 - 0xFFFF) are assigned by
a First Come First Served basis [RFC2434]. Designated Expert [RFC5226]. The responsibility of the expert is to
verify that the selected codepoint(s) are not in use, and that the
request is not for an abnormally large number of codepoints.
Technical review of the extension itself is outside the scope of the
designated expert responsibility.
18.3. STUN Error Code Registry 18.3. STUN Error Code Registry
A STUN Error code is a number in the range 0 - 699. STUN error codes A STUN Error code is a number in the range 0 - 699. STUN error codes
are accompanied by a textual reason phrase in UTF-8 [RFC3629] which are accompanied by a textual reason phrase in UTF-8 [RFC3629] which
is intended only for human consumption and can be anything is intended only for human consumption and can be anything
appropriate; this document proposes only suggested values. appropriate; this document proposes only suggested values.
STUN error codes are consistent in codepoint assignments and STUN error codes are consistent in codepoint assignments and
semantics with SIP [RFC3261] and HTTP [RFC2616]. semantics with SIP [RFC3261] and HTTP [RFC2616].
The initial values in this registry are given in Section 15.6. The initial values in this registry are given in Section 15.6.
New STUN error codes are assigned on an IETF Consensus basis New STUN error codes are assigned based on IETF Review [RFC5226].
[RFC2434]. The specification must carefully consider how clients The specification must carefully consider how clients that do not
that do not understand this error code will process it before understand this error code will process it before granting the
granting the request. See the rules in Section 7.3.4. request. See the rules in Section 7.3.4.
18.4. STUN UDP and TCP Port Numbers 18.4. STUN UDP and TCP Port Numbers
IANA has previously assigned port 3478 for STUN. This port appears IANA has previously assigned port 3478 for STUN. This port appears
in the IANA registry under the moniker "nat-stun-port". In order to in the IANA registry under the moniker "nat-stun-port". In order to
align the DNS SRV procedures with the registered protocol service, align the DNS SRV procedures with the registered protocol service,
IANA is requested to change the name of protocol assigned to port IANA is requested to change the name of protocol assigned to port
3478 from "nat-stun-port" to "stun", and the textual name from 3478 from "nat-stun-port" to "stun", and the textual name from
"Simple Traversal of UDP Through NAT (STUN)" to "Session Traversal "Simple Traversal of UDP Through NAT (STUN)" to "Session Traversal
Utilities for NAT", so that the IANA port registry would read: Utilities for NAT", so that the IANA port registry would read:
skipping to change at page 48, line 44 skipping to change at page 48, line 51
November 2007. November 2007.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
June 2002. June 2002.
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral
Self-Address Fixing (UNSAF) Across Network Address Self-Address Fixing (UNSAF) Across Network Address
Translation", RFC 3424, November 2002. Translation", RFC 3424, November 2002.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
October 1998. May 2008.
[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", SIGCOMM 1987,
August 1987. August 1987.
Appendix A. C Snippet to Determine STUN Message Types Appendix A. C Snippet to Determine STUN Message Types
Given an 16-bit STUN message type value in host byte order in Given an 16-bit STUN message type value in host byte order in
msg_type parameter, below are C macros to determine the STUN message msg_type parameter, below are C macros to determine the STUN message
types: types:
 End of changes. 45 change blocks. 
114 lines changed or deleted 137 lines changed or added

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