[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 RFC 3104

Internet Engineering Task Force                            G. Montenegro
INTERNET DRAFT                                    Sun Microsystems, Inc.
                                                              M. Borella
                                                        3Com Corporation
                                                           February 2000

                   RSIP Support for End-to-end IPsec
                    draft-ietf-nat-rsip-ipsec-02.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 June 2000                                               [Page 1]

INTERNET DRAFT     RSIP Support for End-to-end IPsec       February 2000


Table of Contents

1. Introduction ...................................................    3
2. Model ..........................................................    3
3. Implementation Notes ...........................................    4
4. IKE Handling and Demultiplexing ................................    5
5. IPsec Handling and Demultiplexing ..............................    6
6. RSIP Protocol Extensions .......................................    6
   6.1 IKE Support in RSIP ........................................    7
   6.2 IPsec Support in RSIP ......................................    8
7. IANA Considerations ............................................   10
8. Security Considerations ........................................   10
9. Acknowledgements ...............................................   11
Appendix A: On Optional Port Allocation to RSIP Clients ...........   11
Appendix B: RSIP Error Numbers for IKE and IPsec Support ..........   12
Appendix C: Message Type Values for IPsec Support .................   12
Appendix D: A Note on Flow Policy Enforcement .....................   13
Appendix E: Remote Host Rekeying ..................................   13
Appendix F: Example Application Scenarios .........................   14
Appendix G: Thoughts on Supporting Incoming Connections ...........   15
References ........................................................   17
Author addresses ..................................................   18





























Expires June 2000                                               [Page 2]

INTERNET DRAFT     RSIP Support for End-to-end IPsec       February 2000


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         |
            +------------+       ...  +------------+

   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,



Expires June 2000                                               [Page 3]

INTERNET DRAFT     RSIP Support for End-to-end IPsec       February 2000


   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 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 accomodate 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



Expires June 2000                                               [Page 4]

INTERNET DRAFT     RSIP Support for End-to-end IPsec       February 2000


        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:

      - 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.



Expires June 2000                                               [Page 5]

INTERNET DRAFT     RSIP Support for End-to-end IPsec       February 2000


   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.


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



Expires June 2000                                               [Page 6]

INTERNET DRAFT     RSIP Support for End-to-end IPsec       February 2000


   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.

   The probability of an Initiator Cookie collision at N and
   subsequent retransmissions by X, is infinitessimal 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.




Expires June 2000                                               [Page 7]

INTERNET DRAFT     RSIP Support for End-to-end IPsec       February 2000


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.

      The format of this message is:

      <ASSIGN_REQUEST_RSIPSEC> ::= <Version>
                                   <Message Type>
                                   <Client ID>
                                   <Address (local)>
                                   <Ports (local)>
                                   <Address (remote)>
                                   <Ports (remote)>
                                   <SPI>
                                   [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.




Expires June 2000                                               [Page 8]

INTERNET DRAFT     RSIP Support for End-to-end IPsec       February 2000


         - 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.

      The format of this message is:

      <ASSIGN_RESPONSE_RSIPSEC> ::= <Version>
                                    <Message Type>
                                    <Client ID>
                                    <Bind ID>
                                    <Address (local)>
                                    <Ports (local)>
                                    <Address (remote)>
                                    <Ports (remote)>
                                    <SPI>
                                    <Lease Time>
                                    <Tunnel Type>

      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



Expires June 2000                                               [Page 9]

INTERNET DRAFT     RSIP Support for End-to-end IPsec       February 2000


   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.

   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



Expires June 2000                                              [Page 10]

INTERNET DRAFT     RSIP Support for End-to-end IPsec       February 2000


   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 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 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



Expires June 2000                                              [Page 11]

INTERNET DRAFT     RSIP Support for End-to-end IPsec       February 2000


   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.

   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







Expires June 2000                                              [Page 12]

INTERNET DRAFT     RSIP Support for End-to-end IPsec       February 2000


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 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 occurances 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.





Expires June 2000                                              [Page 13]

INTERNET DRAFT     RSIP Support for End-to-end IPsec       February 2000


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
                 |
                 |

   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.















Expires June 2000                                              [Page 14]

INTERNET DRAFT     RSIP Support for End-to-end IPsec       February 2000


   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).


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 client 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 only be
   registered and used by only one RSIP system (including clients
   and server).




Expires June 2000                                              [Page 15]

INTERNET DRAFT     RSIP Support for End-to-end IPsec       February 2000


   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 the 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 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.





Expires June 2000                                              [Page 16]

INTERNET DRAFT     RSIP Support for End-to-end IPsec       February 2000


References

    [Gupta]        Gupta, V., "Secure Remote Access over the
                   Internet using IPSec," -- work in progress,
                   draft-gupta-ipsec-remote-access-03.txt,
                   Oct, 1999.

    [IKE]          Harkins, D., Carrel, D., "The Internet Key
                   Exchange (IKE)," RFC 2409, November 1998.

    [ISAKMP]       Maughan, D., Schertler, M., Schneider, M.,
                   and Turner, J., "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]      T. Jenkins, "IPsec Rekeying Issues," -- work in
                   progress, draft-jenkins-ipsec-rekeying-03.txt,
                   January 2000.

    [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



Expires June 2000                                              [Page 17]

INTERNET DRAFT     RSIP Support for End-to-end IPsec       February 2000


                   Considerations," RFC 2663, August 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-03.txt,
                   December 1999.

    [RSIP-P]       M. Borella, D. Grabelsky, J. Lo,
                   K. Taniguchi, "Realm Specific IP: Protocol
                   Specification" -- work in progress,
                   draft-ietf-nat-rsip-protocol-05.txt, January
                   2000.


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 (2000). 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



Expires June 2000                                              [Page 18]

INTERNET DRAFT     RSIP Support for End-to-end IPsec       February 2000


   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 June 2000                                              [Page 19]


Html markup produced by rfcmarkup 1.111, available from https://tools.ietf.org/tools/rfcmarkup/