Network Working Group                                       M. Behringer
Internet-Draft                                            F. Le Faucheur
Intended status: Informational                         Cisco Systems Inc
Expires: August 21, 2008                               February 18, January 12, 2009                                  July 11, 2008

           Applicability of Keying Methods for RSVP Security
           draft-ietf-tsvwg-rsvp-security-groupkeying-00.txt
           draft-ietf-tsvwg-rsvp-security-groupkeying-01.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 21, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008). January 12, 2009.

Abstract

   The Resource reSerVation Protocol (RSVP) allows hop-by-hop
   authentication of RSVP neighbors.  This requires messages to be
   cryptographically signed using a shared secret between participating
   nodes.  This document compares group keying for RSVP with per
   neighbor or per interface keying, and discusses the associated key
   provisioning methods as well as applicability and limitations of
   these approaches.  Draft-weis-gdoi-for-rsvp provides an example of
   how  For example, the Group Domain of Interpretation
   (GDOI) could be used to distribute group keys to RSVP nodes.  The
   present document also discusses applicability of group keying to RSVP
   encryption.

Table of Contents

   1.  Introduction and Problem Statement . . . . . . . . . . . . . .  3
   2.  The RSVP Hop-by-Hop Trust Model  . . . . . . . . . . . . . . . . . . . . .  3
   3.  Applicability of Key types Types for RSVP  . . . . . . . . . . . . .  5
     3.1.  Interface and neighbor based keys  . . . . . . . . .  4
     3.1.  Interface based keys . . . .  5
     3.2.  Group keys . . . . . . . . . . . . . . .  4
     3.2.  Neighbor based keys . . . . . . . . .  6
   4.  Key Provisioning Methods for RSVP  . . . . . . . . . .  5
     3.3.  Group keys . . . .  7
     4.1.  Static Key Provisioning  . . . . . . . . . . . . . . . . .  7
     4.2.  Dynamic Keying . . .  5
   4.  Key Provisioning Methods for RSVP . . . . . . . . . . . . . .  5
     4.1.  Static Key Provisioning . . . . .  8
       4.2.1.  Neighbor and Interface Based Key Negotiation . . . . .  8
       4.2.2.  Dynamic Group Key Distribution . . . . . . .  5
     4.2.  Per Neighbor Key Negotiation . . . . .  8
   5.  Specific Cases . . . . . . . . . .  6
     4.3.  Dynamic Group Key Distribution . . . . . . . . . . . . . .  6
   5.  Applicability of Various Keying Methods for  8
     5.1.  RSVP Notify Messages . . . . . . .  6
     5.1.  Per Neighbor or Per Interface Keys for Authentication  . .  6
     5.2.  Group Keys for Authentication . . . . . . . . . . .  8
     5.2.  RSVP-TE  . . .  6
     5.3.  Non-RSVP Hops . . . . . . . . . . . . . . . . . . . . . .  7
     5.4.  Subverted  9
   6.  Applicability of IPsec for RSVP Nodes  . . . . . . . . . . . . . . .  9
     6.1.  Applicability of IPsec ESP . . . .  8
     5.5.  RSVP Encryption . . . . . . . . . . . . 10
     6.2.  Applicability of Tunnel Mode . . . . . . . . .  9
     5.6.  RSVP Notify Messages . . . . . . 10
     6.3.  Applicability of Transport Mode  . . . . . . . . . . . . .  9
   6. 11
   7.  End Host Considerations  . . . . . . . . . . . . . . . . . . . 10
   7. 11
   8.  Applicability to Other Architectures and Protocols . . . . . . 10
   8.  Security Considerations 11
   9.  Summary  . . . . . . . . . . . . . . . . . . . 11
   9.  Acknowledgements . . . . . . . . 12
   10. Security Considerations  . . . . . . . . . . . . . . . 11
   10. Changes to Previous Version . . . . 13
     10.1. Subverted RSVP Nodes . . . . . . . . . . . . . 11
     10.1. changes from behringer-00 to behringer-01 . . . . . . 13
   11. Acknowledgements . . 11
     10.2. changes from behringer-01 to ietf-00 . . . . . . . . . . . 12
   11. Informative References . . . . . . . . . . 14
   12. Changes to Previous Version  . . . . . . . . . . 12
   Authors' Addresses . . . . . . . 14
     12.1. changes from behringer-00 to behringer-01  . . . . . . . . 14
     12.2. changes from behringer-01 to ietf-00 . . . . . . . . . 13
   Intellectual Property and Copyright Statements . . 14
     12.3. changes from ietf-00 to ietf-01  . . . . . . . . 14

1.  Introduction and Problem Statement

   The Resource reSerVation . . . . . 15
   13. Informative References . . . . . . . . . . . . . . . . . . . . 15
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
   Intellectual Property and Copyright Statements . . . . . . . . . . 18

1.  Introduction and Problem Statement

   The Resource reSerVation Protocol [RFC2205] allows hop-by-hop
   authentication of RSVP neighbors, as specified in [RFC2747].  In this
   mode, an integrity object is attached to each RSVP message to
   transmit a keyed message digest.  This message digest allows the
   recipient to verify the authenticity of the RSVP node that sent the
   message, and to validate the integrity of the message.  Through the
   inclusion of a sequence number in the scope of the digest, the digest
   also offers replay protection.

   [RFC2747] does not dictate how the key for the integrity operation is
   derived.  Currently, most implementations of RSVP use a statically
   configured key, per interface or per neighbor.  However, to manually
   configure key per router pair across an entire network is
   operationally hard, especially for key changes.  Effectively, many
   users of RSVP therefore resort to the same key throughout their RSVP
   network, and change it rarely if ever, because of the operational
   burden.  [RFC3562] however recommends regular key changes, at least
   every 90 days.

   [I-D.weis-gdoi-for-rsvp]

   [I-D.weis-gdoi-mac-tek] provides an example of how group keys could
   be dynamically distributed to a set of RSVP routers and updated,
   using GDOI ([RFC3547]) for the actual key distribution.

   The present document discusses the various keying methods and their
   applicability to different RSVP deployment environments, for both
   message integrity and encryption.  It does not mandate any particular
   method, but is meant as a comparative guideline to understand where
   each RSVP keying method is best deployed, and its limitations.
   Furthermore, it discusses how RSVP hop by hop authentication is
   impacted in the presence of non-RSVP nodes, or subverted nodes, in
   the reservation path.

   The document "RSVP Security Properties" ([RFC4230]) provides an
   overview of RSVP security, including RSVP Cryptographic
   Authentication [RFC2747], but does not discuss key management.  It
   states that "RFC 2205 assumes that security associations are already
   available".  The present document focuses specifically on key
   management with different key types, including group keys.  Therefore
   this document complements [RFC4230].

2.  The RSVP Hop-by-Hop Trust Model

   Many protocol security mechanisms used in networks require and use
   per peer authentication.  Each hop authenticates its neighbor with a
   shared key or certificate.  This is also the model used for RSVP.

   Trust in this model is transitive.  Each RSVP node trusts explicitely
   only its RSVP next hop peers, through the message digest contained in
   the INTEGRITY object.  The next hop RSVP speaker in turn trusts its
   own peers and so on.  See also the document ""RSVP "RSVP security
   properties" [RFC4230] for more background.

   The keys used for generating the RSVP messages can, in particular, be
   group keys (for example distributed via GDOI [RFC3547], as discussed
   in [I-D.weis-gdoi-for-rsvp]).  The trust model is the same as for
   RSVP authentication.  This is described in more detail in the section
   "Using GDOI For RSVP Encryption" in section 5.5. [I-D.weis-gdoi-mac-tek]).

   The trust an RSVP node has to another RSVP node has an explicit and
   an implicit component.  Explicitely the node trusts the other node to
   maintain the RSVP messages intact or confidential, depending on
   whether authentication or encryption (or both) is used.  This means
   only that the message has not been altered or seen by another, non-
   trusted node.  Implicitely each node trusts each other node with
   which it has a trust relationship established via the mechanisms here
   to adhere to the protocol specifications laid out by the various
   standards.  Note that in any group keying scheme like GDOI a node
   trusts explicitely as well as implicitely all the other members of
   the group.

   The RSVP protocol can operate in the presence of a non-RSVP router in
   the path from the sender to the receiver.  The non-RSVP hop will
   ignore the RSVP message and just pass it along.  The next RSVP node
   can then process the RSVP message.  For RSVP authentication or
   encryption to work in this case, the key used for computing the RSVP
   message digest needs to be shared by the two RSVP neighbors, even if
   they are not IP neighbors.  However, in the presence of non-RSVP
   hops, while an RSVP node always know the next IP hop before
   forwarding an RSVP Message, it does not always know the RSVP next
   hop.  In fact, part of the role of a Path message is precisely to
   discover the RSVP next hop (and to dynamically re-discover it when it
   changes, for example because of a routing change).  Thus, the
   presence of non-RSVP hops impacts operation of RSVP authentication or
   encryption and may influence the selection of keying approaches.  This is further discussed

   Figure 1 illustrates this scenario.  R2 in
   Section 5.3.

3.  Key types for this picture does not
   participate in RSVP, the other nodes do.  In this case, R2 will pass
   on any RSVP

3.1.  Interface based keys

   Most current messages unchanged, and will ignore them.

                       ----R3---
                      /         \
     sender----R1---R2(*)       R4----receiver
                      \         /
                       ----R5---
   (*) Non-RSVP hop

                   Figure 1: A non-RSVP Node in the path

   This creates a challenge for RSVP authentication implementations support interface
   based RSVP keys.  When and encrpytion.  In
   the interface is point-to-point (and therefore presence of a non-RSVP hop, with some RSVP messages such as a
   PATH message, an RSVP router only has a single does not know the RSVP neighbor on each interface),
   this is similar to neighbor based keys next hop for that
   message at the time of forwarding it.  For example, in Figure 1, R1
   knows that the next IP hop for a Path message addresed to the
   receiver is R2, but it does necessarily not know if the RSVP next hop
   is R3 or R5.

   This means that per interface and per neighbor keys cannot easily be
   used in the presence of non-RSVP routers on the path between senders
   and receivers.

   By contrast, group keying will naturally work in the presence of non-
   RSVP routers.  Referring back to Figure 1, with group keying, R1
   would use the group key to sign a Path message addressed to the
   receiver and forwards it to R2.  Being a non-RSVP node, R2 and will
   ignore and forward the Path message to R3 or R5 depending on the
   current shortest path as determined by routing.  Whether it is R3 or
   R5, the RSVP router that receives the Path message will be able to
   authenticate it successfully with the group key.

3.  Applicability of Key Types for RSVP

3.1.  Interface and neighbor based keys

   Most current RSVP authentication implementations support interface
   based RSVP keys.  When the interface is point-to-point (and therefore
   an RSVP router only has a single RSVP neighbor on each interface),
   this is equivalent to neighbor based keys in the sense that a
   different key is used for each neighbor.  However, when the interface
   is multipoint, all RSVP speakers on a given subnet have to share the
   same key in this model, which makes it unsuitable for deployment
   scenarios where different trust groups share a subnet, for example
   Internet exchange points.  In such a case, neighbor based keys are
   required.

3.2.  Neighbor

   With neighbor based keys

   In this model, keys, an RSVP key is bound to an interface plus a
   neighbor on that interface.  It allows the distinction of different
   trust groups on a single subnet.  (Assuming that layer-2 security is
   correctly implemented to prevent layer-2 attacks.)

3.3.  Group

   Per interface and per neighbor keys

   Here, all members of can be used within a group of RSVP nodes share single
   security domain.  As mentioned above, per interface keys are only
   applicable when all the same nodes reachable on the specific interface
   belong to the same security domain.

   These key types can also be used between security domains, since they
   are specific to a particular interface or neighbor.  Again, interface
   level keys can only be deployed safely when all the reachable
   neighbors on the interface belong to the same security domain.

   As discussed in the previous section, per neighbor and per interface
   keys can not be used in the presence of non-RSVP hops.

3.2.  Group keys

   Here, all members of a group of RSVP nodes share the same key.  This
   implies that a node uses the same key regardless of the next RSVP hop
   that will process the message (within the group of nodes sharing the
   particular key).  It also implies that a node will use the same key
   on the receiving as on the sending side (when exchanging RSVP
   messages withn within the group).

4.  Key Provisioning Methods for RSVP

4.1.  Static Key Provisioning

   The simplest way

   Group keys apply naturally to implement intra-domain RSVP authentication is to use static,
   preconfigured keys.  Static keying can be used with interface based authentication, since
   all RSVP nodes implicitely trust each other.  Using group keys, neighbor based keys or they
   extend this trust to the group keys.

   However, such static key provisioning server.  This is expensive on the operational
   side, since no secure automated mechanism can represented in
   Figure 2.

         ......GKS1.............
         :    :   :   :        :
         :    :   :   :        :
     source--R1--R2--R3-----destination
     |                                |
     |<-----domain 1----------------->|

        Figure 2: Group Key Server within a single security domain

   A single group key cannot normally be used, used to cover multiple security
   domains however, because by definition the different domains do not
   trust each other and initial
   provisioning as well as would not be willing to trust the same group key updates require configuration.  This
   method is therefore mostly useful for small deployments, where
   server.  For a single group key
   changes can to be carried out manually, or used in several security
   domains, there is a need for deployments with
   automated configuration tools which support key changes.

   Static a single group key provisioning server, which is therefore not an ideal model
   trusted by both sides.  While this is theoretically possible, in a large
   network.

   Often, the number of interconnection points across two domains where
   RSVP
   practice it is allowed to transit unlikely that there is relatively small and well controlled.
   Also, the different domains may not be in a position to use an
   infrastructure single such entity trusted by
   both domains.  Figure 3 illustrates this setup.

         ...............GKS1....................
         :    :   :   :        :   :   :       :
         :    :   :   :        :   :   :       :
     source--R1--R2--R3--------R4--R5--R6--destination
     |                  |    |                      |
     |<-----domain 1--->|    |<-------domain 2----->|

        Figure 3: A Single Group Key Server across security domains to update keys on both sides.
   Thus, manually configured keys may be applicable to inter-domain RSVP
   authentication.

   Since it is not

   A more practical to carry out the key change at the exact
   same time on both sides, some grace period needs to be implemented
   during which an RSVP node will accept both the old and the new key.
   Otherwise, approach for RSVP operation would suffer interruptions.

4.2.  Per Neighbor Key Negotiation

   To avoid the problem of manual across security domains,
   is to use a separate group key provisioning server for each security domain, and updates in static
   key deployments, key negotiation between RSVP neighbors could be
   used.  Key negotiation could be used
   to derive either use per interface or per neighbor based keys.  However, existing key negotiation protocols
   such as IKEv1[RFC2409] or IKEv2 [RFC4306] may not be appropriate in
   all environments because of the relative complexity of the protocols
   and related operations.

4.3.  Dynamic Group Key Distribution

   With this approach, group keys are dyanmically distributed among a
   set of RSVP routers.  For example, [I-D.weis-gdoi-for-rsvp] describes
   a mechanism to distribute group keys to a group of RSVP speakers,
   using GDOI [RFC3547].  In this solution, a key server authenticates
   each of the RSVP nodes independently, and then distributes a group
   key to the entire group.

5.  Applicability of Various Keying Methods for RSVP

5.1.  Per Neighbor or Per Interface Keys for Authentication

   Per interface and per neighbor keys can be used within a single
   security domain.  As mentioned above, per interface keys are only
   applicable when all the hosts reachable on the specific interface
   belong to the same security domain.

   These key types can also be used authentication between security domains, since they
   are specific to a particular interface or neighbor.  Again, interface
   level keys can only be deployed safely when all the reachable
   neighbors on the interface belong to the same security domain.

   As discussed in Section 5.3, per neighbor and per interface keys can
   not be used in the presence of non-RSVP hops.

5.2.  Group Keys for Authentication

   Group keys apply naturally to intra-domain RSVP authentication, since
   all RSVP nodes implicitely trust each other.  Using group keys, they
   extend this trust to the group key server.  This is represented in two
   domains.  Figure 1.

         ......GKS1............. 4 shows this set-up.

         ....GKS1......        ....GKS2.........
         :    :   :   :        :   :   :       :
         :    :
     source--R1--R2--R3-----destination   :   :        :   :   :       :
     source--R1--R2--R3--------R4--R5--R6--destination
     |                  |    |                      |
     |<-----domain 1----------------->| 1--->|    |<-------domain 2----->|

             Figure 1: Group 4: A group Key Server within a single per security domain

   A single

   As discussed in section 2, group key cannot normally keying can be used to cover multiple security
   domains however, because by definition in the different domains do not
   trust each other and would not be willing presence
   of non-RSVP hops.

4.  Key Provisioning Methods for RSVP

4.1.  Static Key Provisioning

   The simplest way to trust the same group key
   server.  For a single group key implement RSVP authentication is to use static,
   preconfigured keys.  Static keying can be used in several security
   domains, there with interface based
   keys, neighbor based keys or group keys.

   However, such static key provisioning is a need expensive on the operational
   side, since no secure automated mechanism can be used, and initial
   provisioning as well as key updates require configuration.  This
   method is therefore mostly useful for a single group small deployments, where key server,
   changes can be carried out manually, or for deployments with
   automated configuration tools which support key changes.

   Static key provisioning is
   trusted by both sides.  While this is theoretically possible, therefore not an ideal model in
   practice it a large
   network.

   Often, the number of interconnection points across two domains where
   RSVP is unlikely that there allowed to transit is relatively small and well controlled.
   Also, the different domains may not be in a single such entity position to use an
   infrastructure trusted by both domains.  Figure 2 illustrates this setup.

         ...............GKS1....................
         :    :   :   :        :   :   :       :
         :    :   :   :        :   :   :       :
     source--R1--R2--R3--------R4--R5--R6--destination
     |                  |    |                      |
     |<-----domain 1--->|    |<-------domain 2----->|

        Figure 2: A Single Group Key Server across security domains

   A more practical approach for RSVP operation across security domains,
   is to update keys on both sides.
   Thus, manually configured keys may be applicable to inter-domain RSVP
   authentication.

   Since it is not feasible to carry out the key change at the exact
   same time on both sides, some grace period needs to be implemented
   during which an RSVP node will accept both the old and the new key.
   Otherwise, RSVP operation would suffer interruptions.  (Note that
   also with dynamic keying approaches there can be a grace period where
   two keys are valid at the same time; however, the grace period in
   manual keying tends to be significantly longer than with dynamic key
   rollover schemes.)

4.2.  Dynamic Keying

4.2.1.  Neighbor and Interface Based Key Negotiation

   To avoid the problem of manual key provisioning and updates in static
   key deployments, key negotiation between RSVP neighbors could be used
   to derive either interface or neighbor based keys.  However, existing
   key negotiation protocols such as IKEv1 [RFC2409] or IKEv2 [RFC4306]
   may not be appropriate in all environments because of the relative
   complexity of the protocols and related operations.

4.2.2.  Dynamic Group Key Distribution

   With this approach, group keys are dyanmically distributed among a
   set of RSVP routers.  For example, [I-D.weis-gdoi-mac-tek] describes
   a mechanism to distribute group keys to a group of RSVP speakers,
   using GDOI [RFC3547].  In this solution, a key server authenticates
   each of the RSVP nodes independently, and then distributes a group
   key to the entire group.

5.  Specific Cases

5.1.  RSVP Notify Messages

   [RFC3473] introduces the Notify message and allows such Notify
   messages to be sent in a non-hop-by-hop fashion.  As discussed in the
   Security Considerations section of [RFC3473], this can interfere with
   RSVP's hop-by-hop integrity and authentication model.  [RFC3473]
   describes how standard IPsec based integrity and authentication can
   be used to protect Notify messages.  We observe that, alternatively,
   in some environments, group keying may allow use of regular RSVP
   authentication ([RFC2747]) for protection of non-hop-by-hop Notify
   messages.  For example, this may be applicable to controlled
   environments where nodes invoking notification requests are known to
   belong to the same key group as nodes generating Notify messages.

5.2.  RSVP-TE

   Use of RSVP authentication for RSVP-TE [RFC3209] and for RSVP-TE Fast
   Reroute [RFC4090] deserve additional considerations.  For example,
   with the facility backup method of Fast Reroute, a separate backup tunnel from
   the Point of Local Repair (PLR) to the Merge Point (MP) is used to
   protect Label Switched Paths (protected LSPs) from the failure of a
   facility (e.g. a router) located between the PLR and the MP.  During
   the failure of the facility, the PLR redirects a protected LSP inside
   the backup tunnel and also exchange RSVP control message for the
   maintenance the protected LSP over the backup tunnel.  Therefore,
   during the rerouted period, the PLR and the MP effectively become
   RSVP neighbors while they may not be directly connected to each other
   and thus do not behave as RSVP neighbors in the absence of failure.

   This point is raised in the Security Considerations section of
   [RFC4090] that says: "Note that the facility backup method requires
   that a PLR and its selected merge point trust RSVP messages received
   from each other."  We observe that such environments may benefit from
   group keying since the group key could also be easily used between
   the PLR and the MP.

6.  Applicability of IPsec for RSVP

   The discussions about the various keying methods in this document are
   applicable to the built-in authentication in the RSVP protocol, using
   the INTEGRITY object, as defined in [RFC2747].  In principle, they
   are also applicable to using IPsec to protect RSVP, however,
   [RFC2747] discusses in section 1.2 why IPsec is not an optimal choice
   to protect RSVP.  The key argument is that an IPsec SA and an RSVP SA
   are not based on the same parameters.  We believe that group key server keying
   may solve some of the issues mentioned.  [Editorial note: Detailed
   discussion will be added in the next version of the document.]

   To address specific requirements for each RSVP encryption, we focus the
   discussion here on IPsec ESP (Encapsulation security domain, and payload;
   [RFC4303]).

   IPsec Authentication Header (AH) is currently not considered in this
   document, since authentication is built into RSVP through the
   mechansims defined by [RFC2747].

6.1.  Applicability of IPsec ESP

   The keying approaches discussed in this document can also be used to use per
   encrypt the RSVP messages using IPsec [RFC4301], instead of, or in
   addition to authenticating them.  The same considerations apply for
   this case as discussed above for the authentication case.  Group keys
   are applicable only within a trusted domain, but they allow operation
   through non-RSVP speakers without further configuration.  Per
   interface or per peer authentication between neighbor keys work also inter-domain, but do not
   operate in the two
   domains.  Figure 3 shows this set-up.

         ....GKS1......        ....GKS2.........
         :    :   :   :        :   :   :       :
         :    :   :   :        :   :   :       :
     source--R1--R2--R3--------R4--R5--R6--destination
     |                  |    |                      |
     |<-----domain 1--->|    |<-------domain 2----->|

             Figure 3: presence of a non-RSVP router.

   The existing GDOI standard as described in [RFC3547] contains all
   relevant policy options to allow for RSVP encryption, and no
   extensions are necessary.  An example GDOI policy would be to encrypt
   all packets of the RSVP protocol itself (IP protocol 46).  A router
   implementing GDOI and IPsec is therefore able to implement RSVP
   encryption.

   Since in both tunnel mode and transport mode ESP does not protect the
   header (in tunnel mode the outer header), there is an issue with
   group Key Server per security domain

5.3.  Non-RSVP Hops

   In keying, when using ESP to secure the presence of RSVP packets: The packet
   header could be modified by a non-RSVP man-in-the-middle attack, replacing the
   destination address with another RSVP router in the path from network.  This
   router will receive the sender to packet, use the receiver, regular RSVP keeps working.  The non-RSVP node ignores group key to decrypt the RSVP message,
   encapsulated packet, and passes it then act on transparently the RSVP packet.  This way an
   attacker cannot create new reservations or affect existing ones, but
   he can "re-direct" reservations to parts of the next node.
   Figure 4 illustrates this scenario.  R2 in this picture does not
   participate in RSVP, network off the
   actual reservation path, thereby potentially denying resources to
   other nodes do.  In this case, R2 will pass applications on any RSVP messages unchanged, and will ignore them.

                       ----R3---
                      /         \
     sender----R1---R2(*)       R4----receiver
                      \         /
                       ----R5---
   (*) Non-RSVP hop

                   Figure 4: A non-RSVP Node in that part of the path

   However, this creates an additional challenge network.

6.2.  Applicability of Tunnel Mode

   IPsec tunnel mode for RSVP
   authentication.  In ESP encapsulates and encypts the presence of a non-RSVP hop, with some RSVP
   messages such as original
   packet, prepending a Path message, new IP tunnel header plus an RSVP router does not know the
   RSVP next hop for that message at ESP sub-header.
   The entire original packet is encrypted, and the time of forwarding it.  In
   fact, part integrity of the role of a Path message is precisely to discover
   original packet plus the ESP subheader is secured.  The new, outer IP
   header however is not cryptographically secured in this process.

   Protecting RSVP next hop (and to dynamically re-discover it when it changes, say
   because packets with IPsec ESP tunnel mode works with any of a routing change).  For example, in Figure 4, R1 knows
   that
   the next IP hop above described keying methods (interface, neighbor or group
   based), as long as there are no non-RSVP nodes on the path.  Note
   that for RSVP messages to be visible and considered at each hop, such
   a Path message addresed tunnel would not cross routers, but each RSVP node would establish
   a tunnel with each of its peers, effectively leading to link
   protection.

   In the receiver is
   R2, but it presence of a non-RSVP hop, tunnel mode can not be applied,
   because a router upstream a non-RSVP hop does necessarily not know if the RSVP next hop is R3 or
   R5.

   This means that per interface RSVP
   hop, and per neighbor keys cannot easily be
   used in can thus not apply the presence correct tunnel header.  This is
   independent of non-RSVP routers on the path between senders
   and receivers.

   By contrast, group keying will naturally work in the presence key type used.

6.3.  Applicability of non- Transport Mode

   IPsec transport mode for ESP, as defined in [RFC4303] is not suitable
   for securing RSVP routers.  Referring back to Figure 4, with group keying, R1
   would use the group key to sign a Path message addressed to messages, since those messages preserve the
   receiver
   original source and forwards it to R2.  Being destination.  [RFC4303] states explicitely that
   "the use of transport mode by an intermediate system (e.g., a non-RSVP node, R2 and will
   ignore and forward the Path message
   security gateway) is permitted only when applied to R3 packets whose
   source address (for outbound packets) or R5 depending on the
   current shortest path as determined by routing.  Whether it destination address (for
   inbound packets) is R3 or
   R5, the RSVP router that receives an address belonging to the Path message will intermediate system
   itself.  This would not be able to
   authenticate it successfully with the group key.

5.4.  Subverted RSVP Nodes

   A subverted node is defined here as an untrusted node, case for example
   because an intruder has gained control over it.  Since RSVP
   authentication Path messages.

7.  End Host Considerations

   Unless RSVP Proxy entities ([I-D.ietf-tsvwg-rsvp-proxy-approaches]
   are used, RSVP signaling is hop-by-hop controlled by end systems and not end-to-end, a subverted node
   routers.  As discussed in [RFC4230], RSVP allows both user-based
   security and host-based security.  User-based authentication aims at
   "providing policy based admission control mechanism based on user
   identities or application."  To identify the path breaks the chain of trust.  This is to a large extent
   independent of the type of keying used.

   For interface user or per-neighbor keying, the subverted node can now
   introduce fake messages to its neighbors.  This can be used in application,
   a
   variety of ways, for example by changing the receiver address policy element called AUTH_DATA, which is contained in the
   Path message, or by generating fake Path messages.  This allows path
   states to be
   POLICY_DATA object, is created on every by the RSVP router along any arbitrary path
   through daemon at the user's host
   and transmitted inside the RSVP domain.  That in itself could result in message.  This way, a form of
   Denial of Service by allowing exhaustion of some router resources
   (e.g. memory).  The subverted node could also generate fake Resv
   messages upstream corresponding user may
   authenticate to valid Path states.  In doing so,
   the subverted node can reserve excessive amounts of bandwidth thereby
   possibly performing a denial of service attack.

   Group keying allows the additional abuse of sending fake RSVP
   messages Policy Decision Point (or directly to any node in the RSVP domain, not just adjacent RSVP
   nodes.  However, first
   hop router).  Host-based security relies on the same mechanisms as
   between routers (i.e.  INTEGRITY object ) as specified in practice this [RFC2747].
   For host-based security, interface or neighbor based keys may be
   used, however, key management with pre-shared keys can be achieved to difficult
   in a large extent scale deployment, as described in section 4.  In principle
   an end host can also with per neighbor or interface keys, be part of a group key scheme, such as discussed above.
   Therefore GDOI.  If
   the impact end systems are part of subverted nodes on the path is comparable,
   independently whether per-interface, per-neighbor or same zone of trust as the network
   itself, group keys are
   used.

5.5.  RSVP Encryption

   The keying material can also be used extended to encrypt include the RSVP messages
   using IPsec [RFC2401], instead of, or end systems.  If
   the end systems and the network are in addition different zones of trust,
   group keying cannot be used.

8.  Applicability to authenticating
   them.  The same considerations apply for Other Architectures and Protocols

   While, so far, this case as discussed above
   for the authentication case.  Group keys are applicable document only within a
   trusted domain, but they allow operation through non-RSVP speakers
   without further configuration.  Per interface or per neighbor keys
   work also inter-domain, but do not operate in discusses RSVP security assuming
   the presence of a non- traditional RSVP router.

   The existing GDOI standard model as described in [RFC3547] contains all
   relevant policy options to allow for RSVP encryption, defined by [RFC2205] and no
   extensions are necessary.  An example GDOI policy would be to encrypt
   all packets of [RFC2747], the RSVP protocol itself (IP protocol 46).  A router
   implementing GDOI
   analysis is therefore automatically able to encrypt RSVP.

   [Editor's note: Applicability of tunnel vs transport mode still needs also applicable to be discussed.]

5.6. other RSVP Notify Messages

   [RFC3473] introduces the Notify message and allows such Notify
   messages to be sent in a non-hop-by-hop fashion.  As discussed in the
   Security Considerations section of [RFC3473], this can interfere with
   RSVP's hop-by-hop integrity and authentication model.  [RFC3473]
   describes how standard IPsec based integrity and authentication can
   be used deployment models as well
   as to protect Notify messages.  We observe that, alternatively,
   in some environments, group keying may allow similar protocols:

   o  Aggregation of RSVP for IPv4 and IPv6 Reservations [RFC3175]: This
      scheme defines aggregation of individual RSVP reservations, and
      discusses use of regular RSVP authentication ([RFC2747]) for protection of non-hop-by-hop Notify the signaling messages.  For example, this may be
      Group keying is applicable to controlled
   environments where nodes invoking notification requests are known to
   belong to this scheme, particularly when
      automatic Deaggregator discovery is used, since in that case, the same key group as nodes generating Notify messages.

6.  End Host Considerations

   Unless
      Aggregator does not know ahead of time which Deaggregator will
      intercept the initial end-to-end RSVP Proxy entities ([I-D.ietf-tsvwg-rsvp-proxy-approaches]
   are used, Path message.
   o  Generic Aggregate Resource ReSerVation Protocol (RSVP)
      Reservations [RFC4860]: This document also discusses aggregation
      of individual RSVP signaling is controlled by end systems reservations.  Here again, group keying applies
      and not
   routers.  As discussed is mentioned in [RFC4230], the Security Considerations section.
   o  Aggregation of Resource ReSerVation Protocol (RSVP) Reservations
      over MPLS TE/DS-TE Tunnels [RFC4804]([RFC4804]): This scheme also
      defines a form of aggregation of RSVP allows both user-based
   security reservation but this time
      over MPLS TE Tunnels.  Similarly, group keying may be used in such
      an environment.
   o  Pre-Congestion Notification (PCN): [I-D.ietf-pcn-architecture]
      defines an architecture for flow admission and host-based security.  User-based authentication aims at
   "providing policy termination based admission control mechanism
      on aggregated pre-congestion information.  One deployment model
      for this architecture is based on user
   identities or application."  To identify the user or IntServ over DiffServ: the application,
   a policy element called AUTH_DATA, which
      DiffServ region is contained in the
   POLICY_DATA object, PCN-enabled, RSVP signalling is created by used end-to-end
      but the PCN-domain is a single RSVP daemon at hop, i.e. only the user's host PCN-
      boundary-nodes process RSVP messages.  In this scenario, RSVP
      authentication may be required among PCN-boundary-nodes and transmitted inside the RSVP message.  This way, a user
      considerations about keying approaches discussed earlier in this
      document apply.  In particular, group keying may
   authenticate to facilitate
      operations since the Policy Decision Point (or directly to ingress PCN-boundary-node does not
      necessarily know ahead of time which Egress PCN-boundary-node will
      intercept and process the first
   hop router).  Host-based security relies on initial end-to-end Path message.  Note
      that from the same mechanisms as
   between routers (i.e.  INTEGRITY object ) as specified viewpoint of securing end-to-end RSVP, there are a
      lot of similarities in [RFC2747].
   For host-based security, interface scenarios involving RSVP Aggregation over
      aggregate RSVP reservations ([RFC3175], [RFC4860]), RSVP
      Aggregation over MPLS-TE tunnels ([RFC4804]), and RSVP
      (Aggregation) over PCN ingress-egress aggregates.

9.  Summary

   The following table summarizes the various approaches for RSVP
   keying, and their applicability to various RSVP scenarios.  In
   particular, such keying can be used for RSVP Authentication and/ or neighbor
   for RSVP Encryption (using ESP in Tunnel mode).

   +-----------------------------+--------------------+----------------+
   |                             | Neighbor/interface |   Group keys   |
   |                             |     based keys may be
   used, however, key management     |                |
   +-----------------------------+--------------------+----------------+
   | Works intra-domain          |         Yes        |       Yes      |
   | Works inter-domain          |         Yes        |       No       |
   | Works over non-RSVP hops    |         No         |     Yes (1)    |
   | Dynamic keying              |      Yes (IKE)     |  Yes (eg GDOI) |
   +-----------------------------+--------------------+----------------+

      Table 1: Overview of keying approaches and their applicability

   (1): RSVP authentication with pre-shared group keys works over non-RSVP nodes;
   RSVP encryption with IPsec ESP Tunnel mode does not.

   We also make the following observations:

   o  All key types can be difficult
   in a large scale deployment, as described in section 4.  In principle
   an end host can also be part of a group used statically, or with dynamic key scheme, such as GDOI.  If
      negotiation.  This impacts the end systems are part managability of the same zone of trust as solution, but
      not the network
   itself, group keying applicability itself.
   o  For encryption of RSVP messages IPsec ESP in tunnel mode can be extended to include the end systems.  If
      used.  There is however a security concern, see Section 6.1.
   o  There are some special cases in RSVP, like non-RSVP hosts, the end systems and
      "notify" message, the network are various RSVP deployment models discussed in different zones of trust,
      Section 8 and MPLS traffic engineering, which would benefit from a
      group keying cannot be used.

7.  Applicability to Other Architectures and Protocols

   While, so far, this approach.

10.  Security Considerations

   This entire document only discusses RSVP security; this section describes
   a specific security assuming
   the traditional RSVP model as defined by [RFC2205] and [RFC2747], the
   analysis is also applicable considerations relating to other subverted RSVP deployment models as well
   as to similar protocols:

   o  Aggregation of nodes

10.1.  Subverted RSVP Nodes

   A subverted node is defined here as an untrusted node, for IPv4 and IPv6 Reservations [RFC3175]: This
      scheme defines aggregation of individual RSVP reservations, and
      discusses use of example
   because an intruder has gained control over it.  Since RSVP
   authentication for the signaling messages.
      Group keying is applicable to this scheme, particularly when
      automatic Deaggregator discovery is used, since in that case, the
      Aggregator does not know ahead of time which Deaggregator will
      intercept the initial end-to-end RSVP Path message.
   o  Generic Aggregate Resource ReSerVation Protocol (RSVP)
      Reservations [RFC4860]: This document also discusses aggregation
      of individual RSVP reservations.  Here again, group keying applies hop-by-hop and is mentioned not end-to-end, a subverted node in
   the Security Considerations section.
   o  Aggregation path breaks the chain of Resource ReSerVation Protocol (RSVP) Reservations
      over MPLS TE/DS-TE Tunnels [RFC4804]([RFC4804]): trust.  This scheme also
      defines is to a form large extent
   independent of aggregation the type of RSVP reservation but this time
      over MPLS TE Tunnels.  Similarly, group keying may used.

   For interface or per-neighbor keying, the subverted node can now
   introduce fake messages to its neighbors.  This can be used in such
      an environment.

   o  Pre-Congestion Notification (PCN): [I-D.ietf-pcn-architecture]
      defines an architecture for flow admission and termination based
      on aggregated pre-congestion information.  One deployment model a
   variety of ways, for this architecture is based on IntServ over DiffServ: the
      DiffServ region is PCN-enabled, RSVP signalling is used end-to-end
      but example by changing the PCN-domain is a single RSVP hop, i.e. only receiver address in the PCN-
      boundary-nodes process RSVP
   Path message, or by generating fake Path messages.  In this scenario, RSVP
      authentication may  This allows path
   states to be required among PCN-boundary-nodes and created on every RSVP router along any arbitrary path
   through the
      considerations about keying approaches discussed earlier RSVP domain.  That in this
      document apply.  In particular, group keying may facilitate
      operations since the ingress PCN-boundary-node does not
      necessarily know ahead itself could result in a form of time which Egress PCN-boundary-node will
      intercept and process the initial end-to-end
   Denial of Service by allowing exhaustion of some router resources
   (e.g. memory).  The subverted node could also generate fake Resv
   messages upstream corresponding to valid Path message.  Note
      that from states.  In doing so,
   the viewpoint subverted node can reserve excessive amounts of securing end-to-end RSVP, there are bandwidth thereby
   possibly performing a
      lot denial of similarities in scenarios involving RSVP Aggregation over
      aggregate RSVP reservations ([RFC3175], [RFC4860]), service attack.

   Group keying allows the additional abuse of sending fake RSVP
      Aggregation over MPLS-TE tunnels ([RFC4804]), and
   messages to any node in the RSVP
      (Aggregation) over PCN ingress-egress aggregates.

8.  Security Considerations

   This entire document discusses domain, not just adjacent RSVP security.

9.
   nodes.  However, in practice this can be achieved to a large extent
   also with per neighbor or interface keys, as discussed above.
   Therefore the impact of subverted nodes on the path is comparable,
   independently whether per-interface, per-neighbor or group keys are
   used.

11.  Acknowledgements

   The authors would like to thank everybody who provided feedback on
   this document.  Specific thanks to Bob Briscoe, Hannes Tschofenig and
   Brian Weis.

10.

12.  Changes to Previous Version

   The following changes were made

   This section provides a change log.  It will be removed in version 01:

10.1. the final
   document:

12.1.  changes from behringer-00 to behringer-01

   o  New section "Applicability to Other Architectures and Protocols":
      Goal is to clarify the scope of this document: The idea presented
      here is also applicable to other architectures
      (PCN[I-D.ietf-pcn-architecture], RFC3175 and RFC4860, etc.
   o  Clarified the scope of this document versus RFC4230 (in the
      introduction, last paragraph).
   o  Added a section on "End Host Considerations".
   o  Expanded section 5.5 (RSVP Encryption) to clarify that GDOI
      contains all necessary mechanisms to do RSVP encrpytion.
   o  Tried to clarify the "trust to do what?" question raised by Bob
      Briscoe in a mail on 26 Jul 2007.  See the section on trust model.
   o  Lots of small editorial changes (references, typos, figures, etc).
   o  Added an Acknowledgements section.

10.2.

12.2.  changes from behringer-01 to ietf-00

   o  various edits to make it clearer that draft-weis-gdoi-for-rsvp is
      an example of how dynamic group keying could be achieved for RSVP
      and not necessraily necesarily the recommended solution

11.

12.3.  changes from ietf-00 to ietf-01

   o  Significant re-structuring of the entire document, to improve the
      flow, and provide more consistency in various sections.
   o  Moved the "Subverted RSVP nodes" discussion into the security
      considerations section.
   o  Added a "summary" section.
   o  Complete re-write of the old section 5.5 (RSVP encryption), and
      "promotion" to a separate section.
   o  Changed reference ID.weis-gdoi-for-rsvp to the new draft ID.weis-
      gdoi-mac-tek
   o  in several places, explicitely mentioned "encryption" for RSVP (in
      parallel to authentication).
   o  Various minor edits.

13.  Informative References

   [I-D.ietf-pcn-architecture]
              Eardley, P., "Pre-Congestion Notification Architecture",
              October 2007.
              draft-ietf-pcn-architecture-03 (work in progress),
              February 2008.

   [I-D.ietf-tsvwg-rsvp-proxy-approaches]
              Faucheur, F., Manner, J., Wing, D., and A. Guillou, "RSVP
              Proxy Approaches",
              draft-ietf-tsvwg-rsvp-proxy-approaches-03
              draft-ietf-tsvwg-rsvp-proxy-approaches-04 (work in
              progress), December 2007.

   [I-D.weis-gdoi-for-rsvp] April 2008.

   [I-D.weis-gdoi-mac-tek]
              Weis, B., "Group Domain of Interpretation (GDOI) support
              for RSVP", B. and S. Rowles, "GDOI Generic Message
              Authentication Code Policy", draft-weis-gdoi-mac-tek-00
              (work in progress), July 2007. 2008.

   [RFC2205]  Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
              Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
              Functional Specification", RFC 2205, September 1997.

   [RFC2401]  Kent, S. and R. Atkinson, "Security Architecture for the
              Internet Protocol", RFC 2401, November 1998.

   [RFC2409]  Harkins, D. and D. Carrel, "The Internet Key Exchange
              (IKE)", RFC 2409, November 1998.

   [RFC2747]  Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic
              Authentication", RFC 2747, January 2000.

   [RFC3175]  Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie,
              "Aggregation of RSVP for IPv4 and IPv6 Reservations",
              RFC 3175, September 2001.

   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
              Tunnels", RFC 3209, December 2001.

   [RFC3473]  Berger, L., "Generalized Multi-Protocol Label Switching
              (GMPLS) Signaling Resource ReserVation Protocol-Traffic
              Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.

   [RFC3547]  Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The
              Group Domain of Interpretation", RFC 3547, July 2003.

   [RFC3562]  Leech, M., "Key Management Considerations for the TCP MD5
              Signature Option", RFC 3562, July 2003.

   [RFC4090]  Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
              Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
              May 2005.

   [RFC4230]  Tschofenig, H. and R. Graveman, "RSVP Security
              Properties", RFC 4230, December 2005.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.

   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
              RFC 4303, December 2005.

   [RFC4306]  Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
              RFC 4306, December 2005.

   [RFC4804]  Le Faucheur, F., "Aggregation of Resource ReSerVation
              Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels",
              RFC 4804, February 2007.

   [RFC4860]  Le Faucheur, F., Davie, B., Bose, P., Christou, C., and M.
              Davenport, "Generic Aggregate Resource ReSerVation
              Protocol (RSVP) Reservations", RFC 4860, May 2007.

Authors' Addresses

   Michael H. Behringer
   Cisco Systems Inc
   Village d'Entreprises Green Side
   400, Avenue Roumanille, Batiment T 3
   Biot - Sophia Antipolis  06410
   France

   Email: mbehring@cisco.com
   URI:   http://www.cisco.com

   Francois Le Faucheur
   Cisco Systems Inc
   Village d'Entreprises Green Side
   400, Avenue Roumanille, Batiment T 3
   Biot - Sophia Antipolis  06410
   France

   Email: flefauch@cisco.com
   URI:   http://www.cisco.com

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).