[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00

INTERNET-DRAFT                                          M. Kayashima
<draft-ietf-aft-socks-multiple-traversal-00.txt>        M. Terada
Expires in six months                                   T. Fujiyama
                                                        T. Ogino
                                                        Hitachi Ltd.
                                                        21 November 1997

      SOCKS V5 Protocol extension for Multiple Firewalls Traversal

Status of this Memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   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."

   To view the entire list of current Internet-Drafts, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).

Abstract

   This document provides the extended specification of SOCKS Version 5
   which enable to use multiple firewalls traversal.  In this protocol,
   client does subnegotiation with all servers on the communication
   path, and each server relays the connection after subnegotiation.

Propose

   The network firewalls are currently being used for corporate
   networks, but there is a need to provide access control for
   departments in organizations as shown below.

           Internet          +-Corporate Network--------+
                             |         +-Dept. 1------+ |
           +----+         +--+--+   +--+--+    +----+ | |
           | C1 |         | gw1 |   | gw2 |    | S1 | | |
           +----+         +--+--+   +--+--+    +----+ | |
                             |         +--------------+ |
                             |                          |
                             |         +-Depart. 2----+ |



Kayashima                                                       [Page 1]


Internet DRAFT                                               13 Nov 1997


                             |      +--+--+    +----+ | |
                             |      | gw3 |    | S2 | | |
                             |      +--+--+    +----+ | |
                             |         +--------------+ |
                             +--------------------------+

   The department firewalls, gw2 and gw3 are used for a fail safe system
   against intruders on the Internet, and they are used to provide
   access control for other departments members.

   In this environment, the connection from the Internet client to
   department servers must traverses multiple firewalls.  And the client
   authentication with each firewall may be used different method.  For
   example, a firewall which protects corporate network needs strong
   authentication, because it is a gate of the Internet.  But a firewall
   which protects department network uses more weak and convenient
   authentication method such as username/password.

Procedure for TCP-based client

   This extended protocol is used for TCP-based clinets.  When a TCP-
   based client wishes to establish a connection to an object that is
   reachable only via multiple firewalls which are located like a
   cascade.

   In the SOCKS V5 protocol, the sequence between SOCKS client and SOCKS
   server is followed:

    (1) Method specific subnegotiation
    (2) Request Command
    (3) Reply

   In the extended protocol, client repeats these sequence with all
   SOCKS server which is located on the route of server.  Method
   specific subnegotiation and Request Command is not extended from
   SOCKS V5 protocol.

   To recognize the end of repeat, Reply packet is extended as follows:

    +---+---+------+------+---------+---------+---------+---------+
    |VER|REP| RSV  |ATYPE |BND.ADDR |BND.PORT |NXT.ADDR |NXT.PORT |
    +---+---+------+------+---------+---------+---------+---------+
    | 1 | 1 |X'00' |  1   |Variable |    2    |Variable |    2    |
    +---+---+------+------+---------+---------+---------+---------+

   This packet format has two new fields; NXT.ADDR and NXT.PORT.

    Where:



Kayashima                                                       [Page 2]


Internet DRAFT                                               13 Nov 1997


     o  REP         Reply field:
        The reply code is extended with multiple firewalls traversal.
        o X'09' Connect next-hop SOCKS server
     o  NXT.ADDR    Next-hop SOCKS server address
     o  NXT.PORT    Next-hop SOCKS server port


   The NXT.ADDR is next-hop SOCKS server address. The NXT.PORT is a port
   which is used at next-hop SOCKS server.  If destination host is
   behind other SOCKS servers, the SOCKS server selects next-hop SOCKS
   server, which is located at the route of client and destination host,
   and can be connected to it.  If SOCKS server can connect destination
   host directly, NXT.ADDR field and NXT.PORT field set to X'00'.

   The reply code in REP field is extended for multiple firewalls
   traversal. X'09' is new value to express that the client MUST connect
   next-hop SOCKS server.

   When the client receives this REP code, the client starts same
   sequence with next-hop SOCKS server.  This sequence repeated while
   the client receives the reply code of X'09'.

   If each subnegotiation method includes encapsulation for purposes of
   integrity checking and/or confidentiality, following request/reply
   packet and next subnegotiation packets MUST be encapsulated in the
   method dependent encapsulation.  Each SOCKS server encapsulates
   request/reply packet for itself and subnegitiation packets for next
   hop SOCKS server.  Other packets are relaied by SOCKS server without
   encapsulation.


Connection setup sequence

   This section provides an example of connection setup sequence when
   the Internet client C1 establishes a connection with department
   server S1 via corporate firewall gw1 and the department firewall gw2.

    (1) Sequence with gw1
     o C1 connects to gw1.
     o C1 does subnegotiation with gw1 directly.
     o C1 sends Request to gw1.
     o gw1 search destination. If gw1 is reachable the
       destination server, then gw1 send Reply to C1.

    (2) Sequence with gw2
     o gw1 connects to gw2.
     o C1 does subnegotiation with gw2. This sequence is relayed by gw1.
     o C1 sends Request to gw2.



Kayashima                                                       [Page 3]


Internet DRAFT                                               13 Nov 1997


     o gw2 search destination. If gw1 is reachable the destination
       server, then gw2 send Reply to C1.


Security Considerations

   This document describes a protocol for the multiple traversal of
   application layer firewalls. The security of such traversal is highly
   dependent on the particular authentication and encapsulation methods
   provided in a particular implementation, and selected during
   negotiation between SOCKS client and each SOCKS server.

References

   [RFC 1928] Leech, M., Ganis, M., Lee, Y., Kuris, R. Koblas, D., &
              Jones, L., "SOCKS Protocol V5," April 1996.

Author's Address

   Makoto Kayashima
   Hitachi Ltd. Systems Development Laboratory
   292 Yoshida-cho, Totsuka, Yokohama, Kanagawa 244, Japan
   kayashi@sdl.hitachi.co.jp

   Masato Terada
   Hitachi Ltd. Systems Development Laboratory
   292 Yoshida-cho, Totsuka, Yokohama, Kanagawa 244, Japan
   terada@sdl.hitachi.co.jp























Kayashima                                                       [Page 4]


Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/