rfc2207.txt

RFC 的详细文档！

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












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


        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.

4   Processing Rules

   This section presents additions to the Processing Rules presented in
   [RFC 2209].  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 [RFC 2205].  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.




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


     o  For PATH messages that contain the GPI SESSION object,
        end-stations must verify that the protocol ID 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 protocol ID 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
        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, protocol ID, 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, protocol Id, 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.



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


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

5   IANA Considerations

   The range of possible vDstPort values is broken down into sections,
   in a fashion similar to the UDP/TCP port ranges.

             0              Illegal Value
             1 - 10         Reserved. Contact authors.
             11 - 8191      Assigned by IANA
             8192 - 65535   Dynamic

   IANA is directed to assign the well-known vDstPorts using the
   following criteria:  Anyone who asks for an assigned vDstPort must
   provide a) a Point of Contact, b) a brief description of intended
   use, and c) a short name to be associated with the assignment (e.g.
   "ftp").

6   Security Considerations

   The same considerations stated in [RFC 2205], [RFC 1826], and [RFC
   1827] apply to the extensions described in this note.  There are two
   additional issue related to these extensions.

   First, the vDstPort mechanism represents another data element about
   the IP Flow that might be available to an adversary.  Such data might
   be useful to an adversary engaging in traffic analysis by monitoring
   not only the data packets of the IP Flow but also the RSVP control
   messages associated with that Flow.  Protection against traffic
   analysis attacks is outside the scope of this mechanism.  One
   possible approach to precluding such attacks would be deployment and
   use of appropriate link-layer confidentiality mechansisms, such as
   encryption.





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


   Secondly, 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
   applications.











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


7   References

     [RFC 2205] Braden, R., Ed., Zhang, L., Estrin, D., Herzog, S.,
                and S. Jamin, "Resource ReSerVation Protocol (RSVP)
                -- Version 1 Functional Specification", RFC 2205,
                September 1997.

     [RFC 2209] Braden, R., Ed., Zhang, "Resource ReSerVation
                Protocol (RSVP) -- Version 1 Message Processing
                Rules", RFC 2209, September 1997.

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

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