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_RESPONSE_IKE The ASSIGN_RESPONSE_IKE message is used by an RSIP server to assign initiator cookies to an IKE-enabled RSIP client. ::= [] [] 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_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 ::= [] [] 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]