Internet Draft                                            L. Berger
Expiration: August 22, 1996                                     BBN
File: draft-berger-rsvp-ext-02.txt                      T. O'Malley
                                                                BBN
                                                        R. Atkinson
                                                              Cisco



                                Proposed
               RSVP Extensions for IPSEC IPv4 Data Flows


                           February 22, 1996


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
   IPv4 IPSEC protocols, but only on a per address, per protocol basis
   not on a per flow basis.






Berger, O'Malley, Atkinson      Expires August 22, 1996         [Page 1]

Internet Draft      RSVP Extensions for IPSEC Flows    February 22, 1996


   Table of Contents


      1   Introduction                                               3

      2   Overview of Extensions                                     4

      3   Mechanisms                                                 5

      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                                           7

      5   Object Definition                                          8
          5.1  SESSION Class                                         8
          5.2  FILTER_SPEC Class                                     8
          5.3  SENDER_TEMPLATE Class                                 8

      6   Security Considerations                                    9

      7   References                                                10

      8   Acknowledgments and Authors' Information                  10
          8.1   Acknowledgments                                     10
          8.2   Authors' Information                                10
























Berger, O'Malley, Atkinson      Expires August 22, 1996         [Page 2]

Internet Draft      RSVP Extensions for IPSEC Flows    February 22, 1996


   Changes From Previous Version

   The most significant changes from the previous version are:

     o Introduced the notion of a virtual destination port.  This
       modification more clearly shows that the DstPort is not in the
       transport header.  In the SESSION object, now contains a vDstPort
       field rather than a DstPort field.

     o Fixed values of AH (51) and ESP (50), they were reversed.


   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.  For IPv4, RSVP as currently specified [RSVP96] is tailored
   towards IP packets carrying protocols that have TCP or UDP-like
   ports.  Protocols that do not have such UDP/TCP-like ports can be
   supported, but only with limitations.  The IPSEC protocols do not
   have UDP/TCP like ports, so they are not very well supported.
   Specifically, for flows of IPSEC data packets, flow definition can
   only be done on an 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.  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.








Berger, O'Malley, Atkinson      Expires August 22, 1996         [Page 3]

Internet Draft      RSVP Extensions for IPSEC Flows    February 22, 1996


   2   Overview of Extensions

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

   The extension will require modifying RESV processing.  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 allow the receiver to share reservations among senders, the SPI
   will be included as part of the FILTER_SPEC.  This approach will
   support the control of multiple independent flows between source and
   destination IP addresses using FF and SE filter styles.  With WF, all
   flows to the same IP destination address using the same protocol will
   share the same reservation.  This limitation exists because the IPSEC
   protocols do not contain either UDP/TCP-like destination ports or
   some other alternative destination demultiplexing value in the
   transport header.

   Although the format of the RESV message will not change, RESV
   processing will require modification.  When the FILTER_SPEC is used
   with IPSEC protocols, processing will need to be dependent on the use
   of the new SESSION object and on the next protocol field contained in
   the session definition.  When the new SESSION 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 SPI is located at transport header offset
   +4 for AH (51), and at +0 for ESP (50).

   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).  The DstPort field of the SESSION object is currently
   defined as "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.  To satisfy this requirement, a virtual destination port, or
   vDstPort, is introduced.  The vDstPort value will not be carried in
   the IPSEC transport header.  This change will allow control of
   multiple IPSEC flows to a single destination.  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.




Berger, O'Malley, Atkinson      Expires August 22, 1996         [Page 4]

