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 ::=
[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. ::=
[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: ::=
[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 ::=
[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]