Internet Engineering Task Force G. Montenegro
INTERNET DRAFT Sun Microsystems, Inc.
M. Borella
3Com Corporation
May, 19, 1999
RSIP Support for End-to-end IPSEC
draft-ietf-nat-rsip-ipsec-00.txt
Status of This Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed
at http://www.ietf.org/shadow.html.
Abstract
This document proposes mechanisms that enable "Realm-Specific
IP" (RSIP) to handle end-to-end IPSEC.
Expires November 19, 1999 [Page 1]
INTERNET DRAFT RSIP Support for End-to-end IPSEC May 1999
Table of Contents
1. Introduction ................................................... 3
2. Model .......................................................... 3
3. IKE Handling and Demultiplexing ................................ 4
4. IPSEC Handling and Demultiplexing .............................. 5
5. RSIP Protocol Extensions ....................................... 5
5.1 New Messages and Parameters to Support IKE ................. 6
5.2 New Messages and Parameters to Support IPSEC ............... 7
6. Security Considerations ........................................ 8
7. Acknowledgements ............................................... 9
Appendix: On Optional Port Allocation to RSIP Clients ............. 9
References ........................................................ 10
Author addresses .................................................. 11
Expires November 19, 1999 [Page 2]
INTERNET DRAFT RSIP Support for End-to-end IPSEC May 1999
1. Introduction
This document specifies RSIP extensions to enable end-to-end
IPSEC. It assumes the RSIP framework as presented in [RSIP-FW],
and specifies extensions to the RSIP protocol defined in
[RSIP-P]. Other terminology follows [NAT-TERMS].
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].
2. Model
For clarity, the discussion below assumes this model:
RSIP client RSIP server Host
Xa Na Nb Yb
+------------+ Nb1 +------------+
[X]------| Addr space |----[N]-----| Addr space |-------[Y]
| A | Nb2 | B |
+------------+ ... +------------+
Hosts X and Y belong to different address spaces A and B,
respectively, and N is an RSIP server. N has two addresses:
Na on address space A, and Nb on address space B. For example,
A could be a private address space, and B the public address
space of the general Internet. Additionally, N may have a
pool of addresses in address space B which it can assign to
or lend to X.
The RSIP server N is not required to have more than one address
on address space B. RSIP allows X (and any other hosts on
address space A) to reuse Nb. Because of this, Y's SPD SHOULD
be configured to support session-oriented keying [Kent98c].
Not doing so implies that only one peer may, at any given
point in time, use address Nb when exchanging IPSEC packets
with Y. Additionally, Y's SPD MAY be configured to support
user-oriented keying, although other types of identifications
within the IKE Identification Payload are equally effective
at disambiguating who is the real client behind the single
address Nb [Piper98].
This document proposes RSIP extensions and mechanisms to
enable an RSIP client X to initiate IKE and IPSEC sessions to
a legacy IKE and IPSEC node Y. In order to do so, X exchanges
Expires November 19, 1999 [Page 3]
INTERNET DRAFT RSIP Support for End-to-end IPSEC May 1999
RSIP protocol messages with the RSIP server N.
This document currently does not address IKE/IPSEC session
initiation from Y to an RSIP client X.
The explanations below assume that the RSIP server N is
examining a packet sent by Y, destined for X. This implies that
in the discussion below "source" refers to Y and "destination"
refers to Y's peer, namely, X's presence at N.
3. IKE Handling and Demultiplexing
IKE packets are carried on UDP port 500 for both source
and destination [ISAKMP]. Usually, UDP traffic is handled
appropriately by NAPT [NAPT], and does not require RSIP.
However, IKE uses a fixed source port of 500 which precludes
that field being used for demultiplexing. Instead, the
"Initiator Cookie" field in the IKE header fields must be used
for this purpose. This fields is appropriate as it is guaranteed
to be present in every IKE exchange (Phase 1 and Phase 2),
and is guaranteed to be in the clear (even if subsequent IKE
payloads are encrypted). However, it is protected by the Hash
payload in IKE [IKE], so simply extending NAPT does not work.
Because of this, RSIP must be used to agree upon a valid value
for the Initiator Cookie.
Once X and N arrive at a mutually agreeable value for the
Initiator Cookie, X uses it to create an IKE packet and tunnels
it the RSIP server N. N decapsulates the IKE packet and sends
it on address space B.
The complete tuple negotiated via RSIP, and used for
demultiplexing incoming IKE responses from Y at the RSIP server
N is:
- IKE destination port Number (usually 500)
- Initiator Cookie
- destination IP address
Notice that RSIP does support alternate UDP ports (other than
500) for IKE, as this may be useful in certain situations (e.g.
testing purposes).
One problem still remains: how does Y know that it is supposed
to send packets to X via Nb? Y is not RSIP-aware, but it is
Expires November 19, 1999 [Page 4]
INTERNET DRAFT RSIP Support for End-to-end IPSEC May 1999
definitely IKE-aware. Y sees IKE packets coming from address Nb.
To prevent Y from mistakenly deriving the identity of its IKE
peer based on the source address of the packets (Nb), X MUST
exchange client identifiers with Y:
- IDii, IDir if in Phase 1, and
- IDci, IDcr if in Phase 2.
The proper use of identifiers allows the clear separation
between those identities and the source IP address of the
packets.
4. IPSEC Handling and Demultiplexing
The RSIP client X and server N arrive at an SPI value to
denote the incoming IPSEC 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.
This ensures that Y sends IPSEC packets (protocols 51 and
50 for AH and ESP, respectively) [Kent98a,Kent98b] to X via
address Nb using the negotiated SPI.
IPSEC packets (protocols 51 and 50 for AH and ESP, respectively)
[Kent98a,Kent98b] from Y destined for X arrive at RSIP server
N. They are demultiplexed based on the following tuple of
demultiplexing fields:
- protocol (50 or 51)
- SPI
- destination IP address
N is able to find a matching mapping, and tunnels the packet
to X according to the tunneling mode in effect.
5. RSIP Protocol Extensions
The next two sections specify how the RSIP protocol is extended
to support both IKE (a UDP application) and the IPSEC-defined
AH and ESP headers (layered directly over IP with their own
protocol numbers).
Expires November 19, 1999 [Page 5]
INTERNET DRAFT RSIP Support for End-to-end IPSEC May 1999
RSIP IKE and IPSEC messages use the same message numbers as
ASSIGN_REQUEST and ASSIGN_RESPONSE, only with different RSIP
methods. These methods are called RSIKE and RSIPSEC and are
assigned RSIP method numbers 3 and 4, respectively.
5.1 New Messages and Parameters to Support IKE
RSIP support for IKE requires the following new message types:
ASSIGN_REQUEST_IKE
The ASSIGN_IKE_request message is used by an RSIP-client to
request IKE parameter assignments.
The port range parameter is optional. If not included the
default is:
number of ports: 1 port number: 500
If included, the port range MUST request only one port.
<ASSIGN_REQUEST_IKE> ::= <Message Type> <Client ID>
<RSIP method = RSIKE>
<IP Address Request>
<Number of Initiator Cookies>
[<Number of Ports>]
[<Lease Time>] [<Message ID>]
ASSIGN_RESPONSE_IKE
The ASSIGN_RESPONSE_IKE message is used by an RSIP server
to assign initiator cookies to an IKE-enabled RSIP client.
<ASSIGN_RESPONSE_IKE> ::= <Message Type> <Client ID> <Bind ID>
<RSIP method = RSIKE>
<IP Address>[<Port Range>]
<Initiator Cookie Range>
<Lease Time> [<Message ID>]
In response to the optional port request, the server MUST
assign only one port.
Additionally, RSIP support for IKE requires the following
new parameters:
Number of Initiator Cookies
Expires November 19, 1999 [Page 6]
INTERNET DRAFT RSIP Support for End-to-end IPSEC May 1999
Code Length Number of Initiator Cookies
+------+--------+-----------------------------+
| 20 | 1 | (2 bytes) |
+------+--------+-----------------------------+
Sent by the RSIP client in ASSIGN_REQUEST_IKE messages to ask
for a particular number of initiator cookies to be assigned.
Initiator Cookie Range
Code Length Low Cookie High Cookie
+------+--------+-----------+-----------+
| 21 | 16 | (8 bytes) | (8 bytes) |
+------+--------+-----------+-----------+
Sent by the RSIP server to the client in ASSIGN_RESPONSE_IKE
messages. The cookie range MUST be contiguous and is
inclusive.
5.2 New Messages and Parameters to Support IPSEC
This section defines the protocol extensions required for RSIP
to support AH and ESP. The required message types are:
ASSIGN_REQUEST_IPSEC
The ASSIGN_REQUEST_IPSEC message is used by an RSIP client
to request IPSEC parameter assignments. An RSIP client MUST
request an IP address and SPIs in one message.
If the RSIP client wishes to use IPSEC to protect a TCP or
UDP application, it SHOULD use the optional port range
parameter (see the Appendix).
The format of these messages is:
<ASSIGN_REQUEST_IPSEC> ::= <Message Type> <Client ID>
<RSIP method = RSIPSEC>
<IP Addr Req> <Number of SPIs>
[<Number of Ports>]
[<Lease Time>] [<Message ID>]
ASSIGN_RESPONSE_IPSEC
The ASSIGN_RESPONSE_IPSEC message is used by an RSIP server
to assign parameters to an IPSEC-enabled RSIP client.
Expires November 19, 1999 [Page 7]
INTERNET DRAFT RSIP Support for End-to-end IPSEC May 1999
<ASSIGN_RESPONSE_IPSEC> ::= <Message Type> <Client ID> <Bind ID>
<RSIP method = RSIPSEC>
<IP Address> <SPI Range>
[<Port Range>] <Lease Time>
[<Message ID>]
Additionally, RSIP support for IPSEC requires the following
new parameters:
Number of SPIs
Code Length Number of SPIs
+------+--------+-----------------------------+
| 22 | 1 | (2 byte) |
+------+--------+-----------------------------+
Sent by the RSIP client in ASSIGN_REQUEST_IPSEC messages
to ask for a particular number of SPIs to be assigned.
SPI Range
Code Length Low SPI High SPI
+------+--------+-----------+-----------+
| 23 | 8 | (4 bytes) | (4 bytes) |
+------+--------+-----------+-----------+
Sent by the RSIP server in ASSIGN_RESPONSE_IPSEC messages
to assign an SPI range. The SPI range MUST be contiguous
and is inclusive.
6. Security Considerations
This document does not add any security issues to those already
posed by NAT, or normal routing operations. Current routing
decisions typically are based on a tuple with only 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: Cookie and SPI values are meant
to be semi-random, and, thus serve also as anti-clogging
tokens to reduce off-the-path denial-of-service attacks.
However, RSIP support for IPSEC, renders cookies and SPI's
a negotiated item: in addition to being unique values at the
receiver X, they must also be unique at the RSIP server, N.
Expires November 19, 1999 [Page 8]
INTERNET DRAFT RSIP Support for End-to-end IPSEC May 1999
Limiting the range of the cookie and SPI values available to
the RSIP clients reduces their entropy slightly, thus (slightly)
weakening their effectiveness as an anti-clogging token.
7. Acknowledgements
Many thanks to Vipul Gupta, Jeffrey Lo, Dan Nessett and Gary
Jaszewski for helpful discussions.
Appendix: On Optional Port Allocation to RSIP Clients
Despite the fact that SPIs rather than ports are used to
demultiplex packets at the RSIP server, the RSIP server may
still allocate mutually exclusive port numbers to the RSIP
clients. If this does not happen, there is the possibility that
two RSIP clients using the same IP address attempt an IPSEC
session with the same public server using the same source
port numbers.
+-------------+
| RSIP client |
| 1 +--+
| 10.0.0.2 | | +-------------+
+-------------+ |10.0.0.1 | |149.112.240.1
+---------+ RSIP server +----------------
+-------------+ | | |
| RSIP client | | +-------------+
| 2 +--+ private public
| 10.0.0.3 | | network network
+-------------+ |
|
|
...
For example, consider hosts 10.0.0.2 and 10.0.0.3 in the
architecture depicted above. Assume that they both are
using public address 149.112.240.1 and both are contacting an
external server at 192.156.136.22 port 80. If they are using
IPSEC but are not allocated mutually exclusive port numbers,
they may both choose the same ephemeral port number to use when
contacting 192.156.136.22:80. Assume client 1 does so first,
and after engaging in an IKE negotiation begins communicating
with the public server using IPSEC. When Client 2 starts its IKE
session, it sends its identification to the public server. The
latter's SPD requires that different identities use different
flows (port numbers). Because of this, the IKE negotiation
will fail. Client 2 will be forced to try another ephemeral
Expires November 19, 1999 [Page 9]
INTERNET DRAFT RSIP Support for End-to-end IPSEC May 1999
port until it succeeds in obtaining one which is currently not
in use by any other security association between the public
server and any of the RSIP clients in the private network.
Each such iteration is costly in terms of round-trip times and
CPU usage. Hence --and as a convenience to its RSIP clients--,
an RSIP server may also assign mutually exclusive port numbers
to its IPSEC RSIP clients.
Despite proper allocation of port numbers, an RSIP server
cannot prevent RSIP clients using encryption from using any
port number, since it cannot examine the port fields. However,
it is in the RSIP clients' best interest to adhere to these
port assignments (when they are available) in order to avoid
costly conflicts and the resultant renegotiations.
References
[ISAKMP] Maughhan, D., Schertler, M., Schneider, M.,
and Turner, J., "Internet Security Association
and Key Management Protocol (ISAKMP)," RFC 2408,
November 1998.
[IKE] Harkins, D., Carrel, D., "The Internet Key
Exchange (IKE)," RFC 2409, November 1998.
[Kent98a] S. Kent, R. Atkinson, "IP Encapsulating
Payload," RFC 2406, November 1998 (obsoletes
RFC 1827, August 1995).
[Kent98b] S. Kent, R. Atkinson, "IP Authentication
Header," RFC 2402, November 1998 (obsoletes
RFC 1826, August 1995).
[Kent98c] S. Kent, R. Atkinson, "Security Architecture
for the Internet Protocol," RFC 2401, November
1998 (obsoletes RFC 1827, August 1995).
[Piper98] D. Piper, "The Internet IP Security Domain of
Interpretation for ISAKMP," RFC 2407, November
1998.
[NAPT] P. Srisuresh and K. Egevang, "Traditional IP
Network Address Translator (Traditional NAT)" --
work in progress,
Expires November 19, 1999 [Page 10]
INTERNET DRAFT RSIP Support for End-to-end IPSEC May 1999
draft-ietf-nat-traditional-01.txt, October
1998.
[NAT-TERMS] P. Srisuresh and M. Holdredge, "IP Network
Address Translator (NAT) Terminology and
Considerations Translator (NAT)" -- work in
progress, draft-ietf-nat-terminology-02.txt,
April 1999.
[RSIP-FW] J. Lo, M. Borella and D. Grabelsky, "Realm
Specific IP: A Framework" -- work in progress,
draft-ietf-nat-rsip-framework-01.txt, May 1999.
[RSIP-P] M. Borella, D. Grabelsky, J. Lo, K. Taniguchi,
"Realm Specific IP: Protocol Specification" --
work in progress,
draft-ietf-nat-rsip-protocol-01.txt, April
1999.
Author addresses
Questions about this document may be directed at:
Gabriel E. Montenegro
Sun Labs Networking and Security Center
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: gab@sun.com
Michael Borella
3Com Corp.
1800 W. Central Rd.
Mount Prospect IL 60056
Voice: +1-847 342-6093
E-Mail: mike_borella@3com.com
Copyright (c) The Internet Society (1999). All Rights Reserved.
Expires November 19, 1999 [Page 11]
INTERNET DRAFT RSIP Support for End-to-end IPSEC May 1999
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Expires November 19, 1999 [Page 12]
