Internet Engineering Task Force                            G. Montenegro
INTERNET DRAFT                                    Sun Microsystems, Inc.
                                                              M. Borella
                                                        3Com Corporation
                                                           May, 19, 1999

                   RSIP Support for End-to-end IPSEC

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

   The list of Internet-Draft Shadow Directories can be accessed


   This document proposes mechanisms that enable "Realm-Specific
   IP" (RSIP) to handle end-to-end IPSEC.

Expires November 19, 1999                                       [Page 1]

INTERNET DRAFT     RSIP Support for End-to-end IPSEC            May 1999

Table of Contents

1. Introduction ...................................................    3
2. Model ..........................................................    3
3. IKE Handling and Demultiplexing ................................    4
4. IPSEC Handling and Demultiplexing ..............................    5
5. RSIP Protocol Extensions .......................................    5
   5.1 New Messages and Parameters to Support IKE .................    6
   5.2 New Messages and Parameters to Support IPSEC ...............    7
6. Security Considerations ........................................    8
7. Acknowledgements ...............................................    9
Appendix: On Optional Port Allocation to RSIP Clients .............    9
References ........................................................   10
Author addresses ..................................................   11

Expires November 19, 1999                                       [Page 2]

INTERNET DRAFT     RSIP Support for End-to-end IPSEC            May 1999

1. Introduction

   This document specifies RSIP extensions to enable end-to-end
   IPSEC.  It assumes the RSIP framework as presented in [RSIP-FW],
   and specifies extensions to the RSIP protocol defined in
   [RSIP-P]. Other terminology follows [NAT-TERMS].

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
   "OPTIONAL" in this document are to be interpreted as described
   in RFC 2119 [9].

2. Model

   For clarity, the discussion below assumes this model:

   RSIP client              RSIP server                   Host

      Xa                    Na   Nb                       Yb
            +------------+       Nb1  +------------+
   [X]------| Addr space |----[N]-----| Addr space |-------[Y]
            |  A         |       Nb2  |  B         |
            +------------+       ...  +------------+

   Hosts X and Y belong to different address spaces A and B,
   respectively, and N is an RSIP server.  N has two addresses:
   Na on address space A, and Nb on address space B. For example,
   A could be a private address space, and B the public address
   space of the general Internet.  Additionally, N may have a
   pool of addresses in address space B which it can assign to
   or lend to X.

   The RSIP server N is not required to have more than one address
   on address space B.  RSIP allows X (and any other hosts on
   address space A) to reuse Nb. Because of this, Y's SPD SHOULD
   be configured to support session-oriented keying [Kent98c].
   Not doing so implies that only one peer may, at any given
   point in time, use address Nb when exchanging IPSEC packets
   with Y. Additionally, Y's SPD MAY be configured to support
   user-oriented keying, although other types of identifications
   within the IKE Identification Payload are equally effective
   at disambiguating who is the real client behind the single
   address Nb [Piper98].

   This document proposes RSIP extensions and mechanisms to
   enable an RSIP client X to initiate IKE and IPSEC sessions to
   a legacy IKE and IPSEC node Y. In order to do so, X exchanges

Expires November 19, 1999                                       [Page 3]

INTERNET DRAFT     RSIP Support for End-to-end IPSEC            May 1999

   RSIP protocol messages with the RSIP server N.

   This document currently does not address IKE/IPSEC session
   initiation from Y to an RSIP client X.

   The explanations below assume that the RSIP server N is
   examining a packet sent by Y, destined for X. This implies that
   in the discussion below "source" refers to Y and "destination"
   refers to Y's peer, namely, X's presence at N.

