draft-ietf-behave-rfc3489bis-16.txt   draft-ietf-behave-rfc3489bis-17.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: January 3, 2009 P. Matthews Expires: January 15, 2009 P. Matthews
Avaya Avaya
D. Wing D. Wing
Cisco Cisco
July 2, 2008 July 14, 2008
Session Traversal Utilities for (NAT) (STUN) Session Traversal Utilities for (NAT) (STUN)
draft-ietf-behave-rfc3489bis-16 draft-ietf-behave-rfc3489bis-17
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 January 3, 2009. This Internet-Draft will expire on January 15, 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 32 skipping to change at page 2, line 32
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 . . . . . . . 18 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 . . . . . . 19
7.3.2. Processing an Indication . . . . . . . . . . . . . . . 19 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 . . . . . . . . . . . . . 20
8. FINGERPRINT Mechanism . . . . . . . . . . . . . . . . . . . . 20 8. FINGERPRINT Mechanism . . . . . . . . . . . . . . . . . . . . 20
9. DNS Discovery of a Server . . . . . . . . . . . . . . . . . . 21 9. DNS Discovery of a Server . . . . . . . . . . . . . . . . . . 21
10. Authentication and Message-Integrity Mechanisms . . . . . . . 22 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 . . . . . . . . . . . 23
10.1.2. Receiving a Request or Indication . . . . . . . . . . 23 10.1.2. Receiving a Request or Indication . . . . . . . . . . 23
10.1.3. Receiving a Response . . . . . . . . . . . . . . . . . 24 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 . . . . . . . . . . . . . . . 26
10.2.2. Receiving a Request . . . . . . . . . . . . . . . . . 25 10.2.2. Receiving a Request . . . . . . . . . . . . . . . . . 26
10.2.3. Receiving a Response . . . . . . . . . . . . . . . . . 26 10.2.3. Receiving a Response . . . . . . . . . . . . . . . . . 27
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 . . . . . . . . . . . . . . 29
12.2. Changes to Server Processing . . . . . . . . . . . . . . 29 12.2. Changes to Server Processing . . . . . . . . . . . . . . 29
13. Basic Server Behavior . . . . . . . . . . . . . . . . . . . . 29 13. Basic Server Behavior . . . . . . . . . . . . . . . . . . . . 30
14. STUN Usages . . . . . . . . . . . . . . . . . . . . . . . . . 30 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 . . . . . . . . . . . . . . . . . . . 32 15.2. XOR-MAPPED-ADDRESS . . . . . . . . . . . . . . . . . . . 33
15.3. USERNAME . . . . . . . . . . . . . . . . . . . . . . . . 33 15.3. USERNAME . . . . . . . . . . . . . . . . . . . . . . . . 34
15.4. MESSAGE-INTEGRITY . . . . . . . . . . . . . . . . . . . . 34 15.4. MESSAGE-INTEGRITY . . . . . . . . . . . . . . . . . . . . 34
15.5. FINGERPRINT . . . . . . . . . . . . . . . . . . . . . . . 35 15.5. FINGERPRINT . . . . . . . . . . . . . . . . . . . . . . . 35
15.6. ERROR-CODE . . . . . . . . . . . . . . . . . . . . . . . 35 15.6. ERROR-CODE . . . . . . . . . . . . . . . . . . . . . . . 36
15.7. REALM . . . . . . . . . . . . . . . . . . . . . . . . . . 37 15.7. REALM . . . . . . . . . . . . . . . . . . . . . . . . . . 38
15.8. NONCE . . . . . . . . . . . . . . . . . . . . . . . . . . 37 15.8. NONCE . . . . . . . . . . . . . . . . . . . . . . . . . . 38
15.9. UNKNOWN-ATTRIBUTES . . . . . . . . . . . . . . . . . . . 37 15.9. UNKNOWN-ATTRIBUTES . . . . . . . . . . . . . . . . . . . 38
15.10. SERVER . . . . . . . . . . . . . . . . . . . . . . . . . 38 15.10. SOFTWARE . . . . . . . . . . . . . . . . . . . . . . . . 39
15.11. CLIENT . . . . . . . . . . . . . . . . . . . . . . . . . 38 15.11. ALTERNATE-SERVER . . . . . . . . . . . . . . . . . . . . 39
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 . . . . 42
16.2.4. Attack IV: Eavesdropping . . . . . . . . . . . . . . . 41 16.2.4. Attack IV: Eavesdropping . . . . . . . . . . . . . . . 42
16.3. Hash Agility Plan . . . . . . . . . . . . . . . . . . . . 42 16.3. Hash Agility Plan . . . . . . . . . . . . . . . . . . . . 42
17. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 42 17. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 42
18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
18.1. STUN Methods Registry . . . . . . . . . . . . . . . . . . 42 18.1. STUN Methods Registry . . . . . . . . . . . . . . . . . . 43
18.2. STUN Attribute Registry . . . . . . . . . . . . . . . . . 43 18.2. STUN Attribute Registry . . . . . . . . . . . . . . . . . 43
18.3. STUN Error Code Registry . . . . . . . . . . . . . . . . 44 18.3. STUN Error Code Registry . . . . . . . . . . . . . . . . 44
18.4. STUN UDP and TCP Port Numbers . . . . . . . . . . . . . . 44 18.4. STUN UDP and TCP Port Numbers . . . . . . . . . . . . . . 45
19. Changes Since RFC 3489 . . . . . . . . . . . . . . . . . . . . 44 19. Changes Since RFC 3489 . . . . . . . . . . . . . . . . . . . . 45
20. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 46 20. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 47
21. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 46 21. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 47
22. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46 22. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47
22.1. Normative References . . . . . . . . . . . . . . . . . . 46 22.1. Normative References . . . . . . . . . . . . . . . . . . 47
22.2. Informational References . . . . . . . . . . . . . . . . 47 22.2. Informational References . . . . . . . . . . . . . . . . 48
Appendix A. C Snippet to Determine STUN Message Types . . . . . . 49 Appendix A. C Snippet to Determine STUN Message Types . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49
Intellectual Property and Copyright Statements . . . . . . . . . . 51 Intellectual Property and Copyright Statements . . . . . . . . . . 51
1. Introduction 1. Introduction
The protocol defined in this specification, Session Traversal The protocol defined in this specification, Session Traversal
Utilities for NAT, provides a tool for dealing with NATs. It Utilities for NAT, provides a tool for dealing with NATs. It
provides a means for an endpoint to determine the IP address and port provides a means for an endpoint to determine the IP address and port
allocated by a NAT that corresponds to its private IP address and allocated by a NAT that corresponds to its private IP address and
skipping to change at page 11, line 52 skipping to change at page 11, line 52
that were added in this revised specification. In addition, it aids that were added in this revised specification. In addition, it aids
in distinguishing STUN packets from packets of other protocols when in distinguishing STUN packets from packets of other protocols when
STUN is multiplexed with those other protocols on the same port. STUN is multiplexed with those other protocols on the same port.
The transaction ID is a 96 bit identifier, used to uniquely identify The transaction ID is a 96 bit identifier, used to uniquely identify
STUN transactions. For request/response transactions, the STUN transactions. For request/response transactions, the
transaction ID is chosen by the STUN client for the request and transaction ID is chosen by the STUN client for the request and
echoed by the server in the response. For indications, it is chosen echoed by the server in the response. For indications, it is chosen
by the agent sending the indication. It primarily serves to by the agent sending the indication. It primarily serves to
correlate requests with responses, though it also plays a small role correlate requests with responses, though it also plays a small role
in helping to prevent certain types of attacks. As such, the in helping to prevent certain types of attacks. The server also uses
transaction ID MUST be uniformly and randomly chosen from the the transaction ID as a key to identify each transaction uniquely
interval 0 .. 2**96-1. Resends of the same request reuse the same across all clients. As such, the transaction ID MUST be uniformly
and randomly chosen from the interval 0 .. 2**96-1, and SHOULD be
cryptographically random. Resends of the same request reuse the same
transaction ID, but the client MUST choose a new transaction ID for transaction ID, but the client MUST choose a new transaction ID for
new transactions unless the new request is bit-wise identical to the new transactions unless the new request is bit-wise identical to the
previous request and sent from the same transport address to the same previous request and sent from the same transport address to the same
IP address. Success and error responses MUST carry the same IP address. Success and error responses MUST carry the same
transaction ID as their corresponding request. When an agent is transaction ID as their corresponding request. When an agent is
acting as a STUN server and STUN client on the same port, the acting as a STUN server and STUN client on the same port, the
transaction IDs in requests sent by the agent have no relationship to transaction IDs in requests sent by the agent have no relationship to
the transaction IDs in requests received by the agent. the transaction IDs in requests received by the agent.
The message length MUST contain the size, in bytes, of the message The message length MUST contain the size, in bytes, of the message
skipping to change at page 12, line 47 skipping to change at page 12, line 49
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). In addition, the client SHOULD add a CLIENT attribute (Section 8).
to the message.
If the agent sending a request, it SHOULD add a SOFTWARE attribute to
the request. Agents MAY include a SOFTWARE attribute in indications,
depending on the method. Extensions to STUN should discuss whether
SOFTWARE is useful in new indications.
For the Binding method with no authentication, no attributes are For the Binding method with no authentication, no attributes are
required unless the usage specifies otherwise. required unless the usage specifies otherwise.
All STUN messages sent over UDP SHOULD be less than the path MTU, if All STUN messages sent over UDP SHOULD be less than the path MTU, if
known. If the path MTU is unknown, messages SHOULD be the smaller of known. If the path MTU is unknown, messages SHOULD be the smaller of
576 bytes and the first-hop MTU for IPv4 [RFC1122] and 1280 bytes for 576 bytes and the first-hop MTU for IPv4 [RFC1122] and 1280 bytes for
IPv6 [RFC2460]. This value corresponds to the overall size of the IP IPv6 [RFC2460]. This value corresponds to the overall size of the IP
packet. Consequently, for IPv4, the actual STUN message would need packet. Consequently, for IPv4, the actual STUN message would need
to be less than 548 bytes (576 minus 20 bytes IP header, minus 8 byte to be less than 548 bytes (576 minus 20 bytes IP header, minus 8 byte
skipping to change at page 13, line 37 skipping to change at page 13, line 44
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 or when STUN is run over TCP), a client SHOULD
server by RTO and SHOULD limit itself to ten outstanding transactions space new transactions to a server by RTO and SHOULD limit itself to
to the same server. ten outstanding transactions 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 13 skipping to change at page 14, line 19
interval of RTO ("Retransmission TimeOut"), doubling after each interval of RTO ("Retransmission TimeOut"), doubling after each
retransmission. The RTO is an estimate of the round-trip-time, and retransmission. The RTO is an estimate of the round-trip-time, and
is computed as described in RFC 2988 [RFC2988], with two exceptions. is computed as described in RFC 2988 [RFC2988], with two exceptions.
First, the initial value for RTO SHOULD be configurable (rather than First, the initial value for RTO SHOULD be configurable (rather than
the 3s recommended in RFC 2988) and SHOULD be greater than 500ms. the 3s recommended in RFC 2988) and SHOULD be greater than 500ms.
The exception cases for this SHOULD are when other mechanisms are The exception cases for this SHOULD are when other mechanisms are
used to derive congestion thresholds (such as the ones defined in ICE used to derive congestion thresholds (such as the ones defined in ICE
for fixed rate streams), or when STUN is used in non-Internet for fixed rate streams), or when STUN is used in non-Internet
environments with known network capacities. In fixed-line access environments with known network capacities. In fixed-line access
links, a value of 500ms is RECOMMENDED. Secondly, the value of RTO links, a value of 500ms is RECOMMENDED. Secondly, the value of RTO
MUST NOT be rounded up to the nearest second. Rather, a 1ms accuracy SHOULD NOT be rounded up to the nearest second. Rather, a 1ms
MUST be maintained. As with TCP, the usage of Karn's algorithm is accuracy SHOULD be maintained. As with TCP, the usage of Karn's
RECOMMENDED [KARN87]. When applied to STUN, it means that RTT algorithm is RECOMMENDED [KARN87]. When applied to STUN, it means
estimates SHOULD NOT be computed from STUN transactions which result that RTT estimates SHOULD NOT be computed from STUN transactions
in the retransmission of a request. which result in the retransmission of a request.
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
skipping to change at page 15, line 13 skipping to change at page 15, line 19
application layer messages. The STUN service running on the well application layer messages. The STUN service running on the well
known port or ports discovered through the the DNS procedures in known port or ports discovered through the the DNS procedures in
Section 9 is for STUN alone, and not for STUN multiplexed with other Section 9 is for STUN alone, and not for STUN multiplexed with other
data. Consequently, no framing protocols are used in connections to data. Consequently, no framing protocols are used in connections to
those servers. When additional framing is utilized, the usage will those servers. When additional framing is utilized, the usage will
specify how the client knows to apply it and what port to connect to. specify how the client knows to apply it and what port to connect to.
For example, in the case of ICE connectivity checks, this information For example, in the case of ICE connectivity checks, this information
is learned through out-of-band negotiation between client and server. is learned through out-of-band negotiation between client and server.
When STUN is run by itself over TLS-over-TCP, the When STUN is run by itself over TLS-over-TCP, the
TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be supported at a TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be implemented at a
minimum. Implementations MAY also support any other ciphersuite. minimum. Implementations MAY also support any other ciphersuite.
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
skipping to change at page 17, line 39 skipping to change at page 17, line 45
attribute in the response that lists the unknown comprehension- attribute in the response that lists the unknown comprehension-
required attributes. required attributes.
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, and for an error response with the last 40 seconds,
transaction IDs received over UDP and their corresponding responses the server SHOULD retransmit the same error response. One way for a
in the last 40 seconds. Another way is to reprocess the request and server to do this is to remember all transaction IDs received over
recompute the response. The latter technique MUST only be applied to UDP and their corresponding responses in the last 40 seconds.
requests which are idempotent (a request is considered idempotent Another way is to reprocess the request and recompute the response.
when the same request can be safely repeated without impacting the The latter technique MUST only be applied to requests which are
overall state of the system) and result in the same success response idempotent (a request is considered idempotent when the same request
for the same request. The Binding method is considered to idempotent can be safely repeated without impacting the overall state of the
in this way (even though certain rare network events could cause the system) and result in the same success response for the same request.
reflexive transport address value to change). Extensions to STUN The SHOULD strength requirement for error responses allows servers to
SHOULD state whether their request types have this property or not. avoid storing transaction state for failed non-idempotent requests.
The Binding method is considered to be idempotent. Note that, there
are certain rare network events that could cause the reflexive
transport address value to change, resulting in a different mapped
address in different success responses. Extensions to STUN MUST
discuss the implications of request retransmissions on servers which
do not store transaction state.
7.3.1.1. Forming a Success or Error Response 7.3.1.1. Forming a Success or Error Response
When forming the response (success or error), the server follows the When forming the response (success or error), the server follows the
rules of section 6. The method of the response is the same as that rules of section 6. The method of the response is the same as that
of the request, and the message class is either "Success Response" or of the request, and the message class is either "Success Response" or
"Error Response". "Error Response".
For an error response, the server MUST add an ERROR-CODE attribute For an error response, the server MUST add an ERROR-CODE attribute
containing the error code specified in the processing above. The containing the error code specified in the processing above. The
skipping to change at page 18, line 28 skipping to change at page 18, line 38
420 (Unknown Attribute), the server MUST include an UNKNOWN- 420 (Unknown Attribute), the server MUST include an UNKNOWN-
ATTRIBUTES attribute. Certain authentication errors also cause ATTRIBUTES attribute. Certain authentication errors also cause
attributes to be added (see Section 10). Extensions may define other attributes to be added (see Section 10). Extensions may define other
errors and/or additional attributes to add in error cases. errors and/or additional attributes to add in error cases.
If the server authenticated the request using an authentication If the server authenticated the request using an authentication
mechanism, then the server SHOULD add the appropriate authentication mechanism, then the server SHOULD add the appropriate authentication
attributes to the response (see Section 10). attributes to the response (see Section 10).
The server also adds any attributes required by the specific method The server also adds any attributes required by the specific method
or usage. In addition, the server SHOULD add a SERVER attribute to or usage. In addition, the server SHOULD add a SOFTWARE attribute to
the message. the message.
For the Binding method, no additional checking is required unless the For the Binding method, no additional checking is required unless the
usage specifies otherwise. When forming the success response, the usage specifies otherwise. When forming the success response, the
server adds a XOR-MAPPED-ADDRESS attribute to the response, where the server adds a XOR-MAPPED-ADDRESS attribute to the response, where the
contents of the attribute are the source transport address of the contents of the attribute are the source transport address of the
request message. For UDP, this is the source IP address and source request message. For UDP, this is the source IP address and source
UDP port of the request message. For TCP and TLS-over-TCP, this is UDP port of the request message. For TCP and TLS-over-TCP, this is
the source IP address and source TCP port of the TCP connection as the source IP address and source TCP port of the TCP connection as
seen by the server. seen by the server.
skipping to change at page 25, line 11 skipping to change at page 25, line 21
subsequent requests are not rejected until the nonce becomes invalid subsequent requests are not rejected until the nonce becomes invalid
by the server, in which case the rejection provides a new nonce to by the server, in which case the rejection provides a new nonce to
the client. 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 utilizing indications must either use a short-term credential, or
omit authentication and message integrity for them. omit authentication and message integrity for them.
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 strong passwords. dictionary attacks, deployments SHOULD utilize passwords which are
difficult to guess. In cases where the credentials are not entered
by the user, but are rather placed on a client device during device
provisioning, the password SHOULD have at least 128 bits of
randomness. In cases where the credentials are entered by the user,
they should follow best current practices around password structure.
10.2.1. Forming a Request 10.2.1. Forming a Request
There are two cases when forming a request. In the first case, this There are two cases when forming a request. In the first case, this
is the first request from the client to the server (as identified by is the first request from the client to the server (as identified by
its IP address and port). In the second case, the client is its IP address and port). In the second case, the client is
submitting a subsequent request once a previous request/response submitting a subsequent request once a previous request/response
transaction has completed successfully. Forming a request as a transaction has completed successfully. Forming a request as a
consequence of a 401 or 438 error response is covered in consequence of a 401 or 438 error response is covered in
Section 10.2.3 and is not considered a "subsequent request" and thus Section 10.2.3 and is not considered a "subsequent request" and thus
skipping to change at page 28, line 6 skipping to change at page 28, line 23
message must have passed the authentication checks. message must have passed the authentication checks.
A client using this extension handles a 300 (Try Alternate) error A client using this extension handles a 300 (Try Alternate) error
code as follows. If the error response has passed the authentication code as follows. If the error response has passed the authentication
checks, then the client looks for a ALTERNATE-SERVER attribute in the checks, then the client looks for a ALTERNATE-SERVER attribute in the
error response. If one is found, then the client considers the error response. If one is found, then the client considers the
current transaction as failed, and re-attempts the request with the current transaction as failed, and re-attempts the request with the
server specified in the attribute, using the same transport protocol server specified in the attribute, using the same transport protocol
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 client 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 defines 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
skipping to change at page 38, line 22 skipping to change at page 39, line 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute 3 Type | Attribute 4 Type ... | Attribute 3 Type | Attribute 4 Type ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: 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. SOFTWARE
The server attribute contains a textual description of the software
being used by the server. 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 SERVER 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.11. CLIENT
The client attribute contains a textual description of the software The SOFTWARE attribute contains a textual description of the software
being used by the client. This SHOULD include manufacturer and being used by the agent sending the message. It is used by clients
version number. The attribute has no impact on operation of the and servers. Its value SHOULD include manufacturer and version
protocol, and serves only as a tool for diagnostic and debugging number. The attribute has no impact on operation of the protocol,
purposes. The value of CLIENT is variable length. It MUST be a and serves only as a tool for diagnostic and debugging purposes. The
UTF-8 [RFC3629] encoded sequence of less than 128 characters (which value of SOFTWARE is variable length. It MUST be a UTF-8 [RFC3629]
can be as long as 763 bytes). encoded sequence of less than 128 characters (which can be as long as
763 bytes).
15.12. ALTERNATE-SERVER 15.11. 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 21 skipping to change at page 40, line 39
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 Revealing the specific software version of the agent through the
through the SERVER and CLIENT attributes might allow them to become SOFTWARE attribute might allow them to become more vulnerable to
more vulnerable to attacks against software that is known to contain attacks against software that is known to contain security holes.
security holes. Implementers SHOULD make the CLIENT and SERVER Implementers SHOULD make usage of the SOFTWARE attribute a
attributes a configurable option. 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
skipping to change at page 42, line 22 skipping to change at page 42, line 40
We will define a STUN extension which introduces a new message We will define a STUN extension which introduces a new message
integrity attribute, computed using a new hash. Clients would be integrity attribute, computed using a new hash. Clients would be
required to include both the new and old message integrity attributes required to include both the new and old message integrity attributes
in their requests or indications. A new server will utilize the new in their requests or indications. A new server will utilize the new
message integrity attribute, and an old one, the old. After a message integrity attribute, and an old one, the old. After a
transition period where mixed implementations are in deployment, the transition period where mixed implementations are in deployment, the
old message-integrity attribute will be deprecated by another old message-integrity attribute will be deprecated by another
specification, and clients will cease including it in requests. specification, and clients will cease including it in requests.
It is also important to note that the HMAC is done using a key which
is itself computed using an MD5 of the user's password. The choice
of the MD5 hash was made because of the existence of legacy databases
which store passwords in that form. If future work finds that an
HMAC of an MD5 input is not secure, and a different hash is needed,
it can also be changed using this plan. However, this would require
administrators to repopulate their databases.
17. IAB Considerations 17. 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
[RFC3424]). STUN can be used to perform this function using a [RFC3424]). STUN can be used to perform this function using a
Binding Request/Response transaction if one agent is behind a NAT and Binding Request/Response transaction if one agent is behind a NAT and
the other is on the public side of the NAT. the other is on the public side of the NAT.
skipping to change at page 43, line 44 skipping to change at page 44, line 24
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) 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: SOFTWARE
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 Review optional range (0x8000 - 0xBFFF) are assigned by IETF Review
[RFC5226]. 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 by of the comprehension-optional range (0xC000 - 0xFFFF) are assigned by
Designated Expert [RFC5226]. The responsibility of the expert is to Designated Expert [RFC5226]. The responsibility of the expert is to
verify that the selected codepoint(s) are not in use, and that the verify that the selected codepoint(s) are not in use, and that the
request is not for an abnormally large number of codepoints. request is not for an abnormally large number of codepoints.
skipping to change at page 45, line 48 skipping to change at page 46, line 26
o Added the FINGERPRINT attribute to provide a method of definitely o Added the FINGERPRINT attribute to provide a method of definitely
detecting the difference between STUN and another protocol when detecting the difference between STUN and another protocol when
the two protocols are multiplexed together. the two protocols are multiplexed together.
o Added support for IPv6. Made it clear that an IPv4 client could o Added support for IPv6. Made it clear that an IPv4 client could
get a v6 mapped address, and vice-a-versa. get a v6 mapped address, and vice-a-versa.
o Added long-term credential-based authentication. o Added long-term credential-based authentication.
o Added the SERVER, REALM, NONCE, and ALTERNATE-SERVER attributes. o Added the SOFTWARE, REALM, NONCE, and ALTERNATE-SERVER attributes.
o Removed the SharedSecret method, and thus the PASSWORD attribute. o Removed the SharedSecret method, and thus the PASSWORD attribute.
This method was almost never implemented and is not needed with This method was almost never implemented and is not needed with
current usages. current usages.
o Removed recommendation to continue listening for STUN Responses o Removed recommendation to continue listening for STUN Responses
for 10 seconds in an attempt to recognize an attack. for 10 seconds in an attempt to recognize an attack.
o Changed transaction timers to be more TCP friendly. o Changed transaction timers to be more TCP friendly.
skipping to change at page 48, line 23 skipping to change at page 48, line 49
[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
"STUN - Simple Traversal of User Datagram Protocol (UDP) "STUN - Simple Traversal of User Datagram Protocol (UDP)
Through Network Address Translators (NATs)", RFC 3489, Through Network Address Translators (NATs)", RFC 3489,
March 2003. March 2003.
[I-D.ietf-behave-turn] [I-D.ietf-behave-turn]
Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)", Traversal Utilities for NAT (STUN)",
draft-ietf-behave-turn-06 (work in progress), draft-ietf-behave-turn-08 (work in progress), June 2008.
January 2008.
[I-D.ietf-sip-outbound] [I-D.ietf-sip-outbound]
Jennings, C. and R. Mahy, "Managing Client Initiated Jennings, C. and R. Mahy, "Managing Client Initiated
Connections in the Session Initiation Protocol (SIP)", Connections in the Session Initiation Protocol (SIP)",
draft-ietf-sip-outbound-11 (work in progress), draft-ietf-sip-outbound-15 (work in progress), June 2008.
November 2007.
[I-D.ietf-behave-nat-behavior-discovery] [I-D.ietf-behave-nat-behavior-discovery]
MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery
Using STUN", draft-ietf-behave-nat-behavior-discovery-02 Using STUN", draft-ietf-behave-nat-behavior-discovery-03
(work in progress), November 2007. (work in progress), February 2008.
[I-D.ietf-mmusic-ice-tcp] [I-D.ietf-mmusic-ice-tcp]
Rosenberg, J., "TCP Candidates with Interactive Rosenberg, J., "TCP Candidates with Interactive
Connectivity Establishment (ICE)", Connectivity Establishment (ICE)",
draft-ietf-mmusic-ice-tcp-05 (work in progress), draft-ietf-mmusic-ice-tcp-06 (work in progress),
November 2007. February 2008.
[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.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
 End of changes. 36 change blocks. 
95 lines changed or deleted 107 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/