rfc3104.txt

RFC 的详细文档！

   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]