Internet Engineering Task Force G. Montenegro
INTERNET DRAFT Sun Microsystems, Inc.
M. Borella
3Com Corporation
October 29, 1999
RSIP Support for End-to-end IPSEC
draft-ietf-nat-rsip-ipsec-01.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 April 29, 1999 [Page 1]
INTERNET DRAFT RSIP Support for End-to-end IPSEC October 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 ....................................... 6
5.1 New Messages and Parameters to Support IKE ................. 6
5.2 New Messages and Parameters to Support IPSEC ............... 8
6. Security Considerations ........................................ 9
7. Acknowledgements ............................................... 10
Appendix A: On Optional Port Allocation to RSIP Clients ........... 10
Appendix B: RSIP Error Numbers for IKE and IPSEC Support .......... 11
Appendix C: Message Type Values for IKE and IPSEC Support ......... 11
References ........................................................ 12
Author addresses .................................................. 13
Expires April 29, 1999 [Page 2]
INTERNET DRAFT RSIP Support for End-to-end IPSEC October 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 April 29, 1999 [Page 3]
INTERNET DRAFT RSIP Support for End-to-end IPSEC October 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.
NOTE: This may be accomodated in the future by defining new
methods LISTEN_REQUEST_RSIKE, and LISTEN_RESPONSE_RSIKE. These
would allow the client to register some value (perhaps an ID?).
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.
Expires April 29, 1999 [Page 4]
INTERNET DRAFT RSIP Support for End-to-end IPSEC October 1999
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
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.
Expires April 29, 1999 [Page 5]
INTERNET DRAFT RSIP Support for End-to-end IPSEC October 1999
5. RSIP Protocol Extensions
The next two sections specify how the RSIP protocol [RSIP-P] 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).
If a server implements RSIP support for IKE and IPSEC as defined
in this document, it MAY include the relevant RSIP Method
parameters (RSIKE and RSIPSEC, respectively) in the
REGISTER_RESPONSE method sent to the client. The values are:
3 RSIP with IKE (RSIKE)
4 RSIP with IPSEC (RSIPSEC)
Unless otherwise specified, requirements of micro and macro
flow-based policy are handled according to [RSIP-P].
5.1 New Messages and Parameters to Support IKE
RSIP support for IKE requires the following new message types:
ASSIGN_REQUEST_RSIKE
The ASSIGN_IKE_request message is used by an RSIP-client to
request IKE parameter assignments.
IKE uses port 500 on both local and remote ports.
Nevertheless, some implementations allow different port
values (for example to allow for more flexible testing). RSIP
support for IKE allows alternate port assignments. Typically,
however, the default value will be used. In this case the
port parameters MUST be initialized with the "don't care"
value of zeros.
number of ports: 1 port number: 500
If the client initializes either port parameter to a non-zero
value, it MUST request only one port.
The client may include an Initiator Cookie Range parameter as
a suggestion to the server.
Expires April 29, 1999 [Page 6]
INTERNET DRAFT RSIP Support for End-to-end IPSEC October 1999
<ASSIGN_REQUEST_RSIKE> ::= <Version>
<Message Type>
<Client ID>
<Address (local)>
<Port (local)>
<Address (remote)>
<Port (remote)>
<Number of Initiator Cookies>
[Lease Time]
[Tunnel Type]
[Message ID]
[Initiator Cookie Range]
ASSIGN_RESPONSE_RSIKE
The ASSIGN_RESPONSE_RSIKE message is used by an RSIP server
to assign initiator cookies to an IKE-enabled RSIP client.
<ASSIGN_RESPONSE_RSIKE> ::= <Version>
<Message Type>
<Client ID>
<Bind ID>
<Address (local)>
<Ports (local)>
<Address (remote)>
<Ports (remote)>
<Lease Time>
<Tunnel Type>
<Initiator Cookie Range>
[Message ID]
In response to the optional port requests, the server MUST
assign only one port.
RSIP support for IKE requires the following new parameters:
Number of Initiator Cookies
Code Length Number of Initiator Cookies
+------+--------+-----------------------------+
| 20 | 2 | (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
Expires April 29, 1999 [Page 7]
INTERNET DRAFT RSIP Support for End-to-end IPSEC October 1999
Code Length Low Cookie High Cookie
+------+--------+-----------+-----------+
| 21 | 16 | (8 bytes) | (8 bytes) |
+------+--------+-----------+-----------+
Sent by the RSIP server to the client in
ASSIGN_RESPONSE_RSIKE 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_RSIPSEC
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 port range parameter (see
Appendix A).
The client may include an SPI Range parameter as a suggestion
to the server.
The format of these messages is:
<ASSIGN_REQUEST_RSAP-IP> ::= <Version>
<Message Type>
<Client ID>
<Address (local)>
<Ports (local)>
<Address (remote)>
<Ports (remote)>
<Number of SPIs>
[Lease Time]
[Tunnel Type]
[Message ID]
[SPI Range]
ASSIGN_RESPONSE_RSIPSEC
The ASSIGN_RESPONSE_IPSEC message is used by an RSIP server
to assign parameters to an IPSEC-enabled RSIP client.
Expires April 29, 1999 [Page 8]
INTERNET DRAFT RSIP Support for End-to-end IPSEC October 1999
<ASSIGN_RESPONSE_RSAP-IP> ::= <Version>
<Message Type>
<Client ID>
<Bind ID>
<Address (local)>
<Ports (local)>
<Address (remote)>
<Ports (remote)>
<Lease Time>
<Tunnel Type>
<SPI Range>
[Message ID]
Additionally, RSIP support for IPSEC requires the following
new parameters:
Number of SPIs
Code Length Number of SPIs
+------+--------+-----------------------------+
| 22 | 2 | (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.
Expires April 29, 1999 [Page 9]
INTERNET DRAFT RSIP Support for End-to-end IPSEC October 1999
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.
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 A: 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,
Expires April 29, 1999 [Page 10]
INTERNET DRAFT RSIP Support for End-to-end IPSEC October 1999
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
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.
Appendix B: RSIP Error Numbers for IKE and IPSEC Support
This section provides descriptions for the error values in the
RSIP error parameter beyond those defined in [RSIP-P].
15: COOKIEUNAVAILABLE - The RSIP server was not able to allocate
initiator cookie(s). Alternatively, the cookie range
suggested by the client was not completely available.
The server MAY offer a suggestion to the client by including
an Initiator Cookie Range that was valid at the time the
error message was being composed. This is merely a suggestion
which the client may or may not heed.
16: SPIUNAVAILABLE - The RSIP server was not able to allocate an
SPI. Alternatively, the SPI range suggested by the client was
not completely available.
The server MAY offer a suggestion to the client by including
an SPI Range that was valid at the time the error message was
being composed. This is merely a suggestion which the client
may or may not heed.
Appendix C: Message Type Values for IKE and IPSEC Support
This section defines the values assigned to RSIP message types
Expires April 29, 1999 [Page 11]
INTERNET DRAFT RSIP Support for End-to-end IPSEC October 1999
beyond those defined in [RSIP-P].
20 ASSIGN_REQUEST_RSIKE
21 ASSIGN_RESPONSE_RSIKE
22 ASSIGN_REQUEST_RSIPSEC
23 ASSIGN_RESPONSE_RSIPSEC
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,
draft-ietf-nat-traditional-03.txt, September
1999.
[NAT-TERMS] P. Srisuresh and M. Holdredge, "IP Network
Address Translator (NAT) Terminology and
Considerations," RFC 2663, August 1999.
Expires April 29, 1999 [Page 12]
INTERNET DRAFT RSIP Support for End-to-end IPSEC October 1999
[RSIP-FW] M. Borella, J. Lo, D. Grabelsky and G.
Montenegro, "Realm Specific IP: A Framework" --
work in progress,
draft-ietf-nat-rsip-framework-02.txt, October
1999.
[RSIP-P] M. Borella, D. Grabelsky, J. Lo,
K. Taniguchi, "Realm Specific IP: Protocol
Specification" -- work in progress,
draft-ietf-nat-rsip-protocol-03.txt, October
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.
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
Expires April 29, 1999 [Page 13]
INTERNET DRAFT RSIP Support for End-to-end IPSEC October 1999
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 April 29, 1999 [Page 14]
