home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc2207 < prev    next >
Text File  |  1997-10-01  |  30KB  |  788 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                     L. Berger
  8. Request for Comments: 2207                             FORE Systems
  9. Category: Standards Track                               T. O'Malley
  10.                                                                 BBN
  11.                                                      September 1997
  12.  
  13.  
  14.                   RSVP Extensions for IPSEC Data Flows
  15.  
  16.  
  17. Status of this Memo
  18.  
  19.    This document specifies an Internet standards track protocol for the
  20.    Internet community, and requests discussion and suggestions for
  21.    improvements.  Please refer to the current edition of the "Internet
  22.    Official Protocol Standards" (STD 1) for the standardization state
  23.    and status of this protocol.  Distribution of this memo is unlimited.
  24.  
  25.  
  26.  
  27. Abstract
  28.  
  29.    This document presents extensions to Version 1 of RSVP.  These
  30.    extensions permit support of individual data flows using RFC 1826, IP
  31.    Authentication Header (AH) or RFC 1827, IP Encapsulating Security
  32.    Payload (ESP).  RSVP Version 1 as currently specified can support the
  33.    IPSEC protocols, but only on a per address, per protocol basis not on
  34.    a per flow basis.  The presented extensions can be used with both
  35.    IPv4 and IPv6.
  36.  
  37.  
  38.  
  39.  
  40.  
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Berger & O'Malley           Standards Track                     [Page 1]
  59.  
  60. RFC 2207               RSVP Extensions for IPSEC          September 1997
  61.  
  62.  
  63. Table of Contents
  64.  
  65.    1   Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
  66.    2   Overview of Extensions . . . . . . . . . . . . . . . . . . 3
  67.    3   Object Definition. . . . . . . . . . . . . . . . . . . . . 4
  68.        3.1  SESSION Class . . . . . . . . . . . . . . . . . . . . 5
  69.        3.2  FILTER_SPEC Class . . . . . . . . . . . . . . . . . . 5
  70.        3.3  SENDER_TEMPLATE Class . . . . . . . . . . . . . . . . 6
  71.    4   Processing Rules . . . . . . . . . . . . . . . . . . . . . 6
  72.        4.1  Required Changes. . . . . . . . . . . . . . . . . . . 6
  73.        4.2  Merging Flowspecs . . . . . . . . . . . . . . . . . . 7
  74.        4.2.1  FF and SE Styles. . . . . . . . . . . . . . . . . . 7
  75.        4.2.2  WF Styles . . . . . . . . . . . . . . . . . . . . . 8
  76.    5   IANA Considerations. . . . . . . . . . . . . . . . . . . . 8
  77.    6   Security Considerations. . . . . . . . . . . . . . . . . . 8
  78.    7   References . . . . . . . . . . . . . . . . . . . . . . . .10
  79.    8   Acknowledgments . . . . . . . . . . . .  . . . . . . . . .10
  80.    9   Authors' Addresses . . . . . . . . . . . . . . . . . . . .10
  81.    A   Options Considered . . . . . . . . . . . . . . . . . . . .11
  82.        A.1  UDP Encapsulation . . . . . . . . . . . . . . . . . .11
  83.        A.2  FlowID Header Encapsulation . . . . . . . . . . . . .12
  84.        A.3  IPSEC Protocol Modification . . . . . . . . . . . . .12
  85.        A.4  AH Transparency . . . . . . . . . . . . . . . . . . .13
  86.  
  87. 1   Introduction
  88.  
  89.    Recently published Standards Track RFCs specify protocol mechanisms
  90.    to provide IP level security.  These IP Security, or IPSEC, protocols
  91.    support packet level authentication, [RFC 1826], and integrity and
  92.    confidentiality [RFC 1827].  A number of interoperable
  93.    implementations already exist and several vendors have announced
  94.    commercial products that will use these mechanisms.
  95.  
  96.    The IPSEC protocols provide service by adding a new header between a
  97.    packet's IP header and the transport (e.g. UDP) protocol header.  The
  98.    two security headers are the Authentication Header (AH), for
  99.    authentication, and the Encapsulating Security Payload (ESP), for
  100.    integrity and confidentiality.
  101.  
  102.    RSVP is being developed as a resource reservation (dynamic QoS setup)
  103.    protocol.  RSVP as currently specified [RFC 2205] is tailored towards
  104.    IP packets carrying protocols that have TCP or UDP-like ports.
  105.    Protocols that do not have such UDP/TCP-like ports, such as the IPSEC
  106.    protocols, can be supported, but only with limitations.
  107.    Specifically, for flows of IPSEC data packets, flow definition can
  108.    only be done on per IP address, per protocol basis.
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Berger & O'Malley           Standards Track                     [Page 2]
  115.  
  116. RFC 2207               RSVP Extensions for IPSEC          September 1997
  117.  
  118.  
  119.    This memo proposes extensions to RSVP so that data flows containing
  120.    IPSEC protocols can be controlled at a granularity similar to what is
  121.    already specified for UDP and TCP.  The proposed extensions can be
  122.    used with both IPv4 and IPv6.  Section 2 of this memo will provide an
  123.    overview of extensions.  Section 3 contains a description of extended
  124.    protocol mechanisms.  Section 4 presents extended protocol processing
  125.    rules.  Section 5 defines the additional RSVP data objects.
  126.  
  127. 2   Overview of Extensions
  128.  
  129.    The basic notion is to extend RSVP to use the IPSEC Security
  130.    Parameter Index, or SPI, in place of the UDP/TCP-like ports.  This
  131.    will require a new FILTER_SPEC object, which will contain the IPSEC
  132.    SPI, and a new SESSION object.
  133.  
  134.    While SPIs are allocated based on destination address, they will
  135.    typically be associated with a particular sender.  As a result, two
  136.    senders to the same unicast destination will usually have different
  137.    SPIs.  In order to support the control of multiple independent flows
  138.    between source and destination IP addresses, the SPI will be included
  139.    as part of the FILTER_SPEC.  When using WF, however, all flows to the
  140.    same IP destination address using the same IP protocol ID will share
  141.    the same reservation.  (This limitation exists because the IPSEC
  142.    transport headers do not contain a destination demultiplexing value
  143.    like the UDP/TCP destination port.)
  144.  
  145.    Although the RESV message format will not change, RESV processing
  146.    will require modification.  Processing of the new IPSEC FILTER_SPEC
  147.    will depend on the use of the new SESSION object and on the protocol
  148.    ID contained in the session definition.  When the new FILTER_SPEC
  149.    object is used, the complete four bytes of the SPI will need to be
  150.    extracted from the FILTER_SPEC for use by the packet classifier.  The
  151.    location of the SPI in the transport header of the IPSEC packets is
  152.    dependent on the protocol ID field.
  153.  
  154.    The extension will also require a change to PATH processing,
  155.    specifically in the usage of the port field in a session definition.
  156.    An RSVP session is defined by the triple: (DestAddress, protocol ID,
  157.    DstPort).  [RFC 2205] includes the definition of one type of SESSION
  158.    object, it contains UDP/TCP destination ports, specifically "a 16-bit
  159.    quantity carried at the octet offset +2 in the transport header" or
  160.    zero for protocols that lack such a field.  The IPSEC protocols do
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Berger & O'Malley           Standards Track                     [Page 3]
  171.  
  172. RFC 2207               RSVP Extensions for IPSEC          September 1997
  173.  
  174.  
  175.    not contain such a field, but there remains a requirement for
  176.    demultiplexing sessions beyond the IP destination address.  In order
  177.    to satisfy this requirement, a virtual destination port, or vDstPort,
  178.    is introduced.  The vDstPort value will be carried in the new SESSION
  179.    object but not in the IPSEC transport header.  The vDstPort allows
  180.    for the differentiation of multiple IPSEC sessions destined to the
  181.    same IP address.  See Section 5 for a discussion of vDstPort ranges.
  182.  
  183.    In PATH messages, the SENDER_TEMPLATE for IPSEC flows will have the
  184.    same format as the modified FILTER_SPEC.  But, a new SESSION object
  185.    will be used to unambiguously distinguish the use of a virtual
  186.    destination port.
  187.  
  188.    Traffic will be mapped (classified) to reservations based on SPIs in
  189.    FILTER_SPECs.  This, of course, means that when WF is used all flows
  190.    to the same IP destination address and with the same IP protocol ID
  191.    will share the same reservation.
  192.  
  193.    The advantages to the described approach are that no changes to
  194.    RFC1826 and 1827 are required and that there is no additional per
  195.    data packet overhead.  Appendix A contains a discussion of the
  196.    advantages of this approach compared to several other alternatives.
  197.    This approach does not take advantage of the IPv6 Flow Label field,
  198.    so greater efficiency may be possible for IPv6 flows.  The details of
  199.    IPv6 Flow Label usage is left for the future.
  200.  
  201. 3   Object Definition
  202.  
  203.    The FILTER_SPEC and SENDER_TEMPLATE used with IPSEC protocols will
  204.    contain a four byte field that will be used to carry the SPI.  Rather
  205.    than label the modified field with an IPSEC specific label, SPI, the
  206.    label "Generalized Port Identifier", or GPI, will be so that these
  207.    object may be reused for non-IPSEC uses in the future.  The name for
  208.    these objects are the IPv4/GPI FILTER_SPEC, IPv6/GPI FILTER_SPEC,
  209.    IPv4/GPI SENDER_TEMPLATE, and IPv6/GPI SENDER_TEMPLATE.  Similarly,
  210.    the new SESSION objects will be the IPv4/GPI SESSION and the IPv6/GPI
  211.    SESSION.  When referring to the new objects, IP version will not be
  212.    included unless a specific distinction between IPv4 and IPv6 is being
  213.    made.
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Berger & O'Malley           Standards Track                     [Page 4]
  227.  
  228. RFC 2207               RSVP Extensions for IPSEC          September 1997
  229.  
  230.  
  231. 3.1  SESSION Class
  232.  
  233.  
  234.         SESSION Class = 1.
  235.  
  236.         o    IPv4/GPI SESSION object: Class = 1, C-Type = 3
  237.  
  238.         +-------------+-------------+-------------+-------------+
  239.         |               IPv4 DestAddress (4 bytes)              |
  240.         +-------------+-------------+-------------+-------------+
  241.         | Protocol ID |     Flags   |         vDstPort          |
  242.         +-------------+-------------+-------------+-------------+
  243.  
  244.  
  245.         o    IPv6/GPI SESSION object:  Class = 1, C-Type = 4
  246.  
  247.         +-------------+-------------+-------------+-------------+
  248.         |                                                       |
  249.         +                                                       +
  250.         |                                                       |
  251.         +               IPv6 DestAddress (16 bytes)             +
  252.         |                                                       |
  253.         +                                                       +
  254.         |                                                       |
  255.         +-------------+-------------+-------------+-------------+
  256.         | Protocol ID |     Flags   |         vDstPort          |
  257.         +-------------+-------------+-------------+-------------+
  258.  
  259. 3.2  FILTER_SPEC Class
  260.  
  261.         FILTER_SPEC class = 10.
  262.  
  263.         o    IPv4/GPI FILTER_SPEC object: Class = 10, C-Type = 4
  264.  
  265.         +-------------+-------------+-------------+-------------+
  266.         |               IPv4 SrcAddress (4 bytes)               |
  267.         +-------------+-------------+-------------+-------------+
  268.         |            Generalized Port Identifier (GPI)          |
  269.         +-------------+-------------+-------------+-------------+
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Berger & O'Malley           Standards Track                     [Page 5]
  283.  
  284. RFC 2207               RSVP Extensions for IPSEC          September 1997
  285.  
  286.  
  287.         o    IPv6/GPI FILTER_SPEC object: Class = 10, C-Type = 5
  288.  
  289.         +-------------+-------------+-------------+-------------+
  290.         |                                                       |
  291.         +                                                       +
  292.         |                                                       |
  293.         +               IPv6 SrcAddress (16 bytes)              +
  294.         |                                                       |
  295.         +                                                       +
  296.         |                                                       |
  297.         +-------------+-------------+-------------+-------------+
  298.         |            Generalized Port Identifier (GPI)          |
  299.         +-------------+-------------+-------------+-------------+
  300.  
  301. 3.3  SENDER_TEMPLATE Class
  302.  
  303.         SENDER_TEMPLATE class = 11.
  304.  
  305.         o    IPv4/GPI SENDER_TEMPLATE object: Class = 11, C-Type = 4
  306.  
  307.                  Definition same as IPv4/GPI FILTER_SPEC object.
  308.  
  309.         o    IPv6/GPI SENDER_TEMPLATE object: Class = 11, C-Type = 5
  310.  
  311.                  Definition same as IPv6/GPI FILTER_SPEC object.
  312.  
  313. 4   Processing Rules
  314.  
  315.    This section presents additions to the Processing Rules presented in
  316.    [RFC 2209].  These additions are required in order to properly
  317.    process the GPI SESSION and FILTER_SPEC objects.  Values for
  318.    referenced error codes can be found in [RFC 2205].  As in with the
  319.    other RSVP documents, values for internally reported (API) errors are
  320.    not defined.
  321.  
  322. 4.1  Required Changes
  323.  
  324.    Both RESV and PATH processing will need to be changed to support the
  325.    new objects.  The changes ensure consistency and extend port
  326.    processing.
  327.  
  328.    The following PATH message processing changes are required:
  329.  
  330.      o  When a session is defined using the GPI SESSION object, only
  331.         the GPI SENDER_TEMPLATE may be used.  When this condition is
  332.         violated, end-stations should report a "Conflicting C-Type" API
  333.         error to the application.
  334.  
  335.  
  336.  
  337.  
  338. Berger & O'Malley           Standards Track                     [Page 6]
  339.  
  340. RFC 2207               RSVP Extensions for IPSEC          September 1997
  341.  
  342.  
  343.      o  For PATH messages that contain the GPI SESSION object,
  344.         end-stations must verify that the protocol ID corresponds to a
  345.         protocol known to use the GPI SESSION object.  Values 51 (AH)
  346.         or 50 (ESP) must be supported by implementations supporting
  347.         the described IPSEC extensions.  If an unknown protocol ID is
  348.         used, then the API should report an "API Error" to the
  349.         application.
  350.  
  351.      o  For such messages, the vDstPort value should be recorded.
  352.         The vDstPort value forms part of the recorded state and is used
  353.         to match Resv messages, but it is not passed to traffic control.
  354.         Non-zero values of vDstPort are required.  This requirement
  355.         ensures that a non-GPI SESSION object will never merge with a
  356.         GPI SESSION object.  Violation of this condition causes an
  357.         "Invalid Destination Port" API error.
  358.  
  359.      The changes to RESV message processing are:
  360.  
  361.      o  When a RESV message contains a GPI FILTER_SPEC, the session
  362.         must be defined using the GPI SESSION object. Otherwise, this is
  363.         a message formatting error.
  364.  
  365.      o  The GPI contained in the FILTER_SPEC must match the GPI
  366.         contained in the SENDER_TEMPLATE.  Otherwise, a "No sender
  367.         information for this Resv message" error  is generated.
  368.  
  369.      o  When the GPI FILTER_SPEC is used, each node must create
  370.         a data classifier for the flow described by the quadruple:
  371.         (DestAddress, protocol ID, SrcAddress, GPI). The data classifier
  372.         will need to look for the four byte GPI at transport header
  373.         offset +4 for AH, and at transport header offset +0 for ESP.
  374.  
  375. 4.2  Merging Flowspecs
  376.  
  377.    When using this extension for IPSEC data flows, RSVP sessions are
  378.    defined by the triple: (DestAddress, protocol Id, vDstPort).
  379.    Similarly, a sender is defined by the tuple: (SrcAddress, GPI), where
  380.    the GPI field will be a four byte representation of a generalized
  381.    source port.  These extensions have some ramifications depending upon
  382.    the reservation style.
  383.  
  384. 4.2.1  FF and SE Styles
  385.  
  386.    In the FF and SE Styles, the FILTER_SPEC object contains the
  387.    (SrcAddress, GPI) pair.  This allows the receiver to uniquely
  388.    identify senders based on both elements of the pair.  When merging
  389.    explicit sender descriptors, the senders may only be considered
  390.    identical when both elements are identical.
  391.  
  392.  
  393.  
  394. Berger & O'Malley           Standards Track                     [Page 7]
  395.  
  396. RFC 2207               RSVP Extensions for IPSEC          September 1997
  397.  
  398.  
  399. 4.2.2  WF Styles
  400.  
  401.    These extensions provide very limited service when used with WF style
  402.    reservations.  As described, the SENDER_TEMPLATE and FILTER_SPEC each
  403.    contain the GPI.  In a WF style reservation, the RESV message does
  404.    NOT contain a FILTER_SPEC (after all, it is a wildcard filter), and
  405.    the SENDER_TEMPLATE is ignored (again, because any sender is
  406.    allowed).  As a result, classifiers may match all packets which
  407.    contain both the session's destination IP address and protocol ID to
  408.    such WF reservations.
  409.  
  410.    Although a solution for this limitation is not proposed, this issue
  411.    is not seen as significant since IPSEC applications are less likely
  412.    to use WF style reservations.
  413.  
  414. 5   IANA Considerations
  415.  
  416.    The range of possible vDstPort values is broken down into sections,
  417.    in a fashion similar to the UDP/TCP port ranges.
  418.  
  419.              0              Illegal Value
  420.              1 - 10         Reserved. Contact authors.
  421.              11 - 8191      Assigned by IANA
  422.              8192 - 65535   Dynamic
  423.  
  424.    IANA is directed to assign the well-known vDstPorts using the
  425.    following criteria:  Anyone who asks for an assigned vDstPort must
  426.    provide a) a Point of Contact, b) a brief description of intended
  427.    use, and c) a short name to be associated with the assignment (e.g.
  428.    "ftp").
  429.  
  430. 6   Security Considerations
  431.  
  432.    The same considerations stated in [RFC 2205], [RFC 1826], and [RFC
  433.    1827] apply to the extensions described in this note.  There are two
  434.    additional issue related to these extensions.
  435.  
  436.    First, the vDstPort mechanism represents another data element about
  437.    the IP Flow that might be available to an adversary.  Such data might
  438.    be useful to an adversary engaging in traffic analysis by monitoring
  439.    not only the data packets of the IP Flow but also the RSVP control
  440.    messages associated with that Flow.  Protection against traffic
  441.    analysis attacks is outside the scope of this mechanism.  One
  442.    possible approach to precluding such attacks would be deployment and
  443.    use of appropriate link-layer confidentiality mechansisms, such as
  444.    encryption.
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Berger & O'Malley           Standards Track                     [Page 8]
  451.  
  452. RFC 2207               RSVP Extensions for IPSEC          September 1997
  453.  
  454.  
  455.    Secondly, Changes in SPI values for a given flow will affect RSVP
  456.    flows and reservations.  Changes will happen whenever that flow
  457.    changes its Security Association.  Such changes will occur when a
  458.    flow is rekeyed (i.e. to use a new key). Rekeying intervals are
  459.    typically set based on traffic levels, key size, threat environment,
  460.    and crypto algorithm in use.  When an SPI change occurs it will, in
  461.    most cases, be necessary to update (send) the corresponding
  462.    SENDER_TEMPLATEs and FILTER_SPECs.  IPSEC implementations, RSVP
  463.    applications, and RSVP end-station implementations will need to take
  464.    the possibility of changes of SPI into account to ensure proper
  465.    reservation behavior.  This issue is likely to be a tolerable, since
  466.    rekeying intervals are under the control of local administrators.
  467.  
  468.    Many, if not most, RSVP sessions will not need to deal with this
  469.    rekeying issue.  For those applications that do need to deal with
  470.    changes of SPIs during a session, the impact of sending new PATH and
  471.    RESV messages will vary based on the reservation style being used.
  472.    Builders of such applications may want to select reservation style
  473.    based on interaction with SPI changes.
  474.  
  475.    The least impact of an SPI change will be to WF style reservations.
  476.    For such reservations, a new SENDER_TEMPLATE will need to be sent,
  477.    but no new RESV is required.  For SE style reservations, both a new
  478.    SENDER_TEMPLATE and a new RESV will need to be sent.  This will
  479.    result in changes to state, but should not affect data packet
  480.    delivery or actual resource allocation in any way.  The FF style will
  481.    be impacted the most.  Like with SE, both PATH and RESV messages will
  482.    need to be sent.  But, since FF style reservations result in sender
  483.    receiving its own resource allocation, resources will be allocated
  484.    twice for a period of time.  Or, even worse, there won't be enough
  485.    resources to support the new flow without first freeing the old flow.
  486.  
  487.    A way around this FF/SPI-change problem does exist.  Applications
  488.    that want FF style reservations can use multiple SE reservations.
  489.    Each real sender would have a separate SESSION (vDstPort) definition.
  490.    When it came time to switch SPIs, a shared reservation could be made
  491.    for the new SPI while the old SPI was still active.  Once the new SPI
  492.    was in use, the old reservation could be torn down.  This is less
  493.    than optimal, but will provide uninterrupted service for a set of
  494.    applications.
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Berger & O'Malley           Standards Track                     [Page 9]
  507.  
  508. RFC 2207               RSVP Extensions for IPSEC          September 1997
  509.  
  510.  
  511. 7   References
  512.  
  513.      [RFC 2205] Braden, R., Ed., Zhang, L., Estrin, D., Herzog, S.,
  514.                 and S. Jamin, "Resource ReSerVation Protocol (RSVP)
  515.                 -- Version 1 Functional Specification", RFC 2205,
  516.                 September 1997.
  517.  
  518.      [RFC 2209] Braden, R., Ed., Zhang, "Resource ReSerVation
  519.                 Protocol (RSVP) -- Version 1 Message Processing
  520.                 Rules", RFC 2209, September 1997.
  521.  
  522.      [RFC 1825] Atkinson, R., "Security Architecture for the Internet
  523.                 Protocol", RFC 1825, NRL, August 1995.
  524.  
  525.      [RFC 1826] Atkinson, R., "IP Authentication Header", RFC 1826, NRL,
  526.                 August 1995.
  527.  
  528.      [RFC 1827] Atkinson, R., "IP Encapsulating Security Payload", RFC
  529.                 1827, NRL, August 1995.
  530.  
  531. 8   Acknowledgments
  532.  
  533.    This note includes ideas originated and reviewed by a number of
  534.    individuals who did not participate in this note's writing.  The
  535.    authors would like to acknowledge their contribution.  We thank Ran
  536.    Atkinson <rja@cisco.com>, Fred Baker <fred@cisco.com>, Greg Troxel
  537.    <gdt@bbn.com>, John Krawczyk <jkrawczyk@BayNetworks.com> for much
  538.    appreciated input and feedback. Special appreciation goes to Bob
  539.    Braden <braden@isi.edu> for his detailed editorial and technical
  540.    comments.  We also thank Buz Owen, Claudio Topolcic, Andy Veitch, and
  541.    Luis Sanchez for their help in coming up with the proposed approach.
  542.    If any brain-damage exists in this note, it originated solely from
  543.    the authors.
  544.  
  545. 9   Authors' Addresses
  546.  
  547.    Lou Berger                           Tim O'Malley
  548.    FORE Systems                         BBN Corporation
  549.    6905 Rockledge Drive                 10 Moulton Street
  550.    Suite 800                            Cambridge, MA 02138
  551.    Bethesda, MD 20817
  552.  
  553.    Phone: 301-571-2534                  Phone: 617-873-3076
  554.    EMail: lberger@fore.com              EMail: timo@bbn.com
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Berger & O'Malley           Standards Track                    [Page 10]
  563.  
  564. RFC 2207               RSVP Extensions for IPSEC          September 1997
  565.  
  566.  
  567. A   Options Considered
  568.  
  569.    This sections reviews other approaches that were explored in
  570.    developing the described extensions.  They are included here to
  571.    provide additional context into the general problem.  All listed
  572.    options were rejected by the working group.
  573.  
  574.    Four other options were considered:
  575.  
  576.    1.  UDP Encapsulation
  577.        Add a UDP header between the IP and the IPSEC AH or ESP
  578.        headers.
  579.  
  580.    2.  FlowID Header Encapsulation
  581.        Add a new type of header between the IP and the IPSEC AH or
  582.        ESP headers.
  583.  
  584.    3.  IPSEC modification
  585.        Modify IPSEC headers so that there are appropriate fields in
  586.        same location as UDP and TCP ports.
  587.  
  588.    4.  AH Transparency
  589.        Skip over the Authentication Header packet classifier
  590.        processing.
  591.  
  592. A.1  UDP Encapsulation
  593.  
  594.    Since current SESSION and FILTER object expect UDP or TCP ports, this
  595.    proposal says let's just give it to them.  The basic concept is to
  596.    add a UDP port between the IP and AH/ESP headers.  The UDP ports
  597.    would provide the granularity of control that is need to associate
  598.    specific flows with reservations.
  599.  
  600.    Source and destination ports would be used, as normal, in RSVP
  601.    session definition and control.  The port fields would also need to
  602.    be used to identify the real transport level protocol (e.g. ESP)
  603.    being used. Also since many UDP ports are assigned as well known
  604.    ports, use of port numbers would be limited.  So, the port fields
  605.    would need to be used to unambiguously identify 1) the next level
  606.    protocol, 2) the RSVP session, and 3) the RSVP reservation.
  607.  
  608.    The advantages of this option is that no RSVP changes are required.
  609.    The disadvantages is that, since the headers aren't in the expected
  610.    location, RFC 1826 and RFC 1827 are violated.
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618. Berger & O'Malley           Standards Track                    [Page 11]
  619.  
  620. RFC 2207               RSVP Extensions for IPSEC          September 1997
  621.  
  622.  
  623. A.2  FlowID Header Encapsulation
  624.  
  625.    [This option was originally proposed by Greg Troxel <gdt@bbn.com>.]
  626.  
  627.    This option is very similar to option 1, but is more generic and
  628.    could be adopted as a standard solution.  The notion is to use UDP
  629.    like ports for the sole purpose of flow identification.  RSVP would
  630.    treat this new protocol exactly the same as UDP.
  631.  
  632.    The difference between this and UDP encapsulation is in destination
  633.    host processing.  The destination host would essentially ignore port
  634.    information and use a new field, protocol ID, to identify which
  635.    protocol should process the packet next.  Some examples of protocol
  636.    IDs correspond to TCP, UDP, ESP, or AH.
  637.  
  638.       The format of the FlowID Header would be:
  639.  
  640.   +---------------+---------------+---------------+---------------+
  641.   |          Source Port          |            Dest Port          |
  642.   +---------------+---------------+---------------+---------------+
  643.   |  Ver  |  Len  |  Protocol ID  |            Checksum           |
  644.   +---------------+---------------+---------------+---------------+
  645.    1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
  646.  
  647.        2 bytes source port                 4 bits length-32 (2)
  648.        2 bytes dest port                   8 bits protocol ID
  649.        4 bits version (1)                  16 bits checksum
  650.  
  651.    The advantage of this protocol is that flow identification is
  652.    separated from all other protocol processing.  The disadvantage is
  653.    that the addition of a header violates RFC 1826 and 1827, and also
  654.    that applications using RSVP will need to add this extra header on
  655.    all data packets whose transport headers do not have UDP/TCP like
  656.    ports.
  657.  
  658. A.3  IPSEC Protocol Modification
  659.  
  660.    The basic notion of this option is to leave RSVP as currently
  661.    specified and use the Security Association Identifier (SPI) found in
  662.    the IPSEC headers for flow identification.  There are two issues with
  663.    using the SPI. The first is that the SPI is located in the wrong
  664.    location when using Authentication (AH).  The second issue is how to
  665.    make use of the SPI.
  666.  
  667.    The first issue is easy to fix, but violates RFC 1826.  UDP and TCP
  668.    have port assignments in the first 4 bytes of their headers, each is
  669.    two bytes long, source comes first, then destination.  The ESP header
  670.    has the SPI in the same location as UDP/TCP ports, the AH doesn't.
  671.  
  672.  
  673.  
  674. Berger & O'Malley           Standards Track                    [Page 12]
  675.  
  676. RFC 2207               RSVP Extensions for IPSEC          September 1997
  677.  
  678.  
  679.    The IP Authentication Header has the following syntax:
  680.  
  681.   +---------------+---------------+---------------+---------------+
  682.   | Next Header   | Length        |           RESERVED            |
  683.   +---------------+---------------+---------------+---------------+
  684.   |                    Security Parameters Index                  |
  685.   +---------------+---------------+---------------+---------------+
  686.   |                                                               |
  687.   +     Authentication Data (variable number of 32-bit words)     |
  688.   |                                                               |
  689.   +---------------+---------------+---------------+---------------+
  690.    1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
  691.  
  692.    Simply reversing the first 4 bytes with the SPI we will have the SPI
  693.    in the location that RSVP expects.  This would be non-standard, or
  694.    require a major (i.e. not backward compatible) change to RSVP 1826.
  695.  
  696.    The second issue is how to make use of the SPI.  Per the current RSVP
  697.    specification, the first two bytes of a flow's SPI will need to be
  698.    carried in the PATH message and the second two bytes in the RESV
  699.    message.  The biggest problem is that the SPI is normally selected by
  700.    the receiver and is likely to be different for EACH sender.  (There
  701.    is a special case where the same SPI is used by all senders in a
  702.    multicast group.  But this is a special case.)  It is possible to
  703.    have the SPI selected prior to starting the RSVPsession.  This will
  704.    work for unicast and the special multicast case.  But using this
  705.    approach means that setup time will usually be extended by at least 1
  706.    round trip time.  Its not clear how to support SE and WF style
  707.    reservations.
  708.  
  709.    The advantage of this approach is no change to RSVP.  The
  710.    disadvantages are modification to RFC1827 and limited support of RSVP
  711.    reservation styles.
  712.  
  713. A.4  AH Transparency
  714.  
  715.    The source of the RSVP support of IPSEC protocols problem is that the
  716.    real transport header is not in the expected location.  With ESP
  717.    packets, the real source and destination ports are encrypted and
  718.    therefore useless to RSVP.  This is not the case for authentication.
  719.    For AH, the real header just follows the Authentication Header.  So,
  720.    it would be possible to use the real transport header for RSVP
  721.    session definition and reservation.
  722.  
  723.    To use the transport header, all that would need to be done is for
  724.    the flow classifier to skip over AHs before classifying packets.  No
  725.    modification to RSVP formats or setup processing would be required.
  726.    Applications would make reservations based on transport (i.e., UDP or
  727.  
  728.  
  729.  
  730. Berger & O'Malley           Standards Track                    [Page 13]
  731.  
  732. RFC 2207               RSVP Extensions for IPSEC          September 1997
  733.  
  734.  
  735.    TCP) ports as usual.
  736.  
  737.    The advantages of this approach are no changes to either IPSEC
  738.    protocols or RSVP formats.  The major disadvantage is that routers
  739.    and hosts must skip all AHs before classifying packets.  The working
  740.    group decided that it was best to have a consistent solution for both
  741.    AH and ESP.
  742.  
  743.  
  744.  
  745.  
  746.  
  747.  
  748.  
  749.  
  750.  
  751.  
  752.  
  753.  
  754.  
  755.  
  756.  
  757.  
  758.  
  759.  
  760.  
  761.  
  762.  
  763.  
  764.  
  765.  
  766.  
  767.  
  768.  
  769.  
  770.  
  771.  
  772.  
  773.  
  774.  
  775.  
  776.  
  777.  
  778.  
  779.  
  780.  
  781.  
  782.  
  783.  
  784.  
  785.  
  786. Berger & O'Malley           Standards Track                    [Page 14]
  787.  
  788.