rfc3104.txt

RFC 的详细文档！

   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:<[e-mail]>,
               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: [phone]
   EMail: [e-mail]


   Michael Borella
   CommWorks
   3800 Golf Rd.
   Rolling Meadows IL 60008

   Phone: [phone]
   EMail: [e-mail]































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