rfc2207.txt

RFC 的详细文档！

Network Working Group                                     L. Berger
Request for Comments: 2207                             FORE Systems
Category: Standards Track                               T. O'Malley
                                                                BBN
                                                     September 1997


                  RSVP Extensions for IPSEC Data Flows


Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.



Abstract

   This document presents extensions to Version 1 of RSVP.  These
   extensions permit support of individual data flows using RFC 1826, IP
   Authentication Header (AH) or RFC 1827, IP Encapsulating Security
   Payload (ESP).  RSVP Version 1 as currently specified can support the
   IPSEC protocols, but only on a per address, per protocol basis not on
   a per flow basis.  The presented extensions can be used with both
   IPv4 and IPv6.






















Berger & O'Malley           Standards Track                     [Page 1]

RFC 2207               RSVP Extensions for IPSEC          September 1997


Table of Contents

   1   Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
   2   Overview of Extensions . . . . . . . . . . . . . . . . . . 3
   3   Object Definition. . . . . . . . . . . . . . . . . . . . . 4
       3.1  SESSION Class . . . . . . . . . . . . . . . . . . . . 5
       3.2  FILTER_SPEC Class . . . . . . . . . . . . . . . . . . 5
       3.3  SENDER_TEMPLATE Class . . . . . . . . . . . . . . . . 6
   4   Processing Rules . . . . . . . . . . . . . . . . . . . . . 6
       4.1  Required Changes. . . . . . . . . . . . . . . . . . . 6
       4.2  Merging Flowspecs . . . . . . . . . . . . . . . . . . 7
       4.2.1  FF and SE Styles. . . . . . . . . . . . . . . . . . 7
       4.2.2  WF Styles . . . . . . . . . . . . . . . . . . . . . 8
   5   IANA Considerations. . . . . . . . . . . . . . . . . . . . 8
   6   Security Considerations. . . . . . . . . . . . . . . . . . 8
   7   References . . . . . . . . . . . . . . . . . . . . . . . .10
   8   Acknowledgments . . . . . . . . . . . .  . . . . . . . . .10
   9   Authors' Addresses . . . . . . . . . . . . . . . . . . . .10
   A   Options Considered . . . . . . . . . . . . . . . . . . . .11
       A.1  UDP Encapsulation . . . . . . . . . . . . . . . . . .11
       A.2  FlowID Header Encapsulation . . . . . . . . . . . . .12
       A.3  IPSEC Protocol Modification . . . . . . . . . . . . .12
       A.4  AH Transparency . . . . . . . . . . . . . . . . . . .13

1   Introduction

   Recently published Standards Track RFCs specify protocol mechanisms
   to provide IP level security.  These IP Security, or IPSEC, protocols
   support packet level authentication, [RFC 1826], and integrity and
   confidentiality [RFC 1827].  A number of interoperable
   implementations already exist and several vendors have announced
   commercial products that will use these mechanisms.

   The IPSEC protocols provide service by adding a new header between a
   packet's IP header and the transport (e.g. UDP) protocol header.  The
   two security headers are the Authentication Header (AH), for
   authentication, and the Encapsulating Security Payload (ESP), for
   integrity and confidentiality.

   RSVP is being developed as a resource reservation (dynamic QoS setup)
   protocol.  RSVP as currently specified [RFC 2205] is tailored towards
   IP packets carrying protocols that have TCP or UDP-like ports.
   Protocols that do not have such UDP/TCP-like ports, such as the IPSEC
   protocols, can be supported, but only with limitations.
   Specifically, for flows of IPSEC data packets, flow definition can
   only be done on per IP address, per protocol basis.





Berger & O'Malley           Standards Track                     [Page 2]

RFC 2207               RSVP Extensions for IPSEC          September 1997


   This memo proposes extensions to RSVP so that data flows containing
   IPSEC protocols can be controlled at a granularity similar to what is
   already specified for UDP and TCP.  The proposed extensions can be
   used with both IPv4 and IPv6.  Section 2 of this memo will provide an
   overview of extensions.  Section 3 contains a description of extended
   protocol mechanisms.  Section 4 presents extended protocol processing
   rules.  Section 5 defines the additional RSVP data objects.

