--- 1/draft-ietf-behave-rfc3489bis-05.txt 2007-03-08 23:12:21.000000000 +0100 +++ 2/draft-ietf-behave-rfc3489bis-06.txt 2007-03-08 23:12:21.000000000 +0100 @@ -1,23 +1,23 @@ BEHAVE J. Rosenberg -Internet-Draft Cisco Systems -Expires: April 26, 2007 C. Huitema - Microsoft - R. Mahy +Internet-Draft Cisco +Obsoletes: 3489 (if approved) C. Huitema +Intended status: Standards Track Microsoft +Expires: September 6, 2007 R. Mahy Plantronics D. Wing Cisco Systems - October 23, 2006 + March 5, 2007 - Simple Traversal Underneath Network Address Translators (NAT) (STUN) - draft-ietf-behave-rfc3489bis-05 + Session Traversal Utilities for (NAT) (STUN) + draft-ietf-behave-rfc3489bis-06 Status of this Memo By submitting this Internet-Draft, each author represents that any 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 aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -28,29 +28,29 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on April 26, 2007. + This Internet-Draft will expire on September 6, 2007. Copyright Notice - Copyright (C) The Internet Society (2006). + Copyright (C) The IETF Trust (2007). Abstract - Simple Traversal Underneath NATs (STUN) is a lightweight protocol + Session Traversal Utilities for NAT (STUN) is a lightweight protocol that serves as a tool for application protocols in dealing with NAT traversal. It allows a client to determine the IP address and port allocated to them by a NAT and to keep NAT bindings open. It can also serve as a check for connectivity between a client and a server in the presence of NAT, and for the client to detect failure of the server. STUN works with many existing NATs, and does not require any special behavior from them. As a result, it allows a wide variety of applications to work through existing NAT infrastructure. Table of Contents @@ -102,65 +102,65 @@ 12.1.5. New Attributes . . . . . . . . . . . . . . . . . . . . 38 12.1.6. New Error Response Codes . . . . . . . . . . . . . . . 38 12.1.7. Client Procedures . . . . . . . . . . . . . . . . . . 38 12.1.8. Server Procedures . . . . . . . . . . . . . . . . . . 38 12.1.9. Security Considerations for Binding Discovery . . . . 38 12.2. NAT Keepalives . . . . . . . . . . . . . . . . . . . . . 39 12.2.1. Applicability . . . . . . . . . . . . . . . . . . . . 39 12.2.2. Client Discovery of Server . . . . . . . . . . . . . . 39 12.2.3. Server Determination of Usage . . . . . . . . . . . . 39 12.2.4. New Requests or Indications . . . . . . . . . . . . . 39 - 12.2.5. New Attributes . . . . . . . . . . . . . . . . . . . . 39 + 12.2.5. New Attributes . . . . . . . . . . . . . . . . . . . . 40 12.2.6. New Error Response Codes . . . . . . . . . . . . . . . 40 12.2.7. Client Procedures . . . . . . . . . . . . . . . . . . 40 12.2.8. Server Procedures . . . . . . . . . . . . . . . . . . 40 12.2.9. Security Considerations for NAT Keepalives . . . . . . 40 12.3. Short-Term Password . . . . . . . . . . . . . . . . . . . 41 12.3.1. Applicability . . . . . . . . . . . . . . . . . . . . 41 12.3.2. Client Discovery of Server . . . . . . . . . . . . . . 41 - 12.3.3. Server Determination of Usage . . . . . . . . . . . . 41 + 12.3.3. Server Determination of Usage . . . . . . . . . . . . 42 12.3.4. New Requests or Indications . . . . . . . . . . . . . 42 - 12.3.5. New Attributes . . . . . . . . . . . . . . . . . . . . 42 - 12.3.6. New Error Response Codes . . . . . . . . . . . . . . . 42 + 12.3.5. New Attributes . . . . . . . . . . . . . . . . . . . . 43 + 12.3.6. New Error Response Codes . . . . . . . . . . . . . . . 43 12.3.7. Client Procedures . . . . . . . . . . . . . . . . . . 43 12.3.8. Server Procedures . . . . . . . . . . . . . . . . . . 43 12.3.9. Security Considerations for Short-Term Password . . . 44 13. Security Considerations . . . . . . . . . . . . . . . . . . . 45 13.1. Attacks on STUN . . . . . . . . . . . . . . . . . . . . . 45 - 13.1.1. Attack I: DDoS Against a Target . . . . . . . . . . . 45 + 13.1.1. Attack I: DDoS Against a Target . . . . . . . . . . . 46 13.1.2. Attack II: Silencing a Client . . . . . . . . . . . . 46 13.1.3. Attack III: Assuming the Identity of a Client . . . . 46 13.1.4. Attack IV: Eavesdropping . . . . . . . . . . . . . . . 46 - 13.2. Launching the Attacks . . . . . . . . . . . . . . . . . . 46 + 13.2. Launching the Attacks . . . . . . . . . . . . . . . . . . 47 13.2.1. Approach I: Compromise a Legitimate STUN Server . . . 47 13.2.2. Approach II: DNS Attacks . . . . . . . . . . . . . . . 47 - 13.2.3. Approach III: Rogue Router or NAT . . . . . . . . . . 47 + 13.2.3. Approach III: Rogue Router or NAT . . . . . . . . . . 48 13.2.4. Approach IV: Man in the Middle . . . . . . . . . . . . 48 - 13.2.5. Approach V: Response Injection Plus DoS . . . . . . . 48 + 13.2.5. Approach V: Response Injection Plus DoS . . . . . . . 49 13.2.6. Approach VI: Duplication . . . . . . . . . . . . . . . 49 13.3. Countermeasures . . . . . . . . . . . . . . . . . . . . . 50 13.4. Residual Threats . . . . . . . . . . . . . . . . . . . . 51 14. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 51 - 14.1. Problem Definition . . . . . . . . . . . . . . . . . . . 51 + 14.1. Problem Definition . . . . . . . . . . . . . . . . . . . 52 14.2. Exit Strategy . . . . . . . . . . . . . . . . . . . . . . 52 14.3. Brittleness Introduced by STUN . . . . . . . . . . . . . 52 - 14.4. Requirements for a Long Term Solution . . . . . . . . . . 53 - 14.5. Issues with Existing NAPT Boxes . . . . . . . . . . . . . 54 + 14.4. Requirements for a Long Term Solution . . . . . . . . . . 54 + 14.5. Issues with Existing NAPT Boxes . . . . . . . . . . . . . 55 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55 15.1. STUN Methods Registry . . . . . . . . . . . . . . . . . . 55 15.2. STUN Attribute Registry . . . . . . . . . . . . . . . . . 55 16. Changes Since RFC 3489 . . . . . . . . . . . . . . . . . . . . 56 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 57 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 57 18.1. Normative References . . . . . . . . . . . . . . . . . . 57 18.2. Informational References . . . . . . . . . . . . . . . . 58 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 60 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 59 Intellectual Property and Copyright Statements . . . . . . . . . . 61 1. Applicability Statement This protocol is not a cure-all for the problems associated with NAT. It is a tool that is typically used in conjunction with other protocols, such as Interactive Connectivity Establishment (ICE) [13] for a more complete solution. The binding discovery usage, defined by this specification, can be used by itself with numerous application protocols as a solution for NAT traversal. However, when @@ -213,47 +213,47 @@ the message. ALGs have serious limitations, including scalability, reliability, and speed of deploying new applications. Many existing proprietary protocols, such as those for online games (such as the games described in RFC3027 [21]) and Voice over IP, have developed tricks that allow them to operate through NATs without changing those NATs and without relying on ALG behavior in the NATs. This document takes some of those ideas and codifies them into an interoperable protocol that can meet the needs of many applications. - The protocol described here, Simple Traversal Underneath NAT (STUN), - provides a toolkit of functions. These functions allow entities - behind a NAT to learn the address bindings allocated by the NAT and - to keep those bindings open. STUN requires no changes to NATs and - works with an arbitrary number of NATs in tandem between the + The protocol described here, Session Traversal Utilities for NAT + (STUN), provides a toolkit of functions. These functions allow + entities behind a NAT to learn the address bindings allocated by the + NAT and to keep those bindings open. STUN requires no changes to + NATs and works with an arbitrary number of NATs in tandem between the application entity and the public Internet. 3. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [1] and indicate requirement levels for compliant STUN implementations. 4. Definitions STUN Client: A STUN client (also just referred to as a client) is an entity that generates STUN requests and receives STUN responses. Clients can also generate STUN indications. STUN Server: A STUN Server (also just referred to as a server) is an entity that receives STUN requests and sends STUN responses. Servers also send STUN indications. - Transport Address: The combination of an IP address and (UDP or TCP) - port. + Transport Address: The combination of an IP address and transport + protocol (such as UDP or TCP) port. Reflexive Transport Address: A transport address learned by a client that identifies that client as seen by another host on an IP network, typically a STUN server. When there is an intervening NAT between the client and the other host, the reflexive transport address represents the binding allocated to the client on the public side of the NAT. Reflexive transport addresses are learned from the mapped address attribute (MAPPED-ADDRESS or XOR-MAPPED- ADDRESS) in STUN responses. @@ -491,21 +491,21 @@ The most significant two bits of every STUN message are both zeroes. This, combined with the magic cookie and the fingerprint attribute, aid in differentiating STUN packets from other protocols when STUN is multiplexed with other protocols on the same port. The message type field is decomposed further into the following structure: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|M|M|M|M|C|M|M|M|C|M|M|M|M| - |1|1|9|8|7|1|6|5|4|0|3|2|2|0| + |1|1|9|8|7|1|6|5|4|0|3|2|1|0| |1|0| | | | | | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Format of STUN Message Type Field M11 through M0 represent a 12-bit encoding of the method. C1 through C0 represent a 2 bit encoding of the class. A class of 0 is a Request, a class of 1 is an indication, a class of 2 is a success response, and a class of 3 is an error response. This specification defines two methods, Binding and Shared Secret. Their method values @@ -795,22 +795,24 @@ equal to 0x2112A442), the FINGERPRINT attribute MUST be present. Otherwise, its inclusion is RECOMMENDED. Next, the client sends the request. For UDP-based requests, reliability is accomplished through client retransmissions, following the procedure in Section 7.1. For TCP (including TLS over TCP), there are no retransmissions. For TCP and TLS over TCP, the client MAY send multiple requests on the connection. When using TCP or TLS over TCP, the client SHOULD - close the connection as soon as it has received the STUN Response, if - it has no plans to send further requests. + keep the connection open until it has no further requests to send, + and has no plans to use any resources (such as a mapped address or + relayed address [16]) learned though STUN requests sent over that + connection. Regardless of the transport protocol, a client MAY pipeline requests (that is, it can have multiple requests outstanding at the same time). 8.3.2. Processing Responses Once the client has received a response to its request that it did not discard, it MUST discard any further responses for the same request. @@ -2635,34 +2636,35 @@ Mankin, Eric Rescorla, and Henning Schulzrinne for IESG and IAB input on this work. 18. References 18.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. - [2] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. + [2] Postel, J., "Internet Protocol", STD 5, RFC 791, + September 1981. [3] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [4] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [5] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. - [6] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating - Denial of Service Attacks which employ IP Source Address - Spoofing", BCP 38, RFC 2827, May 2000. + [6] Ferguson, P. and D. Senie, "Network Ingress Filtering: + Defeating Denial of Service Attacks which employ IP Source + Address Spoofing", BCP 38, RFC 2827, May 2000. [7] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. [8] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000. [9] International Telecommunications Union, "Error-correcting Procedures for DCEs Using Asynchronous-to-Synchronous @@ -2676,42 +2678,42 @@ [11] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [12] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [13] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for - Offer/Answer Protocols", draft-ietf-mmusic-ice-11 (work in - progress), October 2006. + Offer/Answer Protocols", draft-ietf-mmusic-ice-13 (work in + progress), January 2007. [14] Audet, F. and C. Jennings, "NAT Behavioral Requirements for Unicast UDP", draft-ietf-behave-nat-udp-08 (work in progress), October 2006. [15] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003. [16] Rosenberg, J., "Obtaining Relay Addresses from Simple Traversal Underneath NAT (STUN)", draft-ietf-behave-turn-02 (work in progress), October 2006. [17] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, July 2003. [18] Jennings, C. and R. Mahy, "Managing Client Initiated Connections in the Session Initiation Protocol (SIP)", - draft-ietf-sip-outbound-04 (work in progress), June 2006. + draft-ietf-sip-outbound-07 (work in progress), January 2007. [19] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. [20] Senie, D., "Network Address Translator (NAT)-Friendly Application Design Guidelines", RFC 3235, January 2002. [21] Holdrege, M. and P. Srisuresh, "Protocol Complications with the IP Network Address Translator", RFC 3027, January 2001. @@ -2726,26 +2728,24 @@ Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002. [25] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. Authors' Addresses Jonathan Rosenberg - Cisco Systems - 600 Lanidex Plaza - Parsippany, NJ 07054 + Cisco + Edison, NJ US - Phone: +1 973 952-5000 Email: jdrosen@cisco.com URI: http://www.jdrosen.net Christian Huitema Microsoft One Microsoft Way Redmond, WA 98052 US Email: huitema@microsoft.com @@ -2759,21 +2758,37 @@ Email: rohan@ekabal.com Dan Wing Cisco Systems 771 Alder Drive San Jose, CA 95035 US Email: dwing@cisco.com -Intellectual Property Statement +Full Copyright Statement + + Copyright (C) The IETF Trust (2007). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS + OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. @@ -2783,30 +2798,14 @@ such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Copyright Statement - - Copyright (C) The Internet Society (2006). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - Acknowledgment - Funding for the RFC Editor function is currently provided by the - Internet Society. + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA).