summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3104.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3104.txt')
-rw-r--r--doc/rfc/rfc3104.txt1067
1 files changed, 1067 insertions, 0 deletions
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:
+
+ <ASSIGN_REQUEST_RSIPSEC> ::= <Version>
+ <Message Type>
+ <Overall Length>
+ <Client ID>
+ <Address (local)>
+ <Ports (local)>
+ <Address (remote)>
+ <Ports (remote)>
+ <SPI>
+ [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:
+
+ <ASSIGN_RESPONSE_RSIPSEC> ::= <Version>
+ <Message Type>
+ <Overall Length>
+ <Client ID>
+ <Bind ID>
+ <Address (local)>
+ <Ports (local)>
+ <Address (remote)>
+ <Ports (remote)>
+ <SPI>
+ <Lease Time>
+ <Tunnel Type>
+ [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]
+