STUND-STUND的C++实现

Network Working Group J. Rosenberg Request for Comments: 3489 J. Weinberger Category: Standards Track dynamicsoft C. Huitema Microsoft R. Mahy Cisco March 2003 STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs) Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs) (STUN) is a lightweight protocol that allows applications to discover the presence and types of NATs and firewalls between them and the public Internet. It also provides the ability for applications to determine the public Internet Protocol (IP) addresses allocated to them by the NAT. 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 1. Applicability Statement ................................... 3 2. Introduction .............................................. 3 3. Terminology ............................................... 4 4. Definitions ............................................... 5 5. NAT Variations ............................................ 5 6. Overview of Operation ..................................... 6 7. Message Overview .......................................... 8 8. Server Behavior ........................................... 10 8.1 Binding Requests .................................... 10 Rosenberg, et al. Standards Track [Page 1]  RFC 3489 STUN March 2003 8.2 Shared Secret Requests .............................. 13 9. Client Behavior ........................................... 14 9.1 Discovery ........................................... 15 9.2 Obtaining a Shared Secret ........................... 15 9.3 Formulating the Binding Request ..................... 17 9.4 Processing Binding Responses ........................ 17 10. Use Cases ................................................. 19 10.1 Discovery Process ................................... 19 10.2 Binding Lifetime Discovery .......................... 21 10.3 Binding Acquisition ................................. 23 11. Protocol Details .......................................... 24 11.1 Message Header ...................................... 25 11.2 Message Attributes .................................. 26 11.2.1 MAPPED-ADDRESS .............................. 27 11.2.2 RESPONSE-ADDRESS ............................ 27 11.2.3 CHANGED-ADDRESS ............................. 28 11.2.4 CHANGE-REQUEST .............................. 28 11.2.5 SOURCE-ADDRESS .............................. 28 11.2.6 USERNAME .................................... 28 11.2.7 PASSWORD .................................... 29 11.2.8 MESSAGE-INTEGRITY ........................... 29 11.2.9 ERROR-CODE .................................. 29 11.2.10 UNKNOWN-ATTRIBUTES .......................... 31 11.2.11 REFLECTED-FROM .............................. 31 12. Security Considerations ................................... 31 12.1 Attacks on STUN ..................................... 31 12.1.1 Attack I: DDOS Against a Target ............. 32 12.1.2 Attack II: Silencing a Client ............... 32 12.1.3 Attack III: Assuming the Identity of a Client 32 12.1.4 Attack IV: Eavesdropping .................... 33 12.2 Launching the Attacks ............................... 33 12.2.1 Approach I: Compromise a Legitimate STUN Server ................................. 33 12.2.2 Approach II: DNS Attacks .................... 34 12.2.3 Approach III: Rogue Router or NAT ........... 34 12.2.4 Approach IV: MITM ........................... 35 12.2.5 Approach V: Response Injection Plus DoS ..... 35 12.2.6 Approach VI: Duplication .................... 35 12.3 Countermeasures ..................................... 36 12.4 Residual Threats .................................... 37 13. IANA Considerations ....................................... 38 14. IAB Considerations ........................................ 38 14.1 Problem Definition .................................. 38 14.2 Exit Strategy ....................................... 39 14.3 Brittleness Introduced by STUN ...................... 40 14.4 Requirements for a Long Term Solution ............... 42 14.5 Issues with Existing NAPT Boxes ..................... 43 14.6 In Closing .......................................... 43 Rosenberg, et al. Standards Track [Page 2]  RFC 3489 STUN March 2003 15. Acknowledgments ........................................... 44 16. Normative References ...................................... 44 17. Informative References .................................... 44 18. Authors' Addresses ........................................ 46 19. Full Copyright Statement................................... 47 1. Applicability Statement This protocol is not a cure-all for the problems associated with NAT. It does not enable incoming TCP connections through NAT. It allows incoming UDP packets through NAT, but only through a subset of existing NAT types. In particular, STUN does not enable incoming UDP packets through symmetric NATs (defined below), which are common in large enterprises. STUN's discovery procedures are based on assumptions on NAT treatment of UDP; such assumptions may prove invalid down the road as new NAT devices are deployed. STUN does not work when it is used to obtain an address to communicate with a peer which happens to be behind the same NAT. STUN does not work when the STUN server is not in a common shared address realm. For a more complete discussion of the limitations of STUN, see Section 14. 2. Introduction Network Address Translators (NATs), while providing many benefits, also come with many drawbacks. The most troublesome of those drawbacks is the fact that they break many existing IP applications, and make it difficult to deploy new ones. Guidelines have been developed [8] that describe how to build "NAT friendly" protocols, but many protocols simply cannot be constructed according to those guidelines. Examples of such protocols include almost all peer-to- peer pr