rfc3104.txt

RFC 的详细文档！

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