From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3104.txt | 1067 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1067 insertions(+) create mode 100644 doc/rfc/rfc3104.txt (limited to 'doc/rfc/rfc3104.txt') diff --git a/doc/rfc/rfc3104.txt b/doc/rfc/rfc3104.txt new file mode 100644 index 0000000..2860262 --- /dev/null +++ b/doc/rfc/rfc3104.txt @@ -0,0 +1,1067 @@ + + + + + + +Network Working Group G. Montenegro +Request for Comments: 3104 Sun Microsystems, Inc. +Category: Experimental M. Borella + CommWorks + October 2001 + + + RSIP Support for End-to-end IPsec + +Status of this Memo + + This memo defines an Experimental Protocol for the Internet + community. It does not specify an Internet standard of any kind. + Discussion and suggestions for improvement are requested. + Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2001). All Rights Reserved. + +IESG Note + + The IESG notes that the set of documents describing the RSIP + technology imply significant host and gateway changes for a complete + implementation. In addition, the floating of port numbers can cause + problems for some applications, preventing an RSIP-enabled host from + interoperating transparently with existing applications in some cases + (e.g., IPsec). Finally, there may be significant operational + complexities associated with using RSIP. Some of these and other + complications are outlined in section 6 of the RFC 3102, as well as + in the Appendices of RFC 3104. Accordingly, the costs and benefits + of using RSIP should be carefully weighed against other means of + relieving address shortage. + +Abstract + + This document proposes mechanisms that enable Realm Specific IP + (RSIP) to handle end-to-end IPsec (IP Security). + + + + + + + + + + + + + +Montenegro & Borella Experimental [Page 1] + +RFC 3104 RSIP Support for End-to-end IPsec October 2001 + + +Table of Contents + + 1. Introduction .................................................. 2 + 2. Model ......................................................... 2 + 3. Implementation Notes .......................................... 3 + 4. IKE Handling and Demultiplexing ............................... 4 + 5. IPsec Handling and Demultiplexing ............................. 5 + 6. RSIP Protocol Extensions ...................................... 6 + 6.1 IKE Support in RSIP ....................................... 6 + 6.2 IPsec Support in RSIP ..................................... 7 + 7. IANA Considerations ........................................... 10 + 8. Security Considerations ....................................... 10 + 9. Acknowledgements .............................................. 10 + References ....................................................... 11 + Authors' Addresses ............................................... 12 + Appendix A: On Optional Port Allocation to RSIP Clients .......... 13 + Appendix B: RSIP Error Numbers for IKE and IPsec Support ......... 14 + Appendix C: Message Type Values for IPsec Support ................ 14 + Appendix D: A Note on Flow Policy Enforcement .................... 14 + Appendix E: Remote Host Rekeying ................................. 14 + Appendix F: Example Application Scenarios ........................ 15 + Appendix G: Thoughts on Supporting Incoming Connections .......... 17 + Full Copyright Statement ......................................... 19 + +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. + +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 | + +------------+ ... +------------+ + + + + + +Montenegro & Borella Experimental [Page 2] + +RFC 3104 RSIP Support for End-to-end IPsec October 2001 + + + 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. + + 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 RSIP protocol messages + with the RSIP server N. This document does not yet address IKE/IPsec + session initiation from Y to an RSIP client X. For some thoughts on + this matter see Appendix G. + + The discussion below assumes that the RSIP server N is examining a + packet sent by Y, destined for X. This implies that "source" refers + to Y and "destination" refers to Y's peer, namely, X's presence at N. + + This document assumes the use of the RSAP-IP flavor of RSIP (except + that port number assignments are optional), on top of which SPI + values are used for demultiplexing. Because of this, more than one + RSIP client may share the same global IP address. + +3. Implementation Notes + + 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 NOT be configured to + support address-based keying. Address-based keying implies that only + one RSIP client may, at any given point in time, use address Nb when + exchanging IPsec packets with Y. Instead, Y's SPD SHOULD be + configured to support session-oriented keying, or user-oriented + keying [Kent98c]. In addition to user-oriented keying, 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]. + + Because it cannot rely on address-based keying, RSIP support for + IPsec is similar to the application of IPsec for remote access using + dynamically assigned addresses. Both cases impose additional + requirements which are not met by minimally compliant IPsec + implementations [Gupta]: + + Note that a minimally-compliant IKE implementation (which only + implements Main mode with Pre-shared keys for Phase I + authentication) cannot be used on a remote host with a dynamically + assigned address. The IKE responder (gateway) needs to look up + the initiator's (mobile node's) pre-shared key before it can + + + +Montenegro & Borella Experimental [Page 3] + +RFC 3104 RSIP Support for End-to-end IPsec October 2001 + + + decrypt the latter's third main mode message (fifth overall in + Phase I). Since the initiator's identity is contained in the + encrypted message, only its IP address is available for lookup and + must be predictable. Other options, such as Main mode with + digital signatures/RSA encryption and Aggressive mode, can + accommodate IKE peers with dynamically assigned addresses. + + IKE packets are typically carried on UDP port 500 for both source and + destination, although the use of ephemeral source ports is not + precluded [ISAKMP]. IKE implementations for use with RSIP SHOULD + employ ephemeral ports, and should handle them as follows [IPSEC- + MSG]: + + IKE implementations MUST support UDP port 500 for both source and + destination, but other port numbers are also allowed. If an + implementation allows other-than-port-500 for IKE, it sets the + value of the port numbers as reported in the ID payload to 0 + (meaning "any port"), instead of 500. UDP port numbers (500 or + not) are handled by the common "swap src/dst port and reply" + method. + + It is important to note that IPsec implementations MUST be aware of + RSIP, at least in some peripheral sense, in order to receive assigned + SPIs and perhaps other parameters from an RSIP client. Therefore, + bump-in-the-stack (BITS) implementations of IPsec are not expected to + work "out of the box" with RSIP. + +4. IKE Handling and Demultiplexing + + If an RSIP client requires the use of port 500 as its IKE source, + this prevents that field being used for demultiplexing. Instead, the + "Initiator Cookie" field in the IKE header fields must be used for + this purpose. This field 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]. Because of this, an RSIP client and server must 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 minimum tuple negotiated via RSIP, and used for demultiplexing + incoming IKE responses from Y at the RSIP server N, is: + + + + + +Montenegro & Borella Experimental [Page 4] + +RFC 3104 RSIP Support for End-to-end IPsec October 2001 + + + - IKE destination port number + + - Initiator Cookie + + - Destination IP address + + 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. + +5. IPsec Handling and Demultiplexing + + The RSIP client X and server N must 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 from Y destined for X arrive at RSIP server N. They + are demultiplexed based on the following minimum tuple of + demultiplexing fields: + + - protocol (50 or 51) + + - SPI + + - destination IP address + + If N is able to find a matching mapping, it tunnels the packet to X + according to the tunneling mode in effect. If N cannot find an + appropriate mapping, it MUST discard the packet. + + + + + +Montenegro & Borella Experimental [Page 5] + +RFC 3104 RSIP Support for End-to-end IPsec October 2001 + + +6. 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 RSIP Method parameter for RSIP with + IPsec in the REGISTER_RESPONSE method sent to the client. This + method is assigned a value of 3: + + 3 RSIP with IPsec (RSIPSEC) + + Unless otherwise specified, requirements of micro and macro flow- + based policy are handled according to [RSIP-P]. + +6.1 IKE Support in RSIP + + As discussed above, if X's IPsec implementation allows use of an + ephemeral source port for IKE, then incoming IKE traffic can be + demultiplexed by N based on the destination address and port tuple. + This is the simplest and most desirable way of supporting IKE, and + IPsec implementations that interact with RSIP SHOULD allow it. + + However, if X must use source port 500 for IKE, there are two + techniques with which X and N can arrive at a mutually unique + Initiator Cookie. + + - Trial and error. + + - Negotiation via an extension of the RSIP protocol. + + The trial and error technique consists of X first obtaining resources + with which to use IPsec (via ASSIGN_REQUEST_RSIPSEC, defined below), + and then randomly choosing an Initiator Cookie and transmitting the + first packet to Y. Upon arrival at N, the RSIP server examines the + Initiator Cookie for uniqueness per X's assigned address (Nb). If + the cookie is unique, N allows the use of this cookie for this an all + subsequent packets between X and Y on this RSIP binding. If the + cookie is not unique, N drops the packet. + + When an IKE packet is determined to be lost, the IKE client will + attempt to retransmit at least three times [IKE]. An RSIP-aware IKE + client SHOULD use different Initiator Cookies for each of these + retransmissions. + + + + + +Montenegro & Borella Experimental [Page 6] + +RFC 3104 RSIP Support for End-to-end IPsec October 2001 + + + The probability of an Initiator Cookie collision at N and subsequent + retransmissions by X, is infinitesimal given the 64-bit cookie space. + According to the birthday paradox, in a population of 640 million + RSIP clients going through the same RSIP server, the chances of a + first collision is just 1%. Thus, it is desirable to use the trial + and error method over negotiation, for these reasons: + + - Simpler implementation requirements + + - It is highly unlikely that more than one round trip between X + and N will be necessary. + +6.2 IPsec Support in RSIP + + This section defines the protocol extensions required for RSIP to + support AH and ESP. The required message types are + ASSIGN_REQUEST_RSIPSEC and ASSIGN_RESPONSE_RSIPSEC: + + ASSIGN_REQUEST_RSIPSEC + + The ASSIGN_REQUEST_RSIPSEC 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 MUST use the port range parameter (see Appendix + A). Otherwise, it MUST set the port parameters to the "don't + need" value. This is accomplished by setting the length field to + 0, and by omitting both the number field and the port field. This + informs the server that the client does not actually need any port + assignments. + + The client may initialize the SPI parameter to the "don't care" + value (see below). In this case, it is requesting the server to + assign it a valid SPI value to use. + + Alternatively, the client may initialize the SPI parameter to a + value it considers valid. In this case, it is suggesting that + value to the server. Of course, the server may choose to reject + that suggestion and return an appropriate error message. + + + + + + + + + + + +Montenegro & Borella Experimental [Page 7] + +RFC 3104 RSIP Support for End-to-end IPsec October 2001 + + + The format of this message is: + + ::= + + + +
+ +
+ + + [Message Counter] + [Lease Time] + [Tunnel Type] + + The following message-specific error conditions exist. The error + behavior of ASSIGN_REQUEST_RSIP_IPSEC follows that of + ASSIGN_REQUEST_RSAP-IP for all non-IPsec errors. + + - If the client is not allowed to use IPsec through the server, + the server MUST respond with an ERROR_RESPONSE containing the + IPSEC_UNALLOWED parameter. + + - If the SPI parameter is a "don't care" value and the RSIP + server cannot allocate ANY SPIs, the RSIP server MUST respond + with an ERROR_RESPONSE containing the IPSEC_SPI_UNAVAILABLE + error. + + - If an SPI parameter is not a "don't care" value and the RSIP + server cannot allocate it because the requested address and SPI + tuple is in use, the RSIP server MUST respond with an + ERROR_RESPONSE containing the IPSEC_SPI_INUSE error. + + ASSIGN_RESPONSE_RSIPSEC + + The ASSIGN_RESPONSE_RSIPSEC message is used by an RSIP server to + assign parameters to an IPsec-enabled RSIP client. + + + + + + + + + + + + + + +Montenegro & Borella Experimental [Page 8] + +RFC 3104 RSIP Support for End-to-end IPsec October 2001 + + + The format of this message is: + + ::= + + + + +
+ +
+ + + + + [Address (tunnel endpoint)] + [Message Counter] + + If the port parameters were set to the "don't need" value in the + request (see above), the RSIP server must do the same in the + response. + + Additionally, RSIP support for IPsec requires the following new + parameter: + + SPI + Code Length Number SPI SPI + +------+--------+---------+---------+ +---------+ + | 22 | 2 | 2 bytes | 4 bytes | ... | 4 bytes | + +------+--------+---------+---------+ +---------+ + + Sent by the RSIP client in ASSIGN_REQUEST_RSIPSEC messages to ask for + a particular number of SPIs to be assigned. Also sent by the RSIP + server to the client in ASSIGN_RESPONSE_RSIPSEC messages. + + The "SPI" fields encode one or more SPIs. When a single SPI is + specified, the value of the number field is 1 and there is one SPI + field following the number field. When more than one SPI is + specified, the value of the number field will indicate the total + number of SPIs contained, and the parameter may take one of two + forms. If there is one SPI field, the SPIs specified are considered + to be contiguous starting at the SPI number specified in the SPI + field. Alternatively, there may be a number of SPI fields equal to + the value of the number field. The number of SPI fields can be + extrapolated from the value of the length field. + + + + + + + +Montenegro & Borella Experimental [Page 9] + +RFC 3104 RSIP Support for End-to-end IPsec October 2001 + + + In some cases, it is necessary to specify a "don't care" value for + one or more SPIs. This is accomplished by setting the length field + to 2 (to account for the 2 bytes in the Number field), setting the + number field to the number of SPIs necessary, and omitting all SPI + fields. The value of the number field MUST be greater than or equal + to one. + +7. IANA Considerations + + All of the designations below are tentative. + + - RSIP IPsec error codes (see below). + + - ASSIGN_REQUEST_RSIP_IPSEC message type code. + + - SPI parameter code. + +8. 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: 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 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 SPI values available to the RSIP clients + reduces their entropy slightly. + +9. Acknowledgements + + Many thanks to Bernard Aboba, Vipul Gupta, Jeffrey Lo, Dan Nessett, + Gary Jaszewski and Prakash Iyer for helpful discussions. + + + + + + + + + + + +Montenegro & Borella Experimental [Page 10] + +RFC 3104 RSIP Support for End-to-end IPsec October 2001 + + +References + + [Gupta] Gupta, V., "Secure Remote Access over the Internet using + IPSec", Work in Progress. + + [IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange + (IKE)", RFC 2409, November 1998. + + [ISAKMP] Maughan, D., Schertler, M., Schneider, M. and J. Turner, + "Internet Security Association and Key Management + Protocol (ISAKMP)", RFC 2408, November 1998. + + [IPSEC-MSG] Ted Ts'o, message to the IETF's IPsec mailing list, + Message-Id:<199911232216.RAA01932@trampoline.thunk.org>, + November 23, 1999. + + [Jenkins] Jenkins, T., "IPsec Rekeying Issues", Work in Progress. + + [Kent98a] Kent, S. and R. Atkinson, "IP Encapsulating Payload", RFC + 2406, November 1998. + + [Kent98b] Kent, S. and R. Atkinson, "IP Authentication Header", RFC + 2402, November 1998. + + [Kent98c] Kent, S. and R. Atkinson, "Security Architecture for the + Internet Protocol", RFC 2401, November 1998. + + [Piper98] Piper, D., "The Internet IP Security Domain of + Interpretation for ISAKMP", RFC 2407, November 1998. + + [NAPT] Srisuresh, P. and K. Egevang, "Traditional IP Network + Address Translator (Traditional NAT)", RFC 3022, January + 2001. + + [NAT-TERMS] Srisuresh, P. and M. Holdredge, "IP Network Address + Translator (NAT) Terminology and Considerations", RFC + 2663, August 1999. + + [RSIP-FW] Borella, M., Lo, J., Grabelsky, D. and G. Montenegro, + "Realm Specific IP: A Framework", RFC 3102, October 2001. + + [RSIP-P] Borella, M., Grabelsky, D., Lo, J. and K. Taniguchi, + "Realm Specific IP: Protocol Specification", RFC 3103, + October 2001. + + + + + + + +Montenegro & Borella Experimental [Page 11] + +RFC 3104 RSIP Support for End-to-end IPsec October 2001 + + +Authors' Addresses + + Gabriel E. Montenegro + Sun Microsystems + Laboratories, Europe + 29, chemin du Vieux Chene + 38240 Meylan + FRANCE + + Phone: +33 476 18 80 45 + EMail: gab@sun.com + + + Michael Borella + CommWorks + 3800 Golf Rd. + Rolling Meadows IL 60008 + + Phone: (847) 262-3083 + EMail: mike_borella@commworks.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Montenegro & Borella Experimental [Page 12] + +RFC 3104 RSIP Support for End-to-end IPsec October 2001 + + +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 server using the same source port + numbers. + + +-------------+ + | RSIP client | + | X1 +--+ + | | | +-------------+ + +-------------+ | | |Nb + +---------+ RSIP server +---------------- + +-------------+ | | N | + | RSIP client | | +-------------+ + | X2 +--+ private public + | | | network network + +-------------+ | + | + | + + For example, consider hosts X1 and X2 depicted above. Assume that + they both are using public address Nb, and both are contacting an + external server Y at 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 Y at port 80. + Assume client X1 does so first, and after engaging in an IKE + negotiation begins communicating with the public server using IPsec. + + When Client X2 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 X2 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. + + + + + + + +Montenegro & Borella Experimental [Page 13] + +RFC 3104 RSIP Support for End-to-end IPsec October 2001 + + + Despite proper allocation of port numbers, an RSIP server cannot + prevent their misuse because it cannot examine the port fields in + packets that have been encrypted by the RSIP clients. Presumably, if + the RSIP clients have gone through the trouble of negotiating ports + numbers, it is in their best interest to adhere to these assignments. + +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]. + + 401: IPSEC_UNALLOWED. The server will not allow the client + to use end-to-end IPsec. + + 402: IPSEC_SPI_UNAVAILABLE. The server does not have an SPI + available for client use. + + 403: IPSEC_SPI_INUSE. The client has requested an SPI that + another client is currently using. + +Appendix C: Message Type Values for IPsec Support + + This section defines the values assigned to RSIP message types beyond + those defined in [RSIP-P]. + + 22 ASSIGN_REQUEST_RSIPSEC + + 23 ASSIGN_RESPONSE_RSIPSEC + +Appendix D: A Note on Flow Policy Enforcement + + An RSIP server may not be able to enforce local or remote micro-flow + policy when a client uses ESP for end-to-end encryption, since all + TCP/UDP port numbers will be encrypted. However, if AH without ESP + is used, micro-flow policy is enforceable. Macro-flow policy will + always be enforceable. + +Appendix E: Remote Host Rekeying + + Occasionally, a remote host with which an RSIP client has established + an IPsec security association (SA) will rekey [Jenkins]. SA rekeying + is only an issue for RSIP when IKE port 500 is used by the client and + the rekey is of ISAKMP phase 1 (the ISAKMP SA). The problem is that + the remote host will transmit IKE packets to port 500 with a new + initiator cookie. The RSIP server will not have a mapping for the + cookie, and SHOULD drop the the packets. This will cause the ISAKMP + + + + + +Montenegro & Borella Experimental [Page 14] + +RFC 3104 RSIP Support for End-to-end IPsec October 2001 + + + SA between the RSIP client and remote host to be deleted, and may + lead to undefined behavior given that current implementations handle + rekeying in a number of different ways. + + If the RSIP client uses an ephemeral source port, rekeying will not + be an issue for RSIP. If this cannot be done, there are a number of + RSIP client behaviors that may reduce the number of occurrences of + this problem, but are not guaranteed to eliminate it. + + - The RSIP client's IKE implementation is given a smaller ISAKMP + SA lifetime than is typically implemented. This would likely + cause the RSIP client to rekey the ISAKMP SA before the remote + host. Since the RSIP client chooses the Initiator Cookie, + there will be no problem routing incoming traffic at the RSIP + server. + + - The RSIP client terminates the ISAKMP SA as soon as the first + IPsec SA is established. This may alleviate the situation to + some degree if the SA is coarse-grained. On the other hand, + this exacerbates the problem if the SA is fine-grained (such + that it cannot be reused by other application-level + connections), and the remote host needs to initialize sockets + back to the RSIP client. + + Note that the unreliability of UDP essentially makes the ephemeral + source approach the only robust solution. + +Appendix F: Example Application Scenarios + + This section briefly describes some examples of how RSIP may be used + to enable applications of IPsec that are otherwise not possible. + + The SOHO (small office, home office) scenario + --------------------------------------------- + + +----------+ + |RSIP | + |client X1 +--+ + | | | +-------------+ +-------+ + +----------+ | |NAPT gateway | |public | + +--+ and +--.......---+IPsec | + +----------+ | |RSIP server | |peer Y | + |RSIP | | +-------------+ +-------+ + |client X2 +--+ private public + | | | "home" Internet + +----------+ | network + | + | + + + +Montenegro & Borella Experimental [Page 15] + +RFC 3104 RSIP Support for End-to-end IPsec October 2001 + + + Suppose the private "home" network is a small installation in + somebody's home, and that the RSIP clients X1 and X2 must use the + RSIP server N as a gateway to the outside world. N is connected via + an ISP and obtains a single address which must be shared by its + clients. Because of this, N has NAPT, functionality. Now, X1 wishes + to establish an IPsec SA with peer Y. This is possible because N is + also an RSIP server augmented with the IPsec support defined in this + document. Y is IPsec-capable, but is not RSIP aware. This is + perhaps the most typical application scenario. + + The above is equally applicable in the ROBO (remote office, branch + office) scenario. + + The Roadwarrior scenario + ------------------------ + + +---------+ +------------+ +----------+ + |RSIP | |Corporate | | IPsec | + |client X +--..........--+Firewall +---+ peer Y | + | | public | and | | (user's | + +---------+ Internet |RSIP server | | desktop) | + | N | | | + +------------+ +----------+ + private corporate + network + + In this example, a remote user with a laptop gains access to the + Internet, perhaps by using PPP or DHCP. The user wants to access its + corporation private network. Using mechanisms not specified in this + document, the RSIP client in the laptop engages in an RSIP + authentication and authorization phase with the RSIP server at the + firewall. After that phase is completed, the IPsec extensions to + RSIP defined here are used to establish an IPsec session with a peer, + Y, that resides within the corporation's network. Y could be, for + example, the remote user's usual desktop when at the office. The + corporate firewall complex would use RSIP to selectively enable IPsec + traffic between internal and external systems. + + Note that this scenario could also be reversed in order to allow an + internal system (Y) to initiate and establish an IPsec session with + an external IPsec peer (X). + + + + + + + + + + +Montenegro & Borella Experimental [Page 16] + +RFC 3104 RSIP Support for End-to-end IPsec October 2001 + + +Appendix G: Thoughts on Supporting Incoming Connections + + Incoming IKE connections are much easier to support if the peer Y can + initiate IKE exchanges to a port other than 500. In this case, the + RSIP client would allocate that port at the RSIP server via + ASSIGN_REQUEST_RSAP-IP. Alternatively, if the RSIP client is able to + allocate an IP address at the RSIP server via ASSIGN_REQUEST_RSA-IP, + Y could simply initiate the IKE exchange to port 500 at that address. + + If there is only one address Nb that must be shared by the RSIP + server and all its clients, and if Y can only send to port 500, the + problem is much more difficult. At any given time, the combination + of address Nb and UDP port 500 may be registered and used by only one + RSIP system (including clients and server). + + Solving this issue would require demultiplexing the incoming IKE + connection request based on something other than the port and address + combination. It may be possible to do so by first registering an + identity with a new RSIP command of LISTEN_RSIP_IKE. Note that the + identity could not be that of the IKE responder (the RSIP client), + but that of the initiator (Y). The reason is that IKE Phase 1 only + allows the sender to include its own identity, not that of the + intended recipient (both, by the way, are allowed in Phase 2). + Furthermore, the identity must be in the clear in the first incoming + packet for the RSIP server to be able to use it as a demultiplexor. + This rules out all variants of Main Mode and Aggressive Mode with + Public Key Encryption (and Revised Mode of Public Key Encryption), + since these encrypt the ID payload. + + The only Phase 1 variants which enable incoming IKE sessions are + Aggressive Mode with signatures or with pre-shared keys. Because + this scheme involves the RSIP server demultiplexing based on the + identity of the IKE initiator, it is conceivable that only one RSIP + client at a time may register interest in fielding requests from any + given peer Y. Furthermore, this precludes more than one RSIP client' + s being available to any unspecified peer Y. + + Once the IKE session is in place, IPsec is set up as discussed in + this document, namely, by the RSIP client and the RSIP server + agreeing on an incoming SPI value, which is then communicated to the + peer Y as part of Quick Mode. + + The alternate address and port combination must be discovered by the + remote peer using methods such as manual configuration, or the use of + KX (RFC2230) or SRV (RFC2052) records. It may even be possible for + the DNS query to trigger the above mechanisms to prepare for the + incoming and impending IKE session initiation. Such a mechanism + would allow more than one RSIP client to be available at any given + + + +Montenegro & Borella Experimental [Page 17] + +RFC 3104 RSIP Support for End-to-end IPsec October 2001 + + + time, and would also enable each of them to respond to IKE + initiations from unspecified peers. Such a DNS query, however, is + not guaranteed to occur. For example, the result of the query could + be cached and reused after the RSIP server is no longer listening for + a given IKE peer's identity. + + Because of the limitations implied by having to rely on the identity + of the IKE initiator, the only practical way of supporting incoming + connections is for the peer Y to initiate the IKE session at a port + other than 500. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Montenegro & Borella Experimental [Page 18] + +RFC 3104 RSIP Support for End-to-end IPsec October 2001 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2001). 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 + 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Montenegro & Borella Experimental [Page 19] + -- cgit v1.2.3