Internet Draft      RSVP Extensions for IPSEC Flows    February 22, 1996


   In PATH messages, the SENDER_TEMPLATE for IPSEC flows will match the
   modified FILTER_SPEC.  But, a new SESSION object will be used to
   unambiguously distinguish the use of a virtual destination port.
   Session definition and PATH processing will need to be modified to
   support the new message class types.

   To make use of this extension, communicating hosts will need to match
   RSVP sessions and reservations to appropriate SPIs.  To make best use
   of reservations, the WF reservation style should be avoided and
   multiple SPIs used when supporting multiple data flows between hosts.
   The use of multiple SPIs is supported by the IPSEC protocols, so this
   should not be an issue.  Avoiding WF and only using SE and FF style
   reservations should also not be a major issue since the IPSEC
   protocols require receivers to identify all valid senders and their
   associated SPIs.

   End-stations will also need to track when the SPI value associated
   with an RSVP flow changes.  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.  This issue is also likely to be a
   tolerable, since rekeying intervals are under the control of local
   administrators.

   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 disadvantages to this approach are that we
   have to modify RSVP and, to a lesser degree, that the use of SPI is
   overloaded.


   3   Mechanisms

   This extension does not alter the mechanisms described in [RSVP96]
   with the exception of Port Usage.  For IPSEC data flows, UDP/TCP-like
   ports are primarily replaced by IPSEC SPIs.

   Implementations of RSVP that support IPSEC flows must recognize the
   new SESSION object and the IPSEC ProtocolIds.  When the new SESSION
   object is used, for example, such systems must permit non-zero
   destination port values even though the IPSEC protocols don't support
   UDP/TCP-like ports.

   Session definition for IPSEC flows will continue to use the triple:
   (DestAddress, ProtocolId, vDstPort), where the vDstPort field will
   represent a virtual destination port rather than a specific value in
   the transport header.  The ProtocolId field must be set to either AH



Berger, O'Malley, Atkinson      Expires August 22, 1996         [Page 5]

Internet Draft      RSVP Extensions for IPSEC Flows    February 22, 1996


   (51) or ESP (50).  Implementations of RSVP must require non-zero
   vDstPort values when either IPSEC protocol is used.  A zero value of
   vDstPort is not valid and end-stations should give an error to an
   application that specifies a zero value.

   The FILTER_SPEC format will not contain a port field.  Instead, it
   will have a four byte field that will contain an SPI.  The
   SENDER_TEMPLATE format will match the FILTER_SPEC format, both
   defined by the pair: (SrcAddress, SPI).  When the new objects are
   used, SPIs in SENDER_TEMPLATEs and FILTER_SPECs must match.

   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 of
   the objects will be IPv4/GPI FILTER_SPEC and IPv4/GPI
   SENDER_TEMPLATE.  Similarly, the name of the new SESSION object will
   be IPv4/GPI SESSION.


   4   Processing Rules

   This section presents additions to the Processing Rules section of
   the [RSVP96].  These additions are required in order to properly
   process the new IPv4/GPI SESSION object and IPv4/GPI FILTER_SPEC.


   4.1  Required Changes

   Both RESV and PATH processing will need to be changed to support the
   new IPv4/GPI 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 IPv4/GPI SESSION object,
      only the IPv4/GPI SENDER_TEMPLATE may be used.

   o  For PATH messages that contain the IPv4/GPI SESSION object,
      the value of the ProtocolId must correspond to a protocol
      known to use the IPv4/GPI SESSION object.  Values 51 (AH)
      or 50 (ESP) must be supported by implementations supporting
      the described IPSEC extensions.

   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.



Berger, O'Malley, Atkinson      Expires August 22, 1996         [Page 6]

Internet Draft      RSVP Extensions for IPSEC Flows    February 22, 1996


      (Non-zero values of vDstPort are required even though the IPSEC
      protocols do not have UDP/TCP-like ports.)

   The changes to RESV message processing are:

   o  When a RESV message contains an IPv4/GPI FILTER_SPEC, the
      session must be defined using the IPv4/GPI SESSION object.

   o  When a RESV message contains an IPv4/GPI FILTER_SPEC, the
      SENDER_TEMPLATE of the associated Path state must be an
      IPv4/GPI SENDER_TEMPLATE object.

   o  The GPI contained in the FILTER_SPEC must match the GPI
      contained in the SENDER_TEMPLATE.

   o  When the IPv4/GPI FILTER_SPEC is used, each node must create
      a data classifier for the flow described by the quadruple:
      (DestAddress, ProtocolId, SrcAddress, GPI).  Specifically, the
      data classifier must NOT include any UDP/TCP-like source or
      destination ports!  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 on merging of
   filter styles.

   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 are likely to match all packets



