idnits 2.17.1 draft-ietf-aft-socks-multiple-traversal-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-29) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 4 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction 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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 118: '...o express that the client MUST connect...' RFC 2119 keyword, line 127: '...otiation packets MUST be encapsulated ...' 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 (21 November 1997) is 9625 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 166, but no explicit reference was found in the text Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT M. Kayashima 3 M. Terada 4 Expires in six months T. Fujiyama 5 T. Ogino 6 Hitachi Ltd. 7 21 November 1997 9 SOCKS V5 Protocol extension for Multiple Firewalls Traversal 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet- Drafts as reference 21 material or to cite them other than as "work in progress." 23 To view the entire list of current Internet-Drafts, please check the 24 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 25 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), 26 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 27 ftp.isi.edu (US West Coast). 29 Abstract 31 This document provides the extended specification of SOCKS Version 5 32 which enable to use multiple firewalls traversal. In this protocol, 33 client does subnegotiation with all servers on the communication 34 path, and each server relays the connection after subnegotiation. 36 Propose 38 The network firewalls are currently being used for corporate 39 networks, but there is a need to provide access control for 40 departments in organizations as shown below. 42 Internet +-Corporate Network--------+ 43 | +-Dept. 1------+ | 44 +----+ +--+--+ +--+--+ +----+ | | 45 | C1 | | gw1 | | gw2 | | S1 | | | 46 +----+ +--+--+ +--+--+ +----+ | | 47 | +--------------+ | 48 | | 49 | +-Depart. 2----+ | 51 Internet DRAFT 13 Nov 1997 53 | +--+--+ +----+ | | 54 | | gw3 | | S2 | | | 55 | +--+--+ +----+ | | 56 | +--------------+ | 57 +--------------------------+ 59 The department firewalls, gw2 and gw3 are used for a fail safe system 60 against intruders on the Internet, and they are used to provide 61 access control for other departments members. 63 In this environment, the connection from the Internet client to 64 department servers must traverses multiple firewalls. And the client 65 authentication with each firewall may be used different method. For 66 example, a firewall which protects corporate network needs strong 67 authentication, because it is a gate of the Internet. But a firewall 68 which protects department network uses more weak and convenient 69 authentication method such as username/password. 71 Procedure for TCP-based client 73 This extended protocol is used for TCP-based clinets. When a TCP- 74 based client wishes to establish a connection to an object that is 75 reachable only via multiple firewalls which are located like a 76 cascade. 78 In the SOCKS V5 protocol, the sequence between SOCKS client and SOCKS 79 server is followed: 81 (1) Method specific subnegotiation 82 (2) Request Command 83 (3) Reply 85 In the extended protocol, client repeats these sequence with all 86 SOCKS server which is located on the route of server. Method 87 specific subnegotiation and Request Command is not extended from 88 SOCKS V5 protocol. 90 To recognize the end of repeat, Reply packet is extended as follows: 92 +---+---+------+------+---------+---------+---------+---------+ 93 |VER|REP| RSV |ATYPE |BND.ADDR |BND.PORT |NXT.ADDR |NXT.PORT | 94 +---+---+------+------+---------+---------+---------+---------+ 95 | 1 | 1 |X'00' | 1 |Variable | 2 |Variable | 2 | 96 +---+---+------+------+---------+---------+---------+---------+ 98 This packet format has two new fields; NXT.ADDR and NXT.PORT. 100 Where: 102 Internet DRAFT 13 Nov 1997 104 o REP Reply field: 105 The reply code is extended with multiple firewalls traversal. 106 o X'09' Connect next-hop SOCKS server 107 o NXT.ADDR Next-hop SOCKS server address 108 o NXT.PORT Next-hop SOCKS server port 110 The NXT.ADDR is next-hop SOCKS server address. The NXT.PORT is a port 111 which is used at next-hop SOCKS server. If destination host is 112 behind other SOCKS servers, the SOCKS server selects next-hop SOCKS 113 server, which is located at the route of client and destination host, 114 and can be connected to it. If SOCKS server can connect destination 115 host directly, NXT.ADDR field and NXT.PORT field set to X'00'. 117 The reply code in REP field is extended for multiple firewalls 118 traversal. X'09' is new value to express that the client MUST connect 119 next-hop SOCKS server. 121 When the client receives this REP code, the client starts same 122 sequence with next-hop SOCKS server. This sequence repeated while 123 the client receives the reply code of X'09'. 125 If each subnegotiation method includes encapsulation for purposes of 126 integrity checking and/or confidentiality, following request/reply 127 packet and next subnegotiation packets MUST be encapsulated in the 128 method dependent encapsulation. Each SOCKS server encapsulates 129 request/reply packet for itself and subnegitiation packets for next 130 hop SOCKS server. Other packets are relaied by SOCKS server without 131 encapsulation. 133 Connection setup sequence 135 This section provides an example of connection setup sequence when 136 the Internet client C1 establishes a connection with department 137 server S1 via corporate firewall gw1 and the department firewall gw2. 139 (1) Sequence with gw1 140 o C1 connects to gw1. 141 o C1 does subnegotiation with gw1 directly. 142 o C1 sends Request to gw1. 143 o gw1 search destination. If gw1 is reachable the 144 destination server, then gw1 send Reply to C1. 146 (2) Sequence with gw2 147 o gw1 connects to gw2. 148 o C1 does subnegotiation with gw2. This sequence is relayed by gw1. 149 o C1 sends Request to gw2. 151 Internet DRAFT 13 Nov 1997 153 o gw2 search destination. If gw1 is reachable the destination 154 server, then gw2 send Reply to C1. 156 Security Considerations 158 This document describes a protocol for the multiple traversal of 159 application layer firewalls. The security of such traversal is highly 160 dependent on the particular authentication and encapsulation methods 161 provided in a particular implementation, and selected during 162 negotiation between SOCKS client and each SOCKS server. 164 References 166 [RFC 1928] Leech, M., Ganis, M., Lee, Y., Kuris, R. Koblas, D., & 167 Jones, L., "SOCKS Protocol V5," April 1996. 169 Author's Address 171 Makoto Kayashima 172 Hitachi Ltd. Systems Development Laboratory 173 292 Yoshida-cho, Totsuka, Yokohama, Kanagawa 244, Japan 174 kayashi@sdl.hitachi.co.jp 176 Masato Terada 177 Hitachi Ltd. Systems Development Laboratory 178 292 Yoshida-cho, Totsuka, Yokohama, Kanagawa 244, Japan 179 terada@sdl.hitachi.co.jp