idnits 2.17.1 draft-ietf-aft-socks-v6-req-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 3 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 1, 1999) is 9003 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC 1928' is defined on line 114, but no explicit reference was found in the text Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 AFT Working Group Marc VanHeyningen 2 draft-ietf-aft-socks-v6-req-00.txt Aventail Corp. 3 Expires six months from --> September 1, 1999 5 SOCKS successor requirements 7 Status of this Memo 9 This document is an Internet-Draft and is in full conformance with 10 all provisions of Section 10 of RFC2026. 12 Internet-Drafts are working documents of the Internet Engineering 13 Task Force (IETF), its areas, and its working groups. Note that 14 other groups may also distribute working documents as Internet- 15 Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other 19 documents at any time. It is inappropriate to use Internet- 20 Drafts as reference material or to cite them other than as "work 21 in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This document is a submission to the IETF Authenticated Firewall 30 Traversal (AFT) Working Group. Comments are solicited and should 31 be addressed to the working group mailing list (aft@socks.nec.com) 32 or to the editor. 34 Abstract 36 The SOCKS protocol version 5 has been deployed and seen use as a 37 mechanism for authenticated firewall traversal. Experience with 38 the use of this protocol and its limitations has led to the desire 39 for a new firewall traversal protocol; we tentatively name this 40 new protocol SOCKS version 6. 42 1. Introduction 44 SOCKS5 has enjoyed wide use in a variety of network environments as a 45 protocol for traversing trust boundaries in heterogenous network 46 environments. Its support for various authentication methods, 47 specification of destinations by name rather than by IP address, and 48 UDP proxy support have provided much benefit; however, there are new 49 features required, and the existing protocol was not designed to be 50 sufficiently extensible such that an easy retrofit is possible. 52 Proposed here is a set of new top-level requirements for the protocol 53 as a whole, along with a set of specific new functionality desired in 54 this new version. As a base requirement, SOCKS v6 should be able to 55 do everything currently done by compliant SOCKS v5 implementations. 57 2. General protocol features 59 Experience with SOCKS5 has indicated some fundamental aspects of the 60 protocol which do not provide the level of flexibilty desired for 61 wide use and enhancement. Thus, the successor should minimally 62 include: 64 o Major and minor version numbers, to allow for revisions which do 65 not break backward compatibility 66 o A general mechanism for negotiating the support of new 67 protocol features. 68 o Authentication methods (and, if possible, the authentication 69 framework) should leverage existing standards rather than re-invent 70 them. 71 o A "control channel" may exist which allows multiple proxy 72 operations to be conducted without incurring the overhead of 73 re-authentication. This control flow should persist throughout 74 the lifetime of the connection(s). 76 3. TCP-BIND features 78 The BIND command as defined in SOCKS5 is designed primarily for cases 79 in which a server must make a "back-connect" to a client, as is the 80 case in FTP. For this purpose the command as defined is sufficient; 81 however, there are protocols which require multiple back-connects to 82 a single listening address/port, and some require a specific port be 83 used when accepting this connection. 85 The TCP BIND functionality shall include: 87 o The ability to support multiple connections, not just one, to 88 the proxy's listening port 89 o The ability of the client to request a specific port be used 90 by the server when listening on its behalf 92 4. UDP-BIND features 94 UDP was a new feature for SOCKS v5, and the initial support was very 95 limited in its capabilities. The model envisioned was that of 96 applications like archie; a client sending data and a response being 97 received. Many UDP applications have different requirements, such as 98 receiving UDP data without sending any, using a specific port, and 99 requiring IP address information. 101 The UDP BIND functionality shall include: 103 o The ability to establish the connection and receive address 104 information about the proxy via a reliable channel 105 o The ability to send or receive UDP first 106 o The ability for the client to control the port used on its behalf 107 o Support for sending and receiving multicast UDP traffic, in a 108 multicast or non-multicast environment. 109 o Support for tunneling UDP inside a reliable channel, at a 110 performance penalty, if needed. 112 5. References 114 [RFC 1928] Leech, M., Ganis, M., Lee, Y., Kuris, R. Koblas, D., & 115 Jones, L., "SOCKS Protocol V5," April 1996. 117 Author's Address 119 Marc VanHeyningen 120 Aventail Corporation 121 808 Howell Streeet; Suite 200 122 Seattle, WA 98101 124 Phone: +1 (206) 215-1111 125 Email: marcvh@aventail.com