2   Overview of Extensions

   The basic notion is to extend RSVP to use the IPSEC Security
   Parameter Index, or SPI, in place of the UDP/TCP-like ports.  This
   will require a new FILTER_SPEC object, which will contain the IPSEC
   SPI, and a new SESSION object.

   While SPIs are allocated based on destination address, they will
   typically be associated with a particular sender.  As a result, two
   senders to the same unicast destination will usually have different
   SPIs.  In order to support the control of multiple independent flows
   between source and destination IP addresses, the SPI will be included
   as part of the FILTER_SPEC.  When using WF, however, all flows to the
   same IP destination address using the same IP protocol ID will share
   the same reservation.  (This limitation exists because the IPSEC
   transport headers do not contain a destination demultiplexing value
   like the UDP/TCP destination port.)

   Although the RESV message format will not change, RESV processing
   will require modification.  Processing of the new IPSEC FILTER_SPEC
   will depend on the use of the new SESSION object and on the protocol
   ID contained in the session definition.  When the new FILTER_SPEC
   object is used, the complete four bytes of the SPI will need to be
   extracted from the FILTER_SPEC for use by the packet classifier.  The
   location of the SPI in the transport header of the IPSEC packets is
   dependent on the protocol ID field.

   The extension will also require a change to PATH processing,
   specifically in the usage of the port field in a session definition.
   An RSVP session is defined by the triple: (DestAddress, protocol ID,
   DstPort).  [RFC 2205] includes the definition of one type of SESSION
   object, it contains UDP/TCP destination ports, specifically "a 16-bit
   quantity carried at the octet offset +2 in the transport header" or
   zero for protocols that lack such a field.  The IPSEC protocols do









Berger & O'Malley           Standards Track                     [Page 3]

RFC 2207               RSVP Extensions for IPSEC          September 1997


   not contain such a field, but there remains a requirement for
   demultiplexing sessions beyond the IP destination address.  In order
   to satisfy this requirement, a virtual destination port, or vDstPort,
   is introduced.  The vDstPort value will be carried in the new SESSION
   object but not in the IPSEC transport header.  The vDstPort allows
   for the differentiation of multiple IPSEC sessions destined to the
   same IP address.  See Section 5 for a discussion of vDstPort ranges.

   In PATH messages, the SENDER_TEMPLATE for IPSEC flows will have the
   same format as the modified FILTER_SPEC.  But, a new SESSION object
   will be used to unambiguously distinguish the use of a virtual
   destination port.

   Traffic will be mapped (classified) to reservations based on SPIs in
   FILTER_SPECs.  This, of course, means that when WF is used all flows
   to the same IP destination address and with the same IP protocol ID
   will share the same reservation.

   The advantages to the described approach are that no changes to
   RFC1826 and 1827 are required and that there is no additional per
   data packet overhead.  Appendix A contains a discussion of the
   advantages of this approach compared to several other alternatives.
   This approach does not take advantage of the IPv6 Flow Label field,
   so greater efficiency may be possible for IPv6 flows.  The details of
   IPv6 Flow Label usage is left for the future.

3   Object Definition

   The FILTER_SPEC and SENDER_TEMPLATE used with IPSEC protocols will
   contain a four byte field that will be used to carry the SPI.  Rather
   than label the modified field with an IPSEC specific label, SPI, the
   label "Generalized Port Identifier", or GPI, will be so that these
   object may be reused for non-IPSEC uses in the future.  The name for
   these objects are the IPv4/GPI FILTER_SPEC, IPv6/GPI FILTER_SPEC,
   IPv4/GPI SENDER_TEMPLATE, and IPv6/GPI SENDER_TEMPLATE.  Similarly,
   the new SESSION objects will be the IPv4/GPI SESSION and the IPv6/GPI
   SESSION.  When referring to the new objects, IP version will not be
   included unless a specific distinction between IPv4 and IPv6 is being
   made.












Berger & O'Malley           Standards Track                     [Page 4]

RFC 2207               RSVP Extensions for IPSEC          September 1997


3.1  SESSION Class


        SESSION Class = 1.

        o    IPv4/GPI SESSION object: Class = 1, C-Type = 3

        +-------------+-------------+-------------+-------------+
        |               IPv4 DestAddress (4 bytes)              |
        +-------------+-------------+-------------+-------------+
        | Protocol ID |     Flags   |         vDstPort          |
        +-------------+-------------+-------------+-------------+


        o    IPv6/GPI SESSION object:  Class = 1, C-Type = 4

        +-------------+-------------+-------------+-------------+
        |                                                       |
        +                                                       +
        |                                                       |
        +               IPv6 DestAddress (16 bytes)             +
        |                                                       |
        +                                                       +
        |                                                       |
        +-------------+-------------+-------------+-------------+
        | Protocol ID |     Flags   |         vDstPort          |
        +-------------+-------------+-------------+-------------+

3.2  FILTER_SPEC Class

        FILTER_SPEC class = 10.

        o    IPv4/GPI FILTER_SPEC object: Class = 10, C-Type = 4