Internet Draft                                            L. Berger
Expiration: June 29, 1997                              FORE Systems
File: draft-berger-rsvp-ext-06.txt                      T. O'Malley
                                                                BBN



                  RSVP Extensions for IPSEC Data Flows


                            January 29, 1997


Status of this Memo


   This document is an Internet-Draft.  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.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet- Drafts
   Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).


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               Expires June 29, 1997            [Page 1]


Internet Draft      RSVP Extensions for IPSEC Flows     January 29, 1997


   Table of Contents


      1   Introduction                                               3

      2   Overview of Extensions                                     3

      3   Object Definition                                          5
          3.1  SESSION Class                                         5
          3.2  FILTER_SPEC Class                                     6
          3.3  SENDER_TEMPLATE Class                                 6

      4   Processing Rules                                           7
          4.1  Required Changes                                      7
          4.2  Merging Flowspecs                                     8
          4.2.1  FF and SE Styles                                    8
          4.2.2  WF Styles                                           8

      5   Security Considerations                                    9

      6   References                                                10

      7   Acknowledgments and Authors' Information                  10
          7.1   Acknowledgments                                     10
          7.2   Authors' Information                                10























Berger, O'Malley               Expires June 29, 1997            [Page 2]


Internet Draft      RSVP Extensions for IPSEC Flows     January 29, 1997


   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, [RFC1826], and integrity and
   confidentiality [RFC1827].  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 [RSVPspec96] 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.

   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



Berger, O'Malley               Expires June 29, 1997            [Page 3]


Internet Draft      RSVP Extensions for IPSEC Flows     January 29, 1997


   same IP destination address using the same protocol 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 next
   protocol field 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 next protocol 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, ProtocolId,
   DstPort).  [RSVPspec96] 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 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.
   This change will allow control of multiple IPSEC flows to a single
   destination.

   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 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.  The 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.




Berger, O'Malley               Expires June 29, 1997            [Page 4]


Internet Draft      RSVP Extensions for IPSEC Flows     January 29, 1997


   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.

   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          |
              +-------------+-------------+-------------+-------------+








Berger, O'Malley               Expires June 29, 1997            [Page 5]


Internet Draft      RSVP Extensions for IPSEC Flows     January 29, 1997


   3.2  FILTER_SPEC Class

         FILTER_SPEC class = 10.

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

              +-------------+-------------+-------------+-------------+
              |               IPv4 SrcAddress (4 bytes)               |
              +-------------+-------------+-------------+-------------+
              |            Generalized Port Identifier (GPI)          |
              +-------------+-------------+-------------+-------------+


         o    IPv6/GPI FILTER_SPEC object: Class = 10, C-Type = 5

              +-------------+-------------+-------------+-------------+
              |                                                       |
              +                                                       +
              |                                                       |
              +               IPv6 SrcAddress (16 bytes)              +
              |                                                       |
              +                                                       +
              |                                                       |
              +-------------+-------------+-------------+-------------+
              |            Generalized Port Identifier (GPI)          |
              +-------------+-------------+-------------+-------------+


   3.3  SENDER_TEMPLATE Class

         SENDER_TEMPLATE class = 11.

         o    IPv4/GPI SENDER_TEMPLATE object: Class = 11, C-Type = 4

              Definition same as IPv4/GPI FILTER_SPEC object.

         o    IPv6/GPI SENDER_TEMPLATE object: Class = 11, C-Type = 5

              Definition same as IPv6/GPI FILTER_SPEC object.









Berger, O'Malley               Expires June 29, 1997            [Page 6]