Berger, O'Malley, Atkinson      Expires August 22, 1996         [Page 7]

Internet Draft      RSVP Extensions for IPSEC Flows    February 22, 1996


   that contain both the session's destination IP address and next
   protocol ID to such WF reservations.  For this reason, it is
   recommended that WF style reservations not be used with IPSEC
   protocols.

   A solution for this limitation is not proposed.  This issue is not
   seen as significant since IPSEC applications are unlikely to use WF
   style reservations.  Although, it would be nice to have a filter
   style which specifies a wildcard sender but specific GPI.  The
   mechanism to support such a filter, however, seems non-trivial.


   5   Object Definition

   As previously mentioned, rather than label the modified FILTER_SPEC
   and SENDER_TEMPLATE with IPSEC the specific fields, SPI, we use the
   label "Generalized Port Identifier", or GPI, so that these object may
   be reused for non-IPSEC uses in the future.

   5.1  SESSION Class

         SESSION Class = 1.

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

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


   5.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)          |
              +-------------+-------------+-------------+-------------+

   5.3  SENDER_TEMPLATE Class

         SENDER_TEMPLATE class = 11.




Berger, O'Malley, Atkinson      Expires August 22, 1996         [Page 8]

Internet Draft      RSVP Extensions for IPSEC Flows    February 22, 1996


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

              Definition same as IPv4/GPI FILTER_SPEC object.

   6   Security Considerations

   The same considerations stated in [RSVP96], [RFC1826], and [RFC1827]
   apply to the extensions described in this note.  There are two
   additional issues related to these extensions.

   The first issue is that the use of SPIs to identify reservations may
   introduce greater opportunity for traffic analysis.  The significance
   of the added traffic analysis threat will, of course, vary on a
   case-by-case basis.  Applications or users may choose to reduce the
   threat by aggregating reservations and flows, or even aggregating all
   traffic into a single flow and reservation.

   The second issue is that 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).  The frequency of key
   changes will depend on duration and size of the flow, 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.

   Many, if not most, RSVP sessions will not need to deal with this last
   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.




Berger, O'Malley, Atkinson      Expires August 22, 1996         [Page 9]

Internet Draft      RSVP Extensions for IPSEC Flows    February 22, 1996


   A way around this FF/SPI-change problem does exist, but it is not
   elegant: 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 inelegant, but will provide
   uninterrupted service for a set of applications.

   7   References

   [RSVP96]  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-09.ps, February 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.


   8   Acknowledgments and Authors' Information

   8.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 Fred
   Baker <fred@cisco.com> for proposing a SPI FILTER_SPEC, Greg Troxel
   <gdt@bbn.com> for proposing a solution that we didn't use, and both
   John Krawczyk <jkrawczyk@BayNetworks.com> and Bob Braden
   <braden@isi.edu> for their detailed feedback.  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.

   8.2   Authors' Information

      Lou Berger
      BBN Corporation
      1300 North 17th Street, Suite 1200
      Arlington, VA 22209



Berger, O'Malley, Atkinson      Expires August 22, 1996        [Page 10]

Internet Draft      RSVP Extensions for IPSEC Flows    February 22, 1996


      Phone: 703-284-4651
      EMail: lberger@bbn.com


      Tim O'Malley
      BBN Corporation
      10 Moulton Street
      Cambridge, MA 02138

      Phone: 617-873-3076
      EMail: timo@bbn.com


      Randall Atkinson
      cisco Systems
      170 West Tasman Drive
      San Jose, CA 95134-1706

      Phone: 408-526-6566
      EMail: rja@cisco.com































Berger, O'Malley, Atkinson      Expires August 22, 1996        [Page 11]