[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01                                                         
Internet Engineering Task Force                            G. Montenegro
INTERNET DRAFT                                    Sun Microsystems, Inc.
                                                             May 1, 1998

                     Negotiated Address Reuse (NAR)
                    draft-montenegro-aatn-nar-00.txt

Status of This Memo

   This document is an individual submission to the Internet
   Engineering Task Force (IETF). Comments should be submitted to the
   author, or to the Alternative to Address Translation in Networks
   (AATN) mailing list at aatn@alpha.zk3.dec.com.

   Distribution of this memo is unlimited.

   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
   (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
   (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
   (US West Coast).


Abstract

   Network address (and port) translation is a useful technology.
   However, several shortcomings have been identified (Mobile IP, IPSEC
   and QOS flows). In these cases, NAT may be complemented by the use
   of NAR (Negotiated Address Reuse). The negotiation phase in NAR is
   based on SOCKS.









Montenegro              Expires November 1, 1998                [Page 1]


INTERNET DRAFT       Negotiated Address Reuse (NAR)             May 1998


Table of Contents

1. Introduction ...................................................    3
   1.1. Terminology ...............................................    3
   1.2. Objectives and Assumptions ................................    3
   1.3. Applicability and Benefits ................................    4
   1.4. Assumptions ...............................................    4
2. Overview of the Solution .......................................    5
   2.1 Model ......................................................    5
   2.2 Negotiation ................................................    6
   2.3 End-to-end NAR Mappings ....................................    7
   2.4 Translated NAR Mappings ....................................    7
   2.5 Packet Delivery between NAR Client and Server ..............    8
   2.6 Protocol Handling and Demultiplexing at the NAR server .....    8
      2.6.1 TCP, UDP and ICMP Handling and Demultiplexing .........    9
      2.6.2 IPSEC Handling and Demultiplexing .....................   10
      2.6.3 Mobile IP and TEP Handling and Demultiplexing .........   11
3. SOCKS-based Negotiation ........................................   14
   3.1 NAR-MODE Command ...........................................   15
   3.2 ICMP Negotiation ...........................................   16
   3.3 IPSEC Negotiation ..........................................   17
   3.4 Tunneling Negotiation ......................................   18
4. Security Considerations ........................................   19
5. Acknowledgements ...............................................   19
References ........................................................   19
Author address ....................................................   21

























Montenegro              Expires November 1, 1998                [Page 2]


INTERNET DRAFT       Negotiated Address Reuse (NAR)             May 1998


1. Introduction

   Network Address (and port) translation [NAPT] (henceforth called
   "NAT" in this document) is a very useful technology. Nevertheless,
   it is raising concerns [IABNAT] not only because of its
   architectural impurity, but also due to its limitations. This
   document proposes Negotiated Address Reuse (NAR) as a complement to
   NAT. The negotiation phase is based on the SOCKS protocol [SOCKS].
   However, once this is over and data transfer begins NAR server and
   client behave considerably different from a SOCKS server and
   client.

   The idea is to use NAT by default due to its transparency, and
   resort to NAR when necessary (or dictated by policy). At the AATN
   BOF held at the 41st IETF meeting (Los Angeles, 4/1/98), the
   applications that require a NAT alternative were initially
   identified as end-to-end:

     - IPSEC
     - Mobile IP
     - QOS flows

   This document specifies how NAR enables IPSEC and Mobile IP. QOS
   will be addressed in a future revision.


1.1. Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in RFC 2119 [9].


1.2. Objectives and Assumptions

   Given that NAT does solve a large number of problems, it makes sense
   to continue using it. Instead of replacing the NAT box, its
   capabilities are augmented by NAR. This is, by far, the most
   practical alternative. Nevertheless, NAR does not require NAT.

   A primary objective of NAR is to enable SOHO (small office home
   office) applications, in which the NAT/NAR box only has one public
   IP address (perhaps assigned dynamically by its ISP). This single
   public IP address hides all other systems within the private SOHO
   net.  This is perhaps the single most common application scenario
   for NAT.

   Finally, legacy systems outside the "local" or "private" network



Montenegro              Expires November 1, 1998                [Page 3]


INTERNET DRAFT       Negotiated Address Reuse (NAR)             May 1998


   MUST be supported. In the context of the model introduced in Section
   2.1, this means that no changes are visible outside address space
   A.


1.3. Applicability and Benefits

   Since TCP, UDP and ICMP are satisfactorily handled by NAT, there
   does not seem to be a compelling reason to use NAR for them.
   Nevertheless, even in this case there still are some benefits:

      - NAR obviates the need to explicitly handle protocols like FTP
        or ICMP that embed address and port information in its payload
        [NAPT].

      - NAR derives the benefits of using SOCKS: authenticating the
        user before granting service, and fine-grained authorization.


1.4. Assumptions

   NAR can operate under the following assumption:

      Mutual Non-Routability Assumption:

         Both address spaces are mutually non-routable (see section
         2.1, "Model"), that is, the routing fabric in one address
         space does not recognize or handle the address ranges used in
         the other.

   On the other hand, NAT cannot operate under this assumption.
   Instead, it requires the:

      Partial Routability Assumption:

         One of the address spaces is routable within the other.  In
         the examples that use the model below (section 2.1), address
         space B is routable within address space A, but the inverse
         is not true.  Default routing is a straightforward way to
         guarantee this.

   In some of the example scenarios below NAR is used to complement
   NAT. In these cases, the latter assumption is implicitly imposed.

   NAT works by establishing mappings between tuples in both address
   spaces. These mappings may be established [NAPT]:

      - statically (at startup time by virtue of manual configuration),



Montenegro              Expires November 1, 1998                [Page 4]


INTERNET DRAFT       Negotiated Address Reuse (NAR)             May 1998


        or

      - dynamically (at protocol session initiation time).

   Static mappings are difficult to maintain and prone to operator
   error.  Only dynamic mappings offer the transparency benefits of
   NAT, but they require that the NAT box be able to establish the
   mapping that applies in the reverse direction (into the NAT box), by
   examining the packet flow in the forward direction (out of the NAT
   box).

   Thus, NAT only works for network protocols that satisfy the:

      Inferrable Mapping Assumption

         A sufficient and correct mapping for inbound traffic is
         inferred by examining outbound traffic.

   There are two reasons why this assumption may not apply:

      - The protocol does not include the necessary information in
        outgoing packets (that is, outgoing packets never initiate
        sessions). This may be true because another protocol is used to
        establish sessions. For example, the mapping for incoming IPSEC
        packets (incoming SPI) is not evident from outgoing IPSEC
        packets (outgoing SPI). This session indicator is negotiated
        out-of-band, by using manual keying or IKE [IKE]. Hence, the
        only mechanism guaranteed to work is to use NAR to explictly
        establish a negotiated mapping.

      - No outgoing traffic is guaranteed. This may happen if the
        incoming traffic is destined for a server. Typically, this has
        been accomodated in NAT by static configuration. NAR provides a
        negotiated mechanism to programatically establish these
        "server" mappings.

   Because NAR adds negotiated mappings, it does not require the
   Inferrable Mapping Assumption.


2. Overview of the Solution


2.1 Model

   The model we will use is [NATMODEL]:





Montenegro              Expires November 1, 1998                [Page 5]


INTERNET DRAFT       Negotiated Address Reuse (NAR)             May 1998


   Host                    NAT/NAR box                    Host

      Xa                    Na   Nb                       Yb
   [X]------( Addr sp. A )----[N]-----( Addr sp. B )-------[Y]
            (  Network   )            (  Network   )

   Hosts X and Y belong to different address spaces A and B,
   respectively, and N is a NAT/NAR box.  N has two addresses:  Na on
   address space A, and Nb on address space B.  In [BYPASS], the
   assumption is that N has several addresses in address space B,
   different from Nb, that it can dynamically assign to or lend to X.
   These addresses are not shown above, but they can be denoted as Nb1,
   Nb2, Nb3, and so on.  NAR allows that model, but also allows X (and
   any other hosts on address space A) to reuse Nb.

   This is applicable to the very common SOHO scenario in which address
   space B is the internet, address space A is a private SOHO network,
   and N has exactly one address per address space: Na and Nb.
   Presumably, Nb is the single address assigned to it (perhaps
   dynamically) by the ISP through which N connects to the internet.

   From the point of view of NAR, N is a NAR server and X is a
   NAR client.


2.2 Negotiation

   Hosts X and Y wish to exchange traffic. Furthermore, the protocol
   they are exchanging does not satisfy the "Inferrable Mapping
   Assumption" from section 1.4.

   As specified in section 3 ("SOCKS-based Negotiation"), X uses a
   derivative of the SOCKS [SOCKS] protocol with N to obtain an IP
   address on address space B.  As a result of the negotiation, N lends
   X one of its available addresses.  Frequently, this will be the same
   address that N uses on address space B, namely, Nb. In what follows,
   this is the case.

   The NAR client also negotiates the values of protocol-dependent
   fields which will enable the NAR server, N, to demultiplex the
   incoming traffic (section 2.6).  At the end of the negotiation
   phase, N establishes a negotiated mapping so incoming replies will
   be processed correctly.

   Each mapping operates in either of two modes: (1) End-to-end mode
   (the default), or (2) Translated mode. These are explained in the
   subsequent sections.




Montenegro              Expires November 1, 1998                [Page 6]


INTERNET DRAFT       Negotiated Address Reuse (NAR)             May 1998


2.3 End-to-end NAR Mappings

   If we impose the "Mutual Non-Routability Assumption" from section
   1.4, then the sequence continues as follows:

      From that point on, X assumes address Nb as its own, and uses it
      as the source IP address of its outgoing packets.

      X then delivers those packets to N by using a tunneling mechanism
      as specified in section 4 ("Delivery between NAR server and NAR
      client").

      Packets flowing from Y to X MUST include the negotiated values so
      N can demultiplex them properly, and deliver them to X. As will
      be seen below, this does not imply any NAR support in Y.  This
      constitutes a reuse of address Nb, because in addition to N
      itself, all its NAR clients are also using Nb as their address.
      Nb is the source IP address of packets created by N (naturally)
      as well as by its NAR clients (for example, X). Packets sent by Y
      and other correspondent hosts are sent to address Nb.

      Other than the fact that X is aware of and actively uses Nb as
      its address when talking to Y, this is very similar to NAT
      [NAPT].  The difference in N's role is it simply shuttles packets
      between X and Y. Since there is no translation involved, packets
      prepared by X arrive unmodified at Y (except for fields that
      change during the course of normal routing operations, as
      specified in Section 3.3.3.1.1.1 of [Kent98b]), and viceversa.

   In this mode of operation, the NAR client in effect establishes a
   virtual presence at the NAR server. Datagrams are exchanged between
   the peer Y and the X's virtual presence within NAR server N.

   The above mode of operation is "End-to-end NAR."


2.4 Translated NAR Mappings

   It is also possible to mix NAR with the benefits of translation. For
   example, if we impose the "Partial Routability Assumption" from
   section 1.4, the sequence might proceed as follows:

      X continues using address Xa as its own, and uses it as the
      source IP address of its outgoing packets.

      X then delivers those packets to the routing infrastructure in
      address space A. Eventually, N receives the packets from X to Y,
      and processes them according to NAT rules (this may imply new



Montenegro              Expires November 1, 1998                [Page 7]


INTERNET DRAFT       Negotiated Address Reuse (NAR)             May 1998


      extensions for NAT): by changing the source IP address of the
      packets from Xa to Nb before injecting them out into address
      space B on their way to Y. In Y's replies the destination IP
      address is set to Nb.

      In this case, NAR is only used to establish the mapping, after
      which NAT (perhaps extended to handle the specific protocol being
      exchanged) takes over.

   The translation undergone by the packet is, of course, protocol
   dependent and if defined in [NAPT], follows those directives exactly
   (for example: UDP, TCP, ICMP, FTP, and so on). Translations for
   other protocols like IPSEC, and tunneling are defined below.

   The above mode of operation is "Translated NAR."


2.5 Packet Delivery between NAR Client and Server

   In Translated NAR, packets between X and N flow as in the regular
   NAT case, that is, direct delivery without recourse to tunneling
   MUST be used. This is the default mode unless explicitly overriden
   by End-to-end NAR during the negotiation phase.

   When operating in the End-to-end mode, the NAR client and server
   MUST tunnel packets to each other.  If tunneling, IP in IP [IPIP]
   MUST be used, unless GRE [GRE] is explicitly agreed upon by NAR
   client and server during the negotiation phase.


2.6 Protocol Handling and Demultiplexing at the NAR server

   Upon receiving a packet addressed to Nb, the NAR server N must
   determine if it is destined for one of its own processes, or for a
   process on one of its NAR clients. This determination depends on the
   protocol, and, in general, uses a "tuple" or set of fields in the
   packet.  By establishing a mapping between a tuple and the
   corresponding NAR client, the NAR server unequivocally identifies
   the destination of matching packets.

   Given that the NAR clients may reuse the NAR server's single IP
   address on address space B, namely, Nb, this is the value that will
   appear in the destination IP address field of incoming packets from
   Y.  This means that the destination IP address cannot be relied on
   to identify the destination of a packet.  Instead, the NAR server
   uses a field within the IP payload for demultiplexing purposes. The
   destination IP address is still checked to make sure that it matches
   what was negotiated (frequently, Nb).  The SOCKS-based negotiation



Montenegro              Expires November 1, 1998                [Page 8]


INTERNET DRAFT       Negotiated Address Reuse (NAR)             May 1998


   phase produces the required and unique tuples. They are mapped to
   the client in the SOCKS-based negotiation.

   The sections below explains processing at the NAR box for the
   following protocols:

      - TCP or UDP

      - ICMP

      - IPSEC

      - Layer 3 tunneling (Mobile IP, TEP)

   The explanations below assume that the NAR server N is examining a
   packet sent by Y, destined for X.


2.6.1 TCP, UDP and ICMP Handling and Demultiplexing

   TCP, UDP and ICMP demultiplexing is done based on the same tuples as
   NAT [NAPT].

   When N receives a TCP packet, it demultiplexes it based on the
   following tuple:

      - source IP address

      - source TCP port

      - destination TCP port

      - destination IP address

   The NAR server looks for a match in its mappings table and tunnels
   the packet to the corresponding NAR client.

   UDP packets are demultiplexed based on this tuple:

      - source UDP port

      - destination UDP port

      - destination IP address

   The source IP address in an incoming UDP reply is ignored because in
   a multihomed host it may not match the destination IP address of the
   original request (RFC 1123).



Montenegro              Expires November 1, 1998                [Page 9]


INTERNET DRAFT       Negotiated Address Reuse (NAR)             May 1998


   ICMP is demultiplexed based on the following tuple:

      - source IP address

      - ICMP identifier

      - destination IP address

   If operating on an End-to-end NAR mapping, the NAR server need not
   modify further the encapsulated IP packet within the ICMP payload as
   required by NAT [NAPT].

   Even though NAR does support TCP, UDP and ICMP, it may be simpler to
   allow NAT or Translated NAR to handle these cases. Translated NAR is
   useful, for example, to negotiate programatically a mapping for a
   server process. Once that is done, the actual translation (if in
   Translated NAR mode) is exactly as specified in [NAPT].


2.6.2 IPSEC Handling and Demultiplexing

   IPSEC packets (protocols 51 and 50 for AH and ESP, respectively)
   [Kent98a,Kent98b] from Y destined for X arrive at NAR server N. They
   are demultiplexed based on the following tuple:

      - protocol (50 or 51)

      - SPI

      - destination IP address

   During negotiation, the NAR client X and server N arrive at an SPI
   value to denote the incoming security association from Y to X.  Once
   N and X make sure that the SPI is unique within both of their SPI
   spaces, X communicates its value to Y as part of the IPSEC security
   association establishment process, namely, Quick Mode in IKE [IKE]
   or manual assignment.

   Given that Y sends packets to address Nb using the negotiated SPI, N
   is able to find a matching mapping and either:

      - tunnel the packet to X (at address Xa), or,

      - overwrite the destination IP address on the packet with Xa
        instead of Nb.

   N MUST deliver packets to X by tunneling if:




Montenegro              Expires November 1, 1998               [Page 10]


INTERNET DRAFT       Negotiated Address Reuse (NAR)             May 1998


      - operating under the "Mutually Non-Routable Assumption". Not
        doing so may prevent successful delivery of the packet within
        address space A (perhaps because of ingress filtering within
        the routing fabric of address space A), given that the source
        and destination IP addresses belong to address space B (Yb and
        Nb, respectively).

      - the packet being forwarded includes an AH header [Kent98b]
        (protocol 51) immediately following the IP header. Since AH
        renders the address fields in the preceding IP header
        immutable, NAT is out of the question, and tunneling is the
        only alternative.

   Given that NAR establishes the appropriate mapping with the expected
   SPI, translation (by NAT) of the destination IP address on incoming
   packets from Y is possible, but only if the packet includes an ESP
   header [Kent98a] (protocol 50) immediately following the IP header.
   In this case, traditional NAT has been said to "break" IPSEC, not
   because the IP address fields are immutable and therefore preclude
   NAT, but because there has been no way to establish the required
   mapping. In other words, the ESP protocol does not satisfy the
   "Inferrable Mapping Assumption."

   One problem still remains: how does Y know that it is supposed to
   send packets to X via Nb? Y is not NAR-aware, but it is definitely
   ISAKMP-aware. Y sees ISAKMP packets coming from address Nb,
   regardless of whether X is operating in End-to-end or Translated NAR
   mode.  To prevent Y from deriving the identity of its ISAKMP peer
   based on the source address of the packets (Nb), X MUST exchange
   client identifiers with Y during Quick Mode (Phase 2). ISAKMP
   traffic is simply UDP (port 500) so it is certainly handled
   correctly by NAT. The proper use of identifiers (IDii and IDir)
   during Phase 1 allow the clear separation between those identities
   and the source IP address of the packets.


2.6.3 Mobile IP and TEP Handling and Demultiplexing

   Suppose NAR client X sets up a layer 3 tunnel with host Y in address
   space B, perhaps because X and Y implement Mobile IP [MIP] or TEP
   [TEP].  X could be a foreign agent, or a co-located mobile node, and
   Y is the home agent. Suppose Xb is the mobile node's home address.

   Similar to IPSEC, Mobile IP and TEP has two distinct phases:

      - tunnel setup via a UDP-based protocol (registration protocol),
        and




Montenegro              Expires November 1, 1998               [Page 11]


INTERNET DRAFT       Negotiated Address Reuse (NAR)             May 1998


      - data transfer via tunneled packets.

   Let's examine first the data transfer phase.

   Say the incoming packet looks like this:


      INCOMING IP IN IP TUNNELED PACKET FROM Y TO N
         +-----------------+
         |        +-------+|
         | Yb->Nb | CN->Xb||
         |        +-------+|
         +--------+--------+


   Here, the original packet is sent by a correspondent node at IP
   address CN to the mobile node at address Xb. The packet was
   intercepted by the home agent at Yb and sent towards the mobile node
   via address Nb.

   Once the packet reaches N (via address Nb), the NAR server must
   identify which of its NAR clients is the ultimate destination for
   the internal packet.  In order to do so, it needs a tuple guaranteed
   to be unique among all of its NAR clients.

   The unique tuple sufficient for demultiplexing IP in IP packets
   [IPIP] (protocol 4) is:

      - destination IP address of the encapsulated (internal) header

        This is mobile node X's home address (Xb in the above
        example).  In tunneling applications other than Mobile IP, it
        is simply another address for X, significant within address
        space B.  At first glance, it seems like this is unique among
        all NAR clients. However, Xb could be a private address in use
        within address space B. Another mobile node roaming from
        another address space, say, address space C could also be using
        the same address. So Xb by itself is not unique, but the
        combination with the remote tunnel endpoint is (see next
        item).

      - source IP address of the external header

        This, the remote end of the tunnel, is Yb in the above
        example.  Its combination with the previous item is guaranteed
        to be unique among all of N's NAR clients.

      - destination IP address of the external header



Montenegro              Expires November 1, 1998               [Page 12]


INTERNET DRAFT       Negotiated Address Reuse (NAR)             May 1998


        This, the local end of the tunnel, is Nb in the above example,
        and, given that it is frequently used by N and all of its NAR
        client, is usually not unique.

   Once N identifies the ultimate destination of the packet, Xa, it
   must deliver the internal packet there. From section 2.5, there are
   two means to do so: tunneling (if using End-to-end NAR) and direct
   delivery as in regular NAT (if using Translated NAR).  As end-to-end
   mode adds yet another IP header, whenever possible, Translated mode
   is preferred. In this case, the packet that arrives at Xa is:


      DELIVERING IP IN IP PACKET FROM N TO X IN TRANSLATED MODE
         +-----------------+
         |        +-------+|
         | Na->Xa | CN->Xb||
         |        +-------+|
         +--------+--------+


   If using End-to-end mode, the packet that arrives at Xa is:


      DELIVERING IP IN IP PACKET FROM N TO X IN END-TO-END MODE
         +---------------------------+
         |        +-----------------+|
         |        |        +-------+||
         | Na->Xa | Yb->Nb | CN->Xb|||
         |        |        +-------+||
         |        +--------+--------+|
         +---------------------------+


   GRE packets [Hanks94] (protocol 47) without a Key field are only
   handled if their Protocol Type field has a value of 0x800 (other
   values are outside the scope of this document), and are
   demultiplexed based on the same tuple as IP in IP packets. In GRE
   terminology, the tuple is:

      - destination IP address of the payload (internal) packet

      - source IP address of the delivery (external) packet

      - destination IP address of the delivery (external) packet

   GRE packets with a Key field could be demultiplexed based on the
   tunnel identifier [TEP], but it is simpler to just use the above
   tuple in all GRE cases.



Montenegro              Expires November 1, 1998               [Page 13]


INTERNET DRAFT       Negotiated Address Reuse (NAR)             May 1998


   GRE packets with a Routing field are outside the scope of this
   document.

   Keeping in mind that Y cannot address X directly, how does the
   latter guarantee that the former send tunneled packets to it via N?
   It must do without requiring any new functionality at node Y (that
   is, Y is unaware of NAR or NAT processing at N). Accordingly, this
   tunnel must be configured using the Registration Protocol as defined
   in [MIP].

   Given that Mobile IP registration protocol is UDP (port 434)
   traffic, it, in fact, works over NAT. If mobile node X is
   registering with home agent Y, it must use Nb as the care-of address
   of home address Xb. This guarantees that Y sends packets to X via
   Nb, after which the negotiated mapping takes over such that N
   delivers packets to Xa, as outlined above.

   It is possible to shield the mobile node X from any knowledge of NAR
   by integrating Mobile IP into the NAR server. All the NAR server
   needs is to be able to create the mapping between the above tuple
   and the mobile node. This informtion is available from the
   Registration protocol itself, so an explicit SOCKS-based negotiation
   phase is not required. For this to work, the mobile node must learn
   the care-of address it must use, namely, Nb from the agent
   advertisements instead of relying on the SOCKS-based negotiation to
   produce this value. If the mobile node has acquired a co-located
   address, the foreign agent issuing agent advertisements (perhaps the
   NAR server itself) must use the 'R' bit to force the mobile node's
   Registration Request to go through it.


3. SOCKS-based Negotiation

   In the negotiation phase, both NAR server and NAR client must agree
   on values used in different protocols fields. Example values are:

        - IPv4 addresses used as tunnel endpoints or as externally
          visible addresses

        - ports for TCP or UDP

        - SPI values for IPSEC

   The negotiation used by NAR is based on SOCKS [SOCKS] messages, and,
   where possible, reuses the exact same formats. However, the behavior
   of the entities involved, namely, the NAR client and NAR server, is
   very different from that between a SOCKS client and server: instead
   of setting up an application layer gateway, the objective is to



Montenegro              Expires November 1, 1998               [Page 14]


INTERNET DRAFT       Negotiated Address Reuse (NAR)             May 1998


   establish a mapping that (1) enables NAT (Translated NAR), or (2)
   allows the client to acquire a virtual presence at the server
   (End-to-end NAR).

   The sequence of the SOCKS negotiation is altered slightly in order
   to allow for NAR mode to be set after the authentication phase
   (Section 3 of [SOCKS]), and before the SOCKS commands are issued
   (Section 4 of [SOCKS]). In addition to SOCKS commands (formatted
   according to Section 4 of [SOCKS], this document defines NAR
   commands. However, these MUST NOT be exchanged before the
   negotiation enters NAR mode, as specified in section 3.1, below.

   Finally, the objective of NAR negotiations is not to establish a
   relay for outgoing packets (as these simply rely on usual routing in
   order to be delivered to the end system), but for incoming packets
   from the "outside" end system to the NAR client.

   Negotiations for UDP and TCP are defined in [SOCKS].


3.1 NAR-MODE Command

   NAR-MODE is a new SOCKS command, with an identifier of TBD, used by
   the NAR client to advise the server that all subsequent exchanges
   are to be interpreted as a NAR, not a SOCKS negotiation.  NAR-MODE
   is formatted according to Section 4 of [SOCKS]. Servers which do not
   support the NAR-MODE command should respond with the "Command not
   supported" error.

   The client MUST set DST.PORT to a port number of 0. and DST.ADDR to
   the address of the target address (Yb, in the examples above).

   The NAR-MODE command implies a persistent connection, because the
   client is requesting the server to treat all subsequent negotiations
   as NAR, not SOCKS negotiations.  Accordingly, the server MUST hold
   the connection after the NAR-MODE command is completed to perform
   another SOCKS5 command.  Unless otherwise specified, command syntax
   follows SOCKS.  The semantics, however, are dictated by NAR.

   The reply to the command is also formatted as a standard reply
   [SOCKS, sec 6.].  The address returned in BND.ADDR MUST be the IPv4
   address offered by the NAR server for reuse by the NAR client (Nb,
   in the examples above).

   Flag bits in the request and reply are defined as follows:

         TUNNELED-DELIVERY X'01'
         GRE               X'02'



Montenegro              Expires November 1, 1998               [Page 15]


INTERNET DRAFT       Negotiated Address Reuse (NAR)             May 1998


   NAR mode uses the direct delivery method by default (Section 2.5).
   If the client wishes to use the tunneled delivery method (End-to-end
   NAR) it sets the TUNNELED-DELIVERY in the FLAG field of the
   request.  Furthermore, the client may petition the use of GRE by
   setting that bit in the FLAG field of the request.

   The server grants the above requests by setting the corresponding
   bits in the FLAG field of its reply to the client.  The server MAY
   also impose any of the options above by setting the corresponding
   bit(s) in the FLAG field of its reply, regardless of what the client
   requested.  The client MUST conform to what the server requests. The
   server MAY ignore non-conforming clients.


3.2 ICMP Negotiation

   The objective of the ICMP negotiation is to establish a mapping
   between the ICMP tuple in section 2.6.1 and the IPv4 address of the
   NAR client. The NAR server derives the latter from the TCP
   connection in use for the NAR negotiation (on TCP port 1080). It
   knows the value of the remote IP endpoint from the value of DST.ADDR
   in the NAR-MODE command, and the value of the local IP endpoint from
   the value of BND.ADDR in the reply to the NAR-MODE command.  All
   that is needed is a command to negotiate the value of the remaining
   element of the tuple: ICMP identifier.

   The ICMP-ASSOCIATE request is a new NAR command used to establish an
   association within the NAR relay process to handle ICMP datagrams:

      +----+-----+-------------+
      |VER | CMD |   ICMP.ID   |
      +----+-----+-------------+
      | 1  |  1  |      2      |
      +----+-----+-------------+

   The fields in the ICMP-ASSOCIATE packet are (with values in network
   octet order):

      o VER     protocol version: X'01'
      o CMD
         o ICMP-ASSOCIATE TBD
      o ICMP.ID         Value to be used in the Identifier field of the
                        ICMP packet by the client. It MAY be set by the
                        client in the request, and MUST be confirmed or
                        overriden by the server in the reply.

   The reply to the command is also formatted as shown above. The CMD
   field is used as a reply field in the response, with reply values as



Montenegro              Expires November 1, 1998               [Page 16]


INTERNET DRAFT       Negotiated Address Reuse (NAR)             May 1998


   specified in [SOCKS, Section 6].


3.3 IPSEC Negotiation

   The objective of the IPSEC negotiation is to establish a mapping
   between the tuple in section 2.6.2 and the IPv4 address of the NAR
   client. The NAR server derives the latter from the TCP connection in
   use for the NAR negotiation (on TCP port 1080). It knows the value
   of the reused IP address (same value as BND.ADDR in the reply to the
   NAR-MODE command). All that is needed is a command to negotiate the
   remaining values of the tuple: the incoming SPI and protocol.

   The IPSEC-ASSOCIATE request is a new NAR command used to establish
   an association within the NAR relay process to handle IPSEC
   datagrams:

      +----+-----+-------------+--------+
      |VER | CMD | IN.PROTOCOL | IN.SPI |
      +----+-----+-------------+--------+
      | 1  |  1  |      1      |    4   |
      +----+-----+-------------+--------+

   The fields in the IPSEC-ASSOCIATE packet are (with values in network
   octet order):

      o VER     protocol version: X'01'
      o CMD
         o IPSEC-ASSOCIATE TBD
      o IN.PROTOCOL     D'50' (X'32') for ESP, D'51' (X'33') for AH.
      o IN.SPI          SPI that the remote node uses when sending
                        datagrams to the NAR client (incoming SPI).
                        Typically not set by the client on the request,
                        but by the server on the reply. It must then be
                        communicated to the remote node via IKE or
                        manual key exchange.

   The IN.SPI field contains the SPI for incoming IPSEC datagrams.  If
   the client is not in possesion of this information at the time of
   the IPSEC-ASSOCIATE, the client MUST use an SPI number of all
   zeros.

   The reply to the command is also formatted as shown above. The CMD
   field is used as a reply field in the response, with reply values as
   specified in [SOCKS, Section 6].  The SPI returned is assigned by
   the NAR server for the NAR client to use as its own and overrides
   whatever value the client may have used in the request.




Montenegro              Expires November 1, 1998               [Page 17]


INTERNET DRAFT       Negotiated Address Reuse (NAR)             May 1998


3.4 Tunneling Negotiation

   The objective of the TUNNEL negotiation is to establish a mapping
   between the tuple in section 2.6.3 and the IPv4 address of the NAR
   client. The NAR server derives the latter from the TCP connection in
   use for the NAR negotiation (on TCP port 1080). It knows the
   value of the remote tunnel endpoint from the value of DST.ADDR in
   the NAR-MODE command, and the value of the local tunnel endpoint
   from the value of BND.ADDR in the reply to the NAR-MODE command.
   All that is needed is a command to negotiate the value of the
   remaining elements of the tuple: tunneling protocol, and the
   internal tunnel address on the local side.

   The TUNNEL-ASSOCIATE request is a new NAR command used to establish
   an association within the NAR relay process to handle tunneled
   datagrams:

      +----+-----+------+-----------+-------------+
      |VER | CMD | ATYP | LTUN.ADDR | TUN.PROTOCOL|
      +----+-----+------+-----------+-------------+
      | 1  |  1  |  1   | Variable  |      1      |
      +----+-----+------+-----------+-------------+

   The fields in the TUNNEL-ASSOCIATE packet are (with values in
   network octet order):

      o VER     protocol version: X'01'
      o CMD
         o TUNNEL-ASSOCIATE TBD
      o ATYP    address type of following address
        o IP V4 address: X'01'
        o DOMAINNAME: X'03'
        o IP V6 address: X'04'
      o LTUN.ADDR       Internal Address of the tunnel on the local
                        side.  In Mobile IP, this corresponds to the
                        value of the NAR client's home address (Xb in
                        the example above).  MUST be set by the client
                        on the request, confirmed by the server on the
                        reply.
      o TUN.PROTOCOL    D'4' (X'4') for IP in IP, D'47' (X'2F') for
                        GRE.

   The reply to the command is also formatted as shown above. The CMD
   field is used as a reply field in the response, with reply values as
   specified in [SOCKS, Section 6].






Montenegro              Expires November 1, 1998               [Page 18]


INTERNET DRAFT       Negotiated Address Reuse (NAR)             May 1998


4. Security Considerations

   This document does not add any security issues to those already
   posed by NAT, or normal routing operations. Routing decisions are
   based on a tuple with typically one element: destination IP
   address.  This document just adds more elements to the tuple.
   Furthermore, by allowing an End-to-end mode of operation and by
   introducing a negotiation phase to address reuse, the mechanisms
   described here are more secure and less arbitrary than NAT.

   A word of caution is in order: SPI values are meant to be random,
   and, thus serve also as cookies to reduce off-the-path
   denial-of-service attacks.  However, NAR support for IPSEC, renders
   the SPI a negotiated item: in addition to being a unique value at
   the receiver X, it must also be unique at the NAR box, N.  Limiting
   the range of the SPI values available to the NAR clients reduces
   their entropy slightly, thus (slightly) weakening their
   effectiveness as an anti-clogging token.


5. Acknowledgements

   Many thanks to Pat Calhoun, Michael Speer and Vipul Gupta for
   helpful discussion and ideas. The latter's [NATMODEL] proved
   invaluable in composing this document.

   Some text in section 3 was taken (with slight modifications) from
   [SOCKS] and draft-ietf-aft-socks-ext-00.


References

    [BYPASS]       G. Tsirtsis and A. O'Neill, "NAT Bypass for End 2
                   End 'sensitive' applications" -- work in progress,
                   draft-tsirtsis-nat-bypass-00.txt, January 1998.

    [Hanks94]      Hanks, S., Li, R., Farinacci, D., and P. Traina,
                   "Generic Routing Encapsulation (GRE)", RFC 1701, and
                   "Generic Routing Encapsulation over IPv4 networks",
                   RFC 1702, October 1994.

    [IABNAT]       T. Hain, "Architectural Implications of NAT" -- work
                   in progress, draft-iab-nat-implications-00.txt,
                   March 1998.







Montenegro              Expires November 1, 1998               [Page 19]


INTERNET DRAFT       Negotiated Address Reuse (NAR)             May 1998



    [ISAKMP]       Maughhan, D., Schertler, M., Schneider, M., and
                   Turner, J., "Internet Security Association and Key
                   Management Protocol (ISAKMP)",
                   draft-ietf-ipsec-isakmp-09.{ps,txt}, March 1998.

    [IKE]          Harkins, D., Carrel, D., "The Internet Key Exchange
                   (IKE)", draft-ietf-ipsec-isakmp-oakley-07.txt, March
                   1998.

    [Kent98a]      S. Kent, R. Atkinson, "IP Encapsulating Payload" --
                   work in progress, draft-ietf-ipsec-esp-v2-04.txt,
                   March 1998 (obsoletes RFC 1827, August 1995).

    [Kent98b]      S. Kent, R. Atkinson, "IP Authentication Header" --
                   work in progress,
                   draft-ietf-ipsec-auth-header-05.txt, March 1998
                   (obsoletes RFC 1826, August 1995).

    [Kent98c]      S. Kent, R. Atkinson, "Security Architecture for the
                   Internet Protocol" -- work in progress,
                   draft-ietf-ipsec-arch-sec-04.txt, March 1998
                   (obsoletes RFC 1827, August 1995).

    [IPIP]         C. Perkins, Editor.  IP Encapsulation within IP. RFC
                   2003, October 1996.

    [MIP]          C. Perkins, Editor.  IP Mobility Support.  RFC
                   2002, October 1996.

    [MoGu97]       G. Montenegro and V. Gupta, "Firewall Support for
                   Mobile IP" -- work in progress,
                   draft-montenegro-firewall-sup-03.txt, January 1998.

    [NAPT]         P. Srisuresh and K. Egevang, "The IP Network Address
                   Translator (NAT)" -- work in progress,
                   draft-rfced-info-srisuresh-05.txt, February 1998.

    [NATMODEL]     V. Gupta, message to the AATN mailing list,
                   Message-Id:
                   <libSDtMail.9802121343.10882.vgupta@nobel>, February
                   12, 1998.

    [NET66]        R. G. Moskowitz, "Network Address Translation issues
                   with IPsec" -- work in progress,
                   draft-moskowitz-net66-vpn-00.txt, February 1998.

    [SOCKS]        M. Leech, M. Ganis, Y. Lee, R. Kuris, D. Koblas, L.



Montenegro              Expires November 1, 1998               [Page 20]


INTERNET DRAFT       Negotiated Address Reuse (NAR)             May 1998


                   Jones, "SOCKS Protocol Version 5", RFC 1928, March
                   1996.

    [TEP]          P. Calhoun, G. Montenegro, C. Perkins, "Tunnel
                   Establishment Protocol" -- work in progress,
                   draft-ietf-mobileip-calhoun-tep-01.txt, March 1998.


Author address


   Questions about this document may be directed at:

          Gabriel E. Montenegro
          Sun Microsystems, Inc.
          901 San Antonio Road
          Mailstop UMPK 15-214
          Mountain View, California 94303

          Voice:  +1-415-786-6288
          Fax:    +1-415-786-6445

          E-Mail: gabriel.montenegro@eng.sun.com




























Montenegro              Expires November 1, 1998               [Page 21]