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]