3. IKE Handling and Demultiplexing

   IKE packets are carried on UDP port 500 for both source
   and destination [ISAKMP].  Usually, UDP traffic is handled
   appropriately by NAPT [NAPT], and does not require RSIP.
   However, IKE uses a fixed source port of 500 which precludes
   that field being used for demultiplexing.  Instead, the
   "Initiator Cookie" field in the IKE header fields must be used
   for this purpose. This fields is appropriate as it is guaranteed
   to be present in every IKE exchange (Phase 1 and Phase 2),
   and is guaranteed to be in the clear (even if subsequent IKE
   payloads are encrypted).  However, it is protected by the Hash
   payload in IKE [IKE], so simply extending NAPT does not work.
   Because of this, RSIP must be used to agree upon a valid value
   for the Initiator Cookie.

   Once X and N arrive at a mutually agreeable value for the
   Initiator Cookie, X uses it to create an IKE packet and tunnels
   it the RSIP server N.  N decapsulates the IKE packet and sends
   it on address space B.

   The complete tuple negotiated via RSIP, and used for
   demultiplexing incoming IKE responses from Y at the RSIP server
   N is:

      - IKE destination port Number (usually 500)

      - Initiator Cookie

      - destination IP address

   Notice that RSIP does support alternate UDP ports (other than
   500) for IKE, as this may be useful in certain situations (e.g.
   testing purposes).

   One problem still remains: how does Y know that it is supposed
   to send packets to X via Nb? Y is not RSIP-aware, but it is

Expires November 19, 1999                                       [Page 4]

INTERNET DRAFT     RSIP Support for End-to-end IPSEC            May 1999

   definitely IKE-aware. Y sees IKE packets coming from address Nb.
   To prevent Y from mistakenly deriving the identity of its IKE
   peer based on the source address of the packets (Nb), X MUST
   exchange client identifiers with Y:

      - IDii, IDir if in Phase 1, and

      - IDci, IDcr if in Phase 2.

   The proper use of identifiers allows the clear separation
   between those identities and the source IP address of the

4. IPSEC Handling and Demultiplexing

   The RSIP client X and server N arrive at an SPI value to
   denote the incoming IPSEC security association from Y to X.
   Once N and X make sure that the SPI is unique within both of
   their SPI spaces, X communicates its value to Y as part of
   the IPSEC security association establishment process, namely,
   Quick Mode in IKE [IKE] or manual assignment.

   This ensures that Y sends IPSEC packets (protocols 51 and
   50 for AH and ESP, respectively) [Kent98a,Kent98b] to X via
   address Nb using the negotiated SPI.

   IPSEC packets (protocols 51 and 50 for AH and ESP, respectively)
   [Kent98a,Kent98b] from Y destined for X arrive at RSIP server
   N.  They are demultiplexed based on the following tuple of
   demultiplexing fields:

      - protocol (50 or 51)

      - SPI

      - destination IP address

   N is able to find a matching mapping, and tunnels the packet
   to X according to the tunneling mode in effect.

5. RSIP Protocol Extensions

   The next two sections specify how the RSIP protocol is extended
   to support both IKE (a UDP application) and the IPSEC-defined
   AH and ESP headers (layered directly over IP with their own
   protocol numbers).

Expires November 19, 1999                                       [Page 5]

INTERNET DRAFT     RSIP Support for End-to-end IPSEC            May 1999

   RSIP IKE and IPSEC messages use the same message numbers as
   ASSIGN_REQUEST and ASSIGN_RESPONSE, only with different RSIP
   methods.  These methods are called RSIKE and RSIPSEC and are
   assigned RSIP method numbers 3 and 4, respectively.

5.1 New Messages and Parameters to Support IKE

   RSIP support for IKE requires the following new message types:


      The ASSIGN_IKE_request message is used by an RSIP-client to
      request IKE parameter assignments.

      The port range parameter is optional. If not included the
      default is:

                number of ports: 1                 port number: 500

      If included, the port range MUST request only one port.

         <ASSIGN_REQUEST_IKE> ::= <Message Type> <Client ID>
                                    <RSIP method = RSIKE>
                                    <IP Address Request>
                                    <Number of Initiator Cookies>
                                    [<Number of Ports>]
                                    [<Lease Time>] [<Message ID>]


      The ASSIGN_RESPONSE_IKE message is used by an RSIP server
      to assign initiator cookies to an IKE-enabled RSIP client.

         <ASSIGN_RESPONSE_IKE> ::= <Message Type> <Client ID> <Bind ID>
                                     <RSIP method = RSIKE>
                                     <IP Address>[<Port Range>]
                                     <Initiator Cookie Range>
                                     <Lease Time> [<Message ID>]

      In response to the optional port request, the server MUST
      assign only one port.

   Additionally, RSIP support for IKE requires the following
   new parameters:

   Number of Initiator Cookies

Expires November 19, 1999                                       [Page 6]

INTERNET DRAFT     RSIP Support for End-to-end IPSEC            May 1999

        Code   Length    Number of Initiator Cookies
      |  20  |    1   |      (2 bytes)              |

      Sent by the RSIP client in ASSIGN_REQUEST_IKE messages to ask
      for a particular number of initiator cookies to be assigned.

   Initiator Cookie Range

        Code   Length   Low Cookie  High Cookie
      |  21  |   16   | (8 bytes) | (8 bytes) |

      Sent by the RSIP server to the client in ASSIGN_RESPONSE_IKE
      messages.  The cookie range MUST be contiguous and is

5.2 New Messages and Parameters to Support IPSEC

   This section defines the protocol extensions required for RSIP
   to support AH and ESP. The required message types are:


      The ASSIGN_REQUEST_IPSEC message is used by an RSIP client
      to request IPSEC parameter assignments. An RSIP client MUST
      request an IP address and SPIs in one message.

      If the RSIP client wishes to use IPSEC to protect a TCP or
      UDP application, it SHOULD use the optional port range
      parameter (see the Appendix).

      The format of these messages is:

         <ASSIGN_REQUEST_IPSEC> ::= <Message Type> <Client ID>
                                    <RSIP method = RSIPSEC>
                                    <IP Addr Req> <Number of SPIs>
                                    [<Number of Ports>]
                                    [<Lease Time>] [<Message ID>]


      The ASSIGN_RESPONSE_IPSEC message is used by an RSIP server
      to assign parameters to an IPSEC-enabled RSIP client.

Expires November 19, 1999                                       [Page 7]

INTERNET DRAFT     RSIP Support for End-to-end IPSEC            May 1999

         <ASSIGN_RESPONSE_IPSEC> ::= <Message Type> <Client ID> <Bind ID>
                                     <RSIP method = RSIPSEC>
                                     <IP Address> <SPI Range>
                                     [<Port Range>] <Lease Time>
                                     [<Message ID>]

   Additionally, RSIP support for IPSEC requires the following
   new parameters:

   Number of SPIs

        Code   Length    Number of SPIs
      |  22  |    1   |      (2 byte)               |

      Sent by the RSIP client in ASSIGN_REQUEST_IPSEC messages
      to ask for a particular number of SPIs to be assigned.

   SPI Range

        Code   Length    Low SPI     High SPI
      |  23  |    8   | (4 bytes) | (4 bytes) |

      Sent by the RSIP server in ASSIGN_RESPONSE_IPSEC messages
      to assign an SPI range.  The SPI range MUST be contiguous
      and is inclusive.

6. Security Considerations

   This document does not add any security issues to those already
   posed by NAT, or normal routing operations. Current routing
   decisions typically are based on a tuple with only one element:
   destination IP address.  This document just adds more elements
   to the tuple.  Furthermore, by allowing an end-to-end mode of
   operation and by introducing a negotiation phase to address
   reuse, the mechanisms described here are more secure and less
   arbitrary than NAT.

   A word of caution is in order: Cookie and SPI values are meant
   to be semi-random, and, thus serve also as anti-clogging
   tokens to reduce off-the-path denial-of-service attacks.
   However, RSIP support for IPSEC, renders cookies and SPI's
   a negotiated item: in addition to being unique values at the
   receiver X, they must also be unique at the RSIP server, N.

Expires November 19, 1999                                       [Page 8]

INTERNET DRAFT     RSIP Support for End-to-end IPSEC            May 1999

   Limiting the range of the cookie and SPI values available to
   the RSIP clients reduces their entropy slightly, thus (slightly)
   weakening their effectiveness as an anti-clogging token.

7. Acknowledgements

   Many thanks to Vipul Gupta, Jeffrey Lo, Dan Nessett and Gary
   Jaszewski for helpful discussions.

Appendix: On Optional Port Allocation to RSIP Clients

   Despite the fact that SPIs rather than ports are used to
   demultiplex packets at the RSIP server, the RSIP server may
   still allocate mutually exclusive port numbers to the RSIP
   clients. If this does not happen, there is the possibility that
   two RSIP clients using the same IP address attempt an IPSEC
   session with the same public server using the same source
   port numbers.

   | RSIP client |
   |       1     +--+
   |  |  |         +-------------+
   +-------------+  | |             |
                    +---------+ RSIP server +----------------
   +-------------+  |         |             |
   | RSIP client |  |         +-------------+
   |       2     +--+ private                     public
   |  |  | network                     network
   +-------------+  |

   For example, consider hosts and in the
   architecture depicted above.  Assume that they both are
   using public address and both are contacting an
   external server 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  Assume client 1 does so first,
   and after engaging in an IKE negotiation begins communicating
   with the public server using IPSEC. When Client 2 starts its IKE
   session, it sends its identification to the public server. The
   latter's SPD requires that different identities use different
   flows (port numbers). Because of this, the IKE negotiation
   will fail. Client 2 will be forced to try another ephemeral

Expires November 19, 1999                                       [Page 9]

INTERNET DRAFT     RSIP Support for End-to-end IPSEC            May 1999

   port until it succeeds in obtaining one which is currently not
   in use by any other security association between the public
   server and any of the RSIP clients in the private network.

   Each such iteration is costly in terms of round-trip times and
   CPU usage.  Hence --and as a convenience to its RSIP clients--,
   an RSIP server may also assign mutually exclusive port numbers
   to its IPSEC RSIP clients.

   Despite proper allocation of port numbers, an RSIP server
   cannot prevent RSIP clients using encryption from using any
   port number, since it cannot examine the port fields. However,
   it is in the RSIP clients' best interest to adhere to these
   port assignments (when they are available) in order to avoid
   costly conflicts and the resultant renegotiations.


    [ISAKMP]       Maughhan, D., Schertler, M., Schneider, M.,
                   and Turner, J., "Internet Security Association
                   and Key Management Protocol (ISAKMP)," RFC 2408,
                   November 1998.

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

    [Kent98a]      S. Kent, R. Atkinson, "IP Encapsulating
                   Payload," RFC 2406, November 1998 (obsoletes
                   RFC 1827, August 1995).

    [Kent98b]      S. Kent, R. Atkinson, "IP Authentication
                   Header," RFC 2402, November 1998 (obsoletes
                   RFC 1826, August 1995).

    [Kent98c]      S. Kent, R. Atkinson, "Security Architecture
                   for the Internet Protocol," RFC 2401, November
                   1998 (obsoletes RFC 1827, August 1995).

    [Piper98]      D. Piper, "The Internet IP Security Domain of
                   Interpretation for ISAKMP," RFC 2407, November

    [NAPT]         P. Srisuresh and K. Egevang, "Traditional IP
                   Network Address Translator (Traditional NAT)" --
                   work in progress,

Expires November 19, 1999                                      [Page 10]

INTERNET DRAFT     RSIP Support for End-to-end IPSEC            May 1999

                   draft-ietf-nat-traditional-01.txt, October

    [NAT-TERMS]    P. Srisuresh and M. Holdredge, "IP Network
                   Address Translator (NAT) Terminology and
                   Considerations Translator (NAT)" -- work in
                   progress, draft-ietf-nat-terminology-02.txt,
                   April 1999.

    [RSIP-FW]      J. Lo, M. Borella and D. Grabelsky, "Realm
                   Specific IP: A Framework" -- work in progress,
                   draft-ietf-nat-rsip-framework-01.txt, May 1999.

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

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


          Michael Borella
          3Com Corp.
          1800 W. Central Rd.
          Mount Prospect IL 60056
          Voice:  +1-847 342-6093


Copyright (c) The Internet Society (1999). All Rights Reserved.

Expires November 19, 1999                                      [Page 11]

INTERNET DRAFT     RSIP Support for End-to-end IPSEC            May 1999

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than

   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

Expires November 19, 1999                                      [Page 12]