Internet Draft      RSVP Extensions for IPSEC Flows     January 29, 1997


   4   Processing Rules

   This section presents additions to the Processing Rules presented in
   [RSVPproc96].  These additions are required in order to properly
   process the GPI SESSION and FILTER_SPEC objects.  Values for
   referenced error codes can be found in [RSVPspec96].  As in with the
   other RSVP documents, values for internally reported (API) errors are
   not defined.

   4.1  Required Changes

   Both RESV and PATH processing will need to be changed to support the
   new objects.  The changes ensure consistency and extend port
   processing.

   The following PATH message processing changes are required:

   o  When a session is defined using the GPI SESSION object, only
      the GPI SENDER_TEMPLATE may be used.  When this condition is
      violated, end-stations should report a "Conflicting C-Type" API
      error to the application.

   o  For PATH messages that contain the GPI SESSION object,
      end-stations must verify that the ProtocolId corresponds to a
      protocol known to use the GPI SESSION object.  Values 51 (AH)
      or 50 (ESP) must be supported by implementations supporting
      the described IPSEC extensions.  If an unknown ProtocolId is used,
      then the API should report an "API Error" to the application.

   o  For such messages, the vDstPort value should be recorded.
      The vDstPort value forms part of the recorded state and is used
      to match Resv messages, but it is not passed to traffic control.
      Non-zero values of vDstPort are required.  This requirement
      ensures that a non-GPI SESSION object will never merge with a
      GPI SESSION object.  Violation of this condition causes an
      "Invalid Destination Port" API error.

   The changes to RESV message processing are:

   o  When a RESV message contains a GPI FILTER_SPEC, the session
      must be defined using the GPI SESSION object. Otherwise, this is a
      message formatting error.

   o  The GPI contained in the FILTER_SPEC must match the GPI
      contained in the SENDER_TEMPLATE.  Otherwise, a "No sender



Berger, O'Malley               Expires June 29, 1997            [Page 7]


Internet Draft      RSVP Extensions for IPSEC Flows     January 29, 1997


      information for this Resv message" error  is generated.

   o  When the GPI FILTER_SPEC is used, each node must create
      a data classifier for the flow described by the quadruple:
      (DestAddress, ProtocolId, SrcAddress, GPI). The data classifier
      will need to look for the four byte GPI at transport header
      offset +4 for AH, and at transport header offset +0 for ESP.


   4.2  Merging Flowspecs

   When using this extension for IPSEC data flows, RSVP sessions are
   defined by the triple: (DestAddress, ProtocolId, vDstPort).
   Similarly, a sender is defined by the tuple: (SrcAddress, GPI), where
   the GPI field will be a four byte representation of a generalized
   source port.  These extensions have some ramifications depending upon
   the reservation style.

   4.2.1  FF and SE Styles

   In the FF and SE Styles, the FILTER_SPEC object contains the
   (SrcAddress, GPI) pair.  This allows the receiver to uniquely
   identify senders based on both elements of the pair.  When merging
   explicit sender descriptors, the senders may only be considered
   identical when both elements are identical.

   4.2.2  WF Styles

   These extensions provide very limited service when used with WF style
   reservations.  As described, the SENDER_TEMPLATE and FILTER_SPEC each
   contain the GPI.  In a WF style reservation, the RESV message does
   NOT contain a FILTER_SPEC (after all, it is a wildcard filter), and
   the SENDER_TEMPLATE is ignored (again, because any sender is
   allowed).  As a result, classifiers may match all packets which
   contain both the session's destination IP address and next protocol
   ID to such WF reservations.

   Although a solution for this limitation is not proposed, this issue
   is not seen as significant since IPSEC applications are less likely
   to use WF style reservations.








Berger, O'Malley               Expires June 29, 1997            [Page 8]


Internet Draft      RSVP Extensions for IPSEC Flows     January 29, 1997


   5   Security Considerations

   The same considerations stated in [RSVPspec96], [RFC1826], and
   [RFC1827] apply to the extensions described in this note.  There is
   one additional issue related to these extensions.

   Changes in SPI values for a given flow will affect RSVP flows and
   reservations.  Changes will happen whenever that flow changes its
   Security Association.  Such changes will occur when a flow is rekeyed
   (i.e. to use a new key). Rekeying intervals are typically set based
   on traffic levels, key size, threat environment, and crypto algorithm
   in use.  When an SPI change occurs it will, in most cases, be
   necessary to update (send) the corresponding SENDER_TEMPLATEs and
   FILTER_SPECs.  IPSEC implementations, RSVP applications, and RSVP
   end-station implementations will need to take the possibility of
   changes of SPI into account to ensure proper reservation behavior.
   This issue is likely to be a tolerable, since rekeying intervals are
   under the control of local administrators.

   Many, if not most, RSVP sessions will not need to deal with this
   rekeying issue.  For those applications that do need to deal with
   changes of SPIs during a session, the impact of sending new PATH and
   RESV messages will vary based on the reservation style being used.
   Builders of such applications may want to select reservation style
   based on interaction with SPI changes.

   The least impact of an SPI change will be to WF style reservations.
   For such reservations, a new SENDER_TEMPLATE will need to be sent,
   but no new RESV is required.  For SE style reservations, both a new
   SENDER_TEMPLATE and a new RESV will need to be sent.  This will
   result in changes to state, but should not affect data packet
   delivery or actual resource allocation in any way.  The FF style will
   be impacted the most.  Like with SE, both PATH and RESV messages will
   need to be sent.  But, since FF style reservations result in sender
   receiving its own resource allocation, resources will be allocated
   twice for a period of time.  Or, even worse, there won't be enough
   resources to support the new flow without first freeing the old flow.

   A way around this FF/SPI-change problem does exist.  Applications
   that want FF style reservations can use multiple SE reservations.
   Each real sender would have a separate SESSION (vDstPort) definition.
   When it came time to switch SPIs, a shared reservation could be made
   for the new SPI while the old SPI was still active.  Once the new SPI
   was in use, the old reservation could be torn down.  This is less
   than optimal, but will provide uninterrupted service for a set of



Berger, O'Malley               Expires June 29, 1997            [Page 9]


Internet Draft      RSVP Extensions for IPSEC Flows     January 29, 1997


   applications.


   6   References

   [RSVPspec96]  Braden, R., Ed., Zhang, L., Estrin, D., Herzog, S., and
                 S. Jamin, "Resource ReSerVation Protocol (RSVP) --
                 Version 1 Functional Specification.  Internet Draft
                 draft-ietf-rsvp-spec-014.ps, November 1996.

   [RSVPproc96]  Braden, R., Ed., Zhang, "Resource ReSerVation
                 Protocol (RSVP) -- Version 1 Message Processing Rules",
                 Internet Draft draft-ietf-rsvp-procrules-00.txt,
                 November 1996.

   [RFC1825] Atkinson, R., "Security Architecture for the Internet
             Protocol", RFC 1825, NRL, August 1995.

   [RFC1826] Atkinson, R., "IP Authentication Header", RFC 1826, NRL,
             August 1995.

   [RFC1827] Atkinson, R., "IP Encapsulating Security Payload", RFC
             1827, NRL, August 1995.


   7   Acknowledgments and Authors' Information

   7.1   Acknowledgments

   This note includes ideas originated and reviewed by a number of
   individuals who did not participate in this note's writing.  The
   authors would like to acknowledge their contribution.  We thank Ran
   Atkinson <rja@cisco.com>, Fred Baker <fred@cisco.com>, Greg Troxel
   <gdt@bbn.com>, John Krawczyk <jkrawczyk@BayNetworks.com> for much
   appreciated input and feedback. Special appreciation goes to Bob
   Braden <braden@isi.edu> for his detailed editorial and technical
   comments.  We also thank Buz Owen, Claudio Topolcic, Andy Veitch, and
   Luis Sanchez for their help in coming up with the proposed approach.
   If any brain-damage exists in this note, it originated solely from
   the authors.

   7.2   Authors' Information

      Lou Berger                           Tim O'Malley
      FORE Systems                         BBN Corporation



Berger, O'Malley               Expires June 29, 1997           [Page 10]


Internet Draft      RSVP Extensions for IPSEC Flows     January 29, 1997


      6905 Rockledge Drive                    10 Moulton Street
      Suite 800                            Cambridge, MA 02138
      Bethesda, MD 20817

      Phone: 301-571-2534                  Phone: 617-873-3076
      EMail: lberger@fore.com              EMail: timo@bbn.com










































Berger, O'Malley               Expires June 29, 1997           [Page 11]