rfc2207.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.


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.

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

8   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 <[e-mail]>, Fred Baker <[e-mail]>, Greg Troxel
   <[e-mail]>, John Krawczyk <[e-mail]> for much
   appreciated input and feedback. Special appreciation goes to Bob
   Braden <[e-mail]> 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.

9   Authors' Addresses

   Lou Berger                           Tim O'Malley
   FORE Systems                         BBN Corporation
   6905 Rockledge Drive                 10 Moulton Street
   Suite 800                            Cambridge, MA 02138
   Bethesda, MD 20817

   Phone: [phone]                  Phone: [phone]
   EMail: [e-mail]              EMail: [e-mail]







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


A   Options Considered

   This sections reviews other approaches that were explored in
   developing the described extensions.  They are included here to
   provide additional context into the general problem.  All listed
   options were rejected by the working group.

   Four other options were considered:

   1.  UDP Encapsulation
       Add a UDP header between the IP and the IPSEC AH or ESP
       headers.

   2.  FlowID Header Encapsulation
       Add a new type of header between the IP and the IPSEC AH or
       ESP headers.

   3.  IPSEC modification
       Modify IPSEC headers so that there are appropriate fields in
       same location as UDP and TCP ports.

   4.  AH Transparency
       Skip over the Authentication Header packet classifier
       processing.

A.1  UDP Encapsulation

   Since current SESSION and FILTER object expect UDP or TCP ports, this
   proposal says let's just give it to them.  The basic concept is to
   add a UDP port between the IP and AH/ESP headers.  The UDP ports
   would provide the granularity of control that is need to associate
   specific flows with reservations.

   Source and destination ports would be used, as normal, in RSVP
   session definition and control.  The port fields would also need to
   be used to identify the real transport level protocol (e.g. ESP)
   being used. Also since many UDP ports are assigned as well known
   ports, use of port numbers would be limited.  So, the port fields
   would need to be used to unambiguously identify 1) the next level
   protocol, 2) the RSVP session, and 3) the RSVP reservation.

   The advantages of this option is that no RSVP changes are required.
   The disadvantages is that, since the headers aren't in the expected
   location, RFC 1826 and RFC 1827 are violated.







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


A.2  FlowID Header Encapsulation

   [This option was originally proposed by Greg Troxel <[e-mail]>.]

   This option is very similar to option 1, but is more generic and
   could be adopted as a standard solution.  The notion is to use UDP
   like ports for the sole purpose of flow identification.  RSVP would
   treat this new protocol exactly the same as UDP.

   The difference between this and UDP encapsulation is in destination
   host processing.  The destination host would essentially ignore port
   information and use a new field, protocol ID, to identify which
   protocol should process the packet next.  Some examples of protocol
   IDs correspond to TCP, UDP, ESP, or AH.

      The format of the FlowID Header would be:

  +---------------+---------------+---------------+---------------+
  |          Source Port          |            Dest Port          |
  +---------------+---------------+---------------+---------------+
  |  Ver  |  Len  |  Protocol ID  |            Checksum           |
  +---------------+---------------+---------------+---------------+
   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

       2 bytes source port                 4 bits length-32 (2)
       2 bytes dest port                   8 bits protocol ID
       4 bits version (1)                  16 bits checksum

   The advantage of this protocol is that flow identification is
   separated from all other protocol processing.  The disadvantage is
   that the addition of a header violates RFC 1826 and 1827, and also
   that applications using RSVP will need to add this extra header on
   all data packets whose transport headers do not have UDP/TCP like
   ports.

A.3  IPSEC Protocol Modification

   The basic notion of this option is to leave RSVP as currently
   specified and use the Security Association Identifier (SPI) found in
   the IPSEC headers for flow identification.  There are two issues with
   using the SPI. The first is that the SPI is located in the wrong
   location when using Authentication (AH).  The second issue is how to
   make use of the SPI.

   The first issue is easy to fix, but violates RFC 1826.  UDP and TCP
   have port assignments in the first 4 bytes of their headers, each is
   two bytes long, source comes first, then destination.  The ESP header
   has the SPI in the same location as UDP/TCP ports, the AH doesn't.



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


   The IP Authentication Header has the following syntax:

  +---------------+---------------+---------------+---------------+
  | Next Header   | Length        |           RESERVED            |
  +---------------+---------------+---------------+---------------+
  |                    Security Parameters Index                  |
  +---------------+---------------+---------------+---------------+
  |                                                               |
  +     Authentication Data (variable number of 32-bit words)     |
  |                                                               |
  +---------------+---------------+---------------+---------------+
   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

   Simply reversing the first 4 bytes with the SPI we will have the SPI
   in the location that RSVP expects.  This would be non-standard, or
   require a major (i.e. not backward compatible) change to RSVP 1826.

   The second issue is how to make use of the SPI.  Per the current RSVP
   specification, the first two bytes of a flow's SPI will need to be
   carried in the PATH message and the second two bytes in the RESV
   message.  The biggest problem is that the SPI is normally selected by
   the receiver and is likely to be different for EACH sender.  (There
   is a special case where the same SPI is used by all senders in a
   multicast group.  But this is a special case.)  It is possible to
   have the SPI selected prior to starting the RSVPsession.  This will
   work for unicast and the special multicast case.  But using this
   approach means that setup time will usually be extended by at least 1
   round trip time.  Its not clear how to support SE and WF style
   reservations.

   The advantage of this approach is no change to RSVP.  The
   disadvantages are modification to RFC1827 and limited support of RSVP
   reservation styles.

A.4  AH Transparency

   The source of the RSVP support of IPSEC protocols problem is that the
   real transport header is not in the expected location.  With ESP
   packets, the real source and destination ports are encrypted and
   therefore useless to RSVP.  This is not the case for authentication.
   For AH, the real header just follows the Authentication Header.  So,
   it would be possible to use the real transport header for RSVP
   session definition and reservation.

   To use the transport header, all that would need to be done is for
   the flow classifier to skip over AHs before classifying packets.  No
   modification to RSVP formats or setup processing would be required.
   Applications would make reservations based on transport (i.e., UDP or



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


   TCP) ports as usual.

   The advantages of this approach are no changes to either IPSEC
   protocols or RSVP formats.  The major disadvantage is that routers
   and hosts must skip all AHs before classifying packets.  The working
   group decided that it was best to have a consistent solution for both
   AH and ESP.












































Berger & O'Malley           Standards Track                    [Page 14]