draft-ietf-tsvwg-rsvp-security-groupkeying-05.txt   draft-ietf-tsvwg-rsvp-security-groupkeying-06.txt 
Network Working Group M. Behringer Network Working Group M. Behringer
Internet-Draft F. Le Faucheur Internet-Draft F. Le Faucheur
Intended status: Informational Cisco Systems Inc Intended status: Informational B. Weis
Expires: December 6, 2009 June 4, 2009 Expires: December 27, 2010 Cisco Systems
June 25, 2010
Applicability of Keying Methods for RSVP Security Applicability of Keying Methods for RSVP Security
draft-ietf-tsvwg-rsvp-security-groupkeying-05.txt draft-ietf-tsvwg-rsvp-security-groupkeying-06.txt
Abstract
The Resource reSerVation Protocol (RSVP) allows hop-by-hop integrity
protection of RSVP neighbors. This requires messages to be
cryptographically protected 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. The document also discusses
applicability of encrypting RSVP messages.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on December 27, 2010.
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 December 6, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
The Resource reSerVation Protocol (RSVP) allows hop-by-hop described in the Simplified BSD License.
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. The present document also discusses applicability
of group keying to RSVP encryption.
Table of Contents Table of Contents
1. Introduction and Problem Statement . . . . . . . . . . . . . . 3 1. Introduction and Problem Statement . . . . . . . . . . . . . . 3
2. The RSVP Hop-by-Hop Trust Model . . . . . . . . . . . . . . . 3 2. The RSVP Hop-by-Hop Trust Model . . . . . . . . . . . . . . . 3
3. Applicability of Key Types for RSVP . . . . . . . . . . . . . 5 3. Applicability of Key Types for RSVP . . . . . . . . . . . . . 5
3.1. Interface and neighbor based keys . . . . . . . . . . . . 5 3.1. Per interface and per neighbor keys . . . . . . . . . . . 5
3.2. Group keys . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Group keys . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Key Provisioning Methods for RSVP . . . . . . . . . . . . . . 7 4. Key Provisioning Methods for RSVP . . . . . . . . . . . . . . 8
4.1. Static Key Provisioning . . . . . . . . . . . . . . . . . 7 4.1. Static Key Provisioning . . . . . . . . . . . . . . . . . 8
4.2. Dynamic Keying . . . . . . . . . . . . . . . . . . . . . . 8 4.2. Dynamic Keying . . . . . . . . . . . . . . . . . . . . . . 8
4.2.1. Neighbor and Interface Based Key Negotiation . . . . . 8 4.2.1. Per Neighbor and Per Interface Key Negotiation . . . . 8
4.2.2. Dynamic Group Key Distribution . . . . . . . . . . . . 8 4.2.2. Dynamic Group Key Distribution . . . . . . . . . . . . 9
5. Specific Cases . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Specific Cases Supporting Use of Group Keying . . . . . . . . 9
5.1. RSVP Notify Messages . . . . . . . . . . . . . . . . . . . 8 5.1. RSVP Notify Messages . . . . . . . . . . . . . . . . . . . 9
5.2. RSVP-TE and GMPLS . . . . . . . . . . . . . . . . . . . . 8 5.2. RSVP-TE and GMPLS . . . . . . . . . . . . . . . . . . . . 9
6. Applicability of IPsec for RSVP . . . . . . . . . . . . . . . 10 6. Applicability of IPsec for RSVP . . . . . . . . . . . . . . . 10
6.1. General Considerations Using IPsec . . . . . . . . . . . . 10 6.1. General Considerations Using IPsec . . . . . . . . . . . . 10
6.2. Using IPsec ESP . . . . . . . . . . . . . . . . . . . . . 10 6.2. Comparing AH and the INTEGRITY Object . . . . . . . . . . 11
6.3. Using IPsec AH . . . . . . . . . . . . . . . . . . . . . . 11 6.3. Applicability of Tunnel Mode . . . . . . . . . . . . . . . 12
6.4. Applicability of Tunnel Mode . . . . . . . . . . . . . . . 11 6.4. Non-Applicability of Transport Mode . . . . . . . . . . . 12
6.5. Applicability of Transport Mode . . . . . . . . . . . . . 12 6.5. Applicability of Tunnel Mode with Address Preservation . . 12
6.6. Applicability of Tunnel Mode with Address Preservation . . 12 7. End Host Considerations . . . . . . . . . . . . . . . . . . . 13
7. End Host Considerations . . . . . . . . . . . . . . . . . . . 12
8. Applicability to Other Architectures and Protocols . . . . . . 13 8. Applicability to Other Architectures and Protocols . . . . . . 13
9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10.1. Subverted RSVP Nodes . . . . . . . . . . . . . . . . . . . 15 10.1. Subverted Nodes . . . . . . . . . . . . . . . . . . . . . 15
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
12. Changes to Previous Version . . . . . . . . . . . . . . . . . 15 12. Changes to Previous Version . . . . . . . . . . . . . . . . . 16
12.1. changes from behringer-00 to behringer-01 . . . . . . . . 16 12.1. changes from behringer-00 to behringer-01 . . . . . . . . 16
12.2. changes from behringer-01 to ietf-00 . . . . . . . . . . . 16 12.2. changes from behringer-01 to ietf-00 . . . . . . . . . . . 17
12.3. changes from ietf-00 to ietf-01 . . . . . . . . . . . . . 16 12.3. changes from ietf-00 to ietf-01 . . . . . . . . . . . . . 17
12.4. changes from ietf-01 to ietf-02 . . . . . . . . . . . . . 16 12.4. changes from ietf-01 to ietf-02 . . . . . . . . . . . . . 17
12.5. changes from ietf-02 to ietf-03 . . . . . . . . . . . . . 16 12.5. changes from ietf-02 to ietf-03 . . . . . . . . . . . . . 17
12.6. changes from ietf-03 to ietf-04 . . . . . . . . . . . . . 17 12.6. changes from ietf-03 to ietf-04 . . . . . . . . . . . . . 17
12.7. changes from ietf-04 to ietf-05 . . . . . . . . . . . . . 17 12.7. changes from ietf-04 to ietf-05 . . . . . . . . . . . . . 17
13. Informative References . . . . . . . . . . . . . . . . . . . . 17 12.8. changes from ietf-05 to ietf-06 . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 13. Informative References . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction and Problem Statement 1. Introduction and Problem Statement
The Resource reSerVation Protocol [RFC2205] allows hop-by-hop The Resource reSerVation Protocol [RFC2205] allows hop-by-hop
authentication of RSVP neighbors, as specified in [RFC2747]. In this authentication of RSVP neighbors, as specified in [RFC2747]. In this
mode, an integrity object is attached to each RSVP message to mode, an integrity object is attached to each RSVP message to
transmit a keyed message digest. This message digest allows the transmit a keyed message digest. This message digest allows the
recipient to verify the authenticity of the RSVP node that sent the recipient to verify the identity of the RSVP node that sent the
message, and to validate the integrity of the message. Through 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 inclusion of a sequence number in the scope of the digest, the digest
also offers replay protection. also offers replay protection.
[RFC2747] does not dictate how the key for the integrity operation is [RFC2747] does not dictate how the key for the integrity operation is
derived. Currently, most implementations of RSVP use a statically derived. Currently, most implementations of RSVP use a statically
configured key, per interface or per neighbor. However, to manually configured key, per interface or per neighbor. However, to manually
configure key per router pair across an entire network is configure a key per router pair across an entire network is
operationally hard, especially for key changes. Effectively, many operationally hard, especially when key changes are to be performed
users of RSVP therefore resort to the same key throughout their RSVP on a regular basis. Effectively, many users of RSVP therefore resort
network, and change it rarely if ever, because of the operational to using the same key throughout their RSVP network, and they change
burden. [RFC3562] however recommends regular key changes, at least it rarely if ever, because of the operational burden. It is however
every 90 days. often necessary to regularly change keys due to network operational
requirements.
The present document discusses the various keying methods and their This document discusses a variety of keying methods and their
applicability to different RSVP deployment environments, for both applicability to different RSVP deployment environments, for both
message integrity and encryption. It does not recommend any message integrity and encryption. It is meant as a comparative guide
particular method or protocol (e.g., RSVP authentication versus IPsec to understand where each RSVP keying method is best deployed, and the
AH), but is meant as a comparative guideline to understand where each limitations of each method. Furthermore, it discusses how RSVP hop
RSVP keying method is best deployed, and its limitations. by hop authentication is impacted in the presence of non-RSVP nodes,
Furthermore, it discusses how RSVP hop by hop authentication is or subverted nodes, in the reservation path.
impacted in the presence of non-RSVP nodes, or subverted nodes, in
the reservation path.
The document "RSVP Security Properties" ([RFC4230]) provides an The document "RSVP Security Properties" ([RFC4230]) provides an
overview of RSVP security, including RSVP Cryptographic overview of RSVP security, including RSVP Cryptographic
Authentication [RFC2747], but does not discuss key management. It Authentication [RFC2747], but does not discuss key management. It
states that "RFC 2205 assumes that security associations are already states that "RFC 2205 assumes that security associations are already
available". The present document focuses specifically on key available". The present document focuses specifically on key
management with different key types, including group keys. Therefore management with different key types, including group keys. Therefore
this document complements [RFC4230]. this document complements [RFC4230].
2. The RSVP Hop-by-Hop Trust Model 2. The RSVP Hop-by-Hop Trust Model
Many protocol security mechanisms used in networks require and use Many protocol security mechanisms used in networks require and use
per peer authentication. Each hop authenticates its neighbor with a per peer authentication. Each hop authenticates its neighbor with a
shared key or certificate. This is also the model used for RSVP. shared key or certificate. This is also the model used for RSVP.
Trust in this model is transitive. Each RSVP node trusts explicitly Trust in this model is transitive. Each RSVP node trusts explicitly
only its RSVP next hop peers, through the message digest contained in only its RSVP next hop peers, through the message digest contained in
the INTEGRITY object. The next hop RSVP speaker in turn trusts its the INTEGRITY object. The next hop RSVP speaker in turn trusts its
own peers and so on. See also the document "RSVP security own peers and so on. See also the document "RSVP security
properties" [RFC4230] for more background. properties" [RFC4230] for more background.
The keys used for generating the RSVP messages can, in particular, be The keys used for protecting RSVP messages can, in particular, be
group keys (for example distributed via GDOI [RFC3547], as discussed group keys (for example distributed via GDOI [RFC3547], as discussed
in [I-D.weis-gdoi-mac-tek]). in [I-D.weis-gdoi-mac-tek]). If a group key is used, the
authentication granularity becomes group membership, not (individual)
peer authentication.
The trust an RSVP node has to another RSVP node has an explicit and The trust an RSVP node has to another RSVP node has an explicit and
an implicit component. Explicitly the node trusts the other node to an implicit component. Explicitly the node trusts the other node to
maintain the RSVP messages intact or confidential, depending on maintain the RSVP messages intact or confidential, depending on
whether authentication or encryption (or both) is used. This means whether authentication or encryption (or both) are used. This means
only that the message has not been altered or seen by another, non- only that the message has not been altered or seen by another, non-
trusted node. Implicitly each node trusts each other node with which trusted node. Implicitly each node trusts each other node with which
it has a trust relationship established via the mechanisms here to it has a trust relationship established via the mechanisms here to
adhere to the protocol specifications laid out by the various adhere to the protocol specifications laid out by the various
standards. Note that in any group keying scheme like GDOI a node standards. Note that in any group keying scheme like GDOI a node
trusts all the other members of the group. trusts all the other members of the group (because the authentication
is now based on group membership, as noted above).
The RSVP protocol can operate in the presence of a non-RSVP router in 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 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 ignore the RSVP message and just pass it along. The next RSVP node
can then process the RSVP message. For RSVP authentication or can then process the RSVP message. For RSVP authentication or
encryption to work in this case, the key used for computing the RSVP 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 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 they are not IP neighbors. However, in the presence of non-RSVP
hops, while an RSVP node always knows the next IP hop before hops, while an RSVP node always knows the next IP hop before
forwarding an RSVP Message, it does not always know the RSVP next forwarding an RSVP Message, it does not always know the RSVP next
skipping to change at page 5, line 12 skipping to change at page 5, line 24
This creates a challenge for RSVP authentication and encryption. In This creates a challenge for RSVP authentication and encryption. In
the presence of a non-RSVP hop, with some RSVP messages such as a the presence of a non-RSVP hop, with some RSVP messages such as a
PATH message, an RSVP router does not know the RSVP next hop for that PATH message, an RSVP router does not know the RSVP next hop for that
message at the time of forwarding it. For example, in Figure 1, R1 message at the time of forwarding it. For example, in Figure 1, R1
knows that the next IP hop for a Path message addressed to the knows that the next IP hop for a Path message addressed to the
receiver is R2, but it does necessarily not know if the RSVP next hop receiver is R2, but it does necessarily not know if the RSVP next hop
is R3 or R5. is R3 or R5.
This means that per interface and per neighbor keys cannot easily be 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 used in the presence of non-RSVP routers on the path between senders
and receivers. and receivers. Section 4.3 of [RFC2747] states that "... the
receiver MAY initiate an integrity handshake with the sender." We
note that if this handshake is taking place, it can be used to
determine the identity of the next RSVP hop. In this case, non-RSVP
hops can be traversed also using per interface or per neighbor keys.
By contrast, group keying will naturally work in the presence of non- Group keying will naturally work in the presence of non-RSVP routers.
RSVP routers. Referring back to Figure 1, with group keying, R1 Referring back to Figure 1, with group keying, R1 would use the group
would use the group key to sign a Path message addressed to the key to protect a Path message addressed to the receiver and forwards
receiver and forwards it to R2. Being a non-RSVP node, R2 will it to R2. Being a non-RSVP node, R2 will ignore and forward the Path
ignore and forward the Path message to R3 or R5 depending on the message to R3 or R5 depending on the current shortest path as
current shortest path as determined by routing. Whether it is R3 or determined by routing. Whether it is R3 or R5, the RSVP router that
R5, the RSVP router that receives the Path message will be able to receives the Path message will be able to authenticate it
authenticate it successfully with the group key. successfully using the group key.
3. Applicability of Key Types for RSVP 3. Applicability of Key Types for RSVP
3.1. Interface and neighbor based keys 3.1. Per interface and per neighbor keys
Most current RSVP authentication implementations support interface Most current RSVP authentication implementations support per
based RSVP keys. When the interface is point-to-point (and therefore interface RSVP keys. When the interface is point-to-point (and
an RSVP router only has a single RSVP neighbor on each interface), therefore an RSVP router has only a single RSVP neighbor on each
this is equivalent to neighbor based keys in the sense that a interface), this is equivalent to per neighbor keys in the sense that
different key is used for each neighbor. However, when the interface a different key is used for each neighbor. However, when the
is multipoint, all RSVP speakers on a given subnet have to share the interface is multipoint, all RSVP speakers on a given subnet have to
same key in this model, which makes it unsuitable for deployment share the same key in this model. This makes it unsuitable for
scenarios where different trust groups share a subnet, for example deployment scenarios where nodes from different security domains are
Internet exchange points. In such a case, neighbor based keys are present on a subnet, for example Internet exchange points. A
security domain is defined here as a set of nodes that shares a
common RSVP security policy. In such cases, per neighbor keys are
required. required.
With neighbor based keys, an RSVP key is bound to an interface plus a With per neighbor keys, each RSVP key is bound to an interface plus a
neighbor on that interface. It allows the distinction of different neighbor on that interface. It allows for the existence of different
trust groups on a single interface and subnet. (Assuming that security domains on a single interface and subnet.
layer-2 security is correctly implemented to prevent layer-2
attacks.)
Per interface and per neighbor keys can be used within a single per interface and per neighbor keys can be used within a single
security domain. As mentioned above, per interface keys are only security domain. As mentioned above, per interface keys are only
applicable when all the nodes reachable on the specific interface applicable when all the nodes reachable on the specific interface
belong to the same security domain. belong to the same security domain.
These key types can also be used between security domains, since they These key types can also be used between security domains, since they
are specific to a particular interface or neighbor. Again, interface are specific to a particular interface or neighbor. Again, interface
level keys can only be deployed safely when all the reachable level keys can be deployed safely only when all the reachable
neighbors on the interface belong to the same security domain. neighbors on the interface belong to the same security domain.
Both monotonically increasing sequence number (e.g., the INTEGRITY
object simple sequence numbers [RFC2747], or the ESP and AH anti-
replay service [RFC4301] sequence numbers) and time based anti-replay
methods (e.g., the INTEGITY sequence numbers based on a clock
[RFC2747]) can be used with per neighbor and per interface keys.
As discussed in the previous section, per neighbor and per interface As discussed in the previous section, per neighbor and per interface
keys can not be used in the presence of non-RSVP hops. keys can not be used in the presence of non-RSVP hops.
3.2. Group keys 3.2. Group keys
Here, all members of a group of RSVP nodes share the same key. This In the case of group keys, all members of a group of RSVP nodes share
implies that a node uses the same key regardless of the next RSVP hop the same key. This implies that a node uses the same key regardless
that will process the message (within the group of nodes sharing the of the next RSVP hop that will process the message (within the group
particular key). It also implies that a node will use the same key of nodes sharing the particular key). It also implies that a node
on the receiving as on the sending side (when exchanging RSVP will use the same key on the receiving as on the sending side (when
messages within the group). exchanging RSVP messages within the group).
Group keys apply naturally to intra-domain RSVP authentication, since Group keys apply naturally to intra-domain RSVP authentication, where
all RSVP nodes implicitly trust each other. Using group keys, they all RSVP nodes are part of the same security domain and implicitly
extend this trust to the group key server. This is represented in trust each other. Using group keys, they extend this trust to the
Figure 2. group key server. This is represented in Figure 2.
......GKS1............. ......GKS1.............
: : : : : : : : : :
: : : : : : : : : :
source--R1--R2--R3-----destination source--R1--R2--R3-----destination
| | | |
|<-----domain 1----------------->| |<-----domain 1----------------->|
Figure 2: Group Key Server within a single security domain Figure 2: Group Key Server within a single security domain
skipping to change at page 7, line 5 skipping to change at page 7, line 34
: : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : :
source--R1--R2--R3--------R4--R5--R6--destination source--R1--R2--R3--------R4--R5--R6--destination
| | | | | | | |
|<-----domain 1--->| |<-------domain 2----->| |<-----domain 1--->| |<-------domain 2----->|
Figure 3: A Single Group Key Server across security domains Figure 3: A Single Group Key Server across security domains
A more practical approach for RSVP operation across security domains, A more practical approach for RSVP operation across security domains,
is to use a separate group key server for each security domain, and is to use a separate group key server for each security domain, and
to use per interface or per neighbor authentication between the two to use per interface or per neighbor keys between the two domains.
domains. Figure 4 shows this set-up. Figure 4 shows this setup.
....GKS1...... ....GKS2......... ....GKS1...... ....GKS2.........
: : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : :
source--R1--R2--R3--------R4--R5--R6--destination source--R1--R2--R3--------R4--R5--R6--destination
| | | | | | | |
|<-----domain 1--->| |<-------domain 2----->| |<-----domain 1--->| |<-------domain 2----->|
Figure 4: A group Key Server per security domain Figure 4: A group Key Server per security domain
As discussed in section 2, group keying can be used in the presence As discussed in Section 2, group keying can be used in the presence
of non-RSVP hops. of non-RSVP hops.
Because a group key may be used to verify messages from different
peers, monotonically increasing sequence number methods are not
appropriate. Time based anti-replay methods (e.g., the INTEGITY
sequence numbers based on a clock [RFC2747]) can be used with group
keys.
4. Key Provisioning Methods for RSVP 4. Key Provisioning Methods for RSVP
4.1. Static Key Provisioning 4.1. Static Key Provisioning
The simplest way to implement RSVP authentication is to use static, Static keys are preconfigured, either manually, or through a network
preconfigured keys. Static keying can be used with interface based management system, and not negotiated via a protocol. The simplest
keys, neighbor based keys or group keys. way to implement RSVP authentication is to use static keys. Static
keying can be used with per interface keys, per neighbor keys or
group keys.
However, such static key provisioning is expensive on the operational The provisioning of static keys requires either manual operator
side, since no secure automated mechanism can be used, and initial intervention on each node, or a network management system performing
provisioning as well as key updates require configuration. This the same task. Time synchronization of static key provisioning and
method is therefore mostly useful for small deployments, where key changes is critical, to avoid inconsistent keys within a security
changes can be carried out manually, or for deployments with domain.
automated configuration tools which support key changes.
Static key provisioning is therefore not an ideal model in a large Static key provisioning is therefore not an ideal model in a large
network. network.
Often, the number of interconnection points across two domains where Often, the number of interconnection points across two domains where
RSVP is allowed to transit is relatively small and well controlled. RSVP is allowed to transit is relatively small and well controlled.
Also, the different domains may not be in a position to use an Also, the different domains may not be in a position to use an
infrastructure trusted by both domains to update keys on both sides. infrastructure trusted by both domains to update keys on both sides.
Thus, manually configured keys may be applicable to inter-domain RSVP Thus, statically provisioned keys may be applicable to inter-domain
authentication. RSVP authentication.
Since it is not feasible to carry out the key change at the exact Since it is not feasible to carry out a key change at the exact same
same time on both sides, some grace period needs to be implemented time in communicating RSVP nodes, some grace period needs to be
during which an RSVP node will accept both the old and the new key. implemented during which an RSVP node will accept both the old and
Otherwise, RSVP operation would suffer interruptions. (Note that the new key. Otherwise, RSVP operation would suffer interruptions.
also with dynamic keying approaches there can be a grace period where (Note that also with dynamic keying approaches there can be a grace
two keys are valid at the same time; however, the grace period in period where two keys are valid at the same time; however, the grace
manual keying tends to be significantly longer than with dynamic key period in manual keying tends to be significantly longer than with
rollover schemes.) dynamic key rollover schemes.)
4.2. Dynamic Keying 4.2. Dynamic Keying
4.2.1. Neighbor and Interface Based Key Negotiation 4.2.1. Per Neighbor and Per Interface Key Negotiation
To avoid the problem of manual key provisioning and updates in static To avoid the problem of manual key provisioning and updates in static
key deployments, key negotiation between RSVP neighbors could be used key deployments, key negotiation between RSVP neighbors could be used
to derive either interface or neighbor based keys. However, existing to derive either per interface or per neighbor keys.
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 4.2.2. Dynamic Group Key Distribution
With this approach, group keys are dynamically distributed among a With this approach, group keys are dynamically distributed among a
set of RSVP routers. For example, [I-D.weis-gdoi-mac-tek] describes 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, a mechanism to distribute group keys to a group of RSVP speakers,
using GDOI [RFC3547]. In this solution, a key server authenticates using GDOI [RFC3547]. In this solution, a key server authenticates
each of the RSVP nodes independently, and then distributes a group each of the RSVP nodes independently, and then distributes a group
key to the entire group. key to the group as part of an encrypted and integrity protected key
agreement protocol. The authentication in this model can be based on
public key mechanisms, thereby avoiding the need for static key
provisioning.
5. Specific Cases 5. Specific Cases Supporting Use of Group Keying
5.1. RSVP Notify Messages 5.1. RSVP Notify Messages
[RFC3473] introduces the Notify message and allows such Notify [RFC3473] introduces the Notify message and allows such messages to
messages to be sent in a non-hop-by-hop fashion. As discussed in the be sent in a non-hop-by-hop fashion. As discussed in the Security
Security Considerations section of [RFC3473], this can interfere with Considerations section of [RFC3473], this can interfere with RSVP's
RSVP's hop-by-hop integrity and authentication model. [RFC3473] hop-by-hop integrity and authentication model. [RFC3473] describes
describes how standard IPsec based integrity and authentication can how standard IPsec based integrity and authentication can be used to
be used to protect Notify messages. We observe that, alternatively, protect Notify messages. We observe that, alternatively, in some
in some environments, group keying may allow use of regular RSVP environments, group keying may allow use of regular RSVP
authentication ([RFC2747]) for protection of non-hop-by-hop Notify authentication ([RFC2747]) for protection of non-hop-by-hop Notify
messages. For example, this may be applicable to controlled messages.
environments where nodes invoking notification requests are known to
belong to the same key group as nodes generating Notify messages. For example, RSVP Notify messages commonly used for traffic
engineering in MPLS networks are non-hop-by-hop messages. Such
messages may be sent from an ingress node directly to an egress node.
Group keying in such a case avoids the establishment of node-to-node
keying when node-to-node keying is not otherwise used.
5.2. RSVP-TE and GMPLS 5.2. RSVP-TE and GMPLS
Use of RSVP authentication for RSVP-TE [RFC3209] and for RSVP-TE Fast Use of RSVP authentication for RSVP-TE [RFC3209] and for RSVP-TE Fast
Reroute [RFC4090] deserves additional considerations. Reroute [RFC4090] deserves additional considerations.
With the facility backup method of Fast Reroute, a backup tunnel from With the facility backup method of Fast Reroute, a backup tunnel from
the Point of Local Repair (PLR) to the Merge Point (MP) is used to the Point of Local Repair (PLR) to the Merge Point (MP) is used to
protect Label Switched Paths (protected LSPs) against the failure of protect Label Switched Paths (protected LSPs) against the failure of
a facility (e.g. a router) located between the PLR and the MP. 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 During the failure of the facility, the PLR redirects a protected LSP
inside the backup tunnel and as a result, the PLR and MP then need to inside the backup tunnel and as a result, the PLR and MP then need to
exchange RSVP control messages between each other (e.g. for the exchange RSVP control messages between each other (e.g., for the
maintenance of the protected LSP). Some of the RSVP messages between maintenance of the protected LSP). Some of the RSVP messages between
the PLR and MP are sent over the backup tunnel (e.g. a Path message the PLR and MP are sent over the backup tunnel (e.g., a Path message
from PLR to MP) while some are directly addressed to the RSVP node from PLR to MP) while some are directly addressed to the RSVP node
(e.g. a Resv message from MP to PLR). During the rerouted period, (e.g., a Resv message from MP to PLR). During the rerouted period,
the PLR and the MP effectively become RSVP neighbors, while they may 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 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 RSVP neighbors in the absence of failure. This point is raised in
the Security Considerations section of [RFC4090] that says: "Note the Security Considerations section of [RFC4090] that says: "Note
that the facility backup method requires that a PLR and its selected that the facility backup method requires that a PLR and its selected
merge point trust RSVP messages received from each other." We merge point trust RSVP messages received from each other." We
observe that such environments may benefit from group keying: a group observe that such environments may benefit from group keying. A
key can be used among a set of routers enabled for Fast Reroute group key can be used among a set of routers enabled for Fast Reroute
thereby easily ensuring that a PLR and MP authenticate messages from thereby easily ensuring that PLR and MP authenticate messages from
each other, without requiring prior specific configuration of keys, each other can be authenticated, without requiring prior specific
or activation of key update mechanism, for every possible pair of PLR configuration of keys, or activation of key update mechanism, for
and MP. every possible pair of PLR and MP.
Where RSVP-TE or RSVP-TE Fast Reroute is deployed across AS Where RSVP-TE or RSVP-TE Fast Reroute is deployed across AS
boundaries (see [RFC4216]), the considerations presented above in boundaries (see [RFC4216]), the considerations presented above in
section 3.1 and 3.2 apply such that per interface or per neighbor section 3.1 and 3.2 apply, such that per interface or per neighbor
keys can be used between two RSVP neighbors in different ASes keys can be used between two RSVP neighbors in different ASes
(independently of the keying method used by the RSVP router to talk (independently of the keying method used by the RSVP router to talk
to the RSVP routers in the same AS). to the RSVP routers in the same AS).
[RFC4875] specifies protocol extensions for support of Point-to- [RFC4875] specifies protocol extensions for support of Point-to-
Multipoint (P2MP) RSVP-TE. In its security considerations section, Multipoint (P2MP) RSVP-TE. In its Security Considerations section,
[RFC4875] points out that RSVP message integrity mechanisms for hop- [RFC4875] points out that RSVP message integrity mechanisms for hop-
by-hop RSVP signaling apply to the hop-by-hop P2MP RSVP-TE signaling. by-hop RSVP signaling apply to the hop-by-hop P2MP RSVP-TE signaling.
In turn, we observe that the considerations in this document on In turn, we observe that the analyses in this document of keying
keying methods apply equally to P2MP RSVP-TE for the hop-by-hop methods apply equally to P2MP RSVP-TE for the hop-by-hop signaling.
signaling.
[RFC4206] defines LSP Hierarchy with GMPLS TE and uses non-hop-by-hop [RFC4206] defines LSP Hierarchy with GMPLS TE and uses non-hop-by-hop
signaling. Because it reuses LSP Hierarchy procedures for some of signaling. Because it reuses LSP Hierarchy procedures for some of
its operations, P2MP RSVP-TE also uses non-hop-by-hop signaling. its operations, P2MP RSVP-TE also uses non-hop-by-hop signaling.
Both LSP hierarchy and P2MP RSVP-TE rely on the security mechanisms Both LSP hierarchy and P2MP RSVP-TE rely on the security mechanisms
defined in [RFC3473] and [RFC4206] for non hop-by-hop RSVP-TE defined in [RFC3473] and [RFC4206] for non hop-by-hop RSVP-TE
signaling. We note that the observation in section 3.1 of this signaling. We note that the observation in Section 3.1 of this
document about use of group keying for protection of non-hop-by-hop document about use of group keying for protection of non-hop-by-hop
messages apply to protection of non-hop-by-hop signaling for LSP messages apply to protection of non-hop-by-hop signaling for LSP
Hierarchy and P2MP RSVP- TE. Hierarchy and P2MP RSVP- TE.
6. Applicability of IPsec for RSVP 6. Applicability of IPsec for RSVP
6.1. General Considerations Using IPsec 6.1. General Considerations Using IPsec
The discussions about the various keying methods in this document are The discussions about the various keying methods in this document are
also applicable when using IPsec to protect RSVP. Note that also applicable when using IPsec [RFC4301] to protect RSVP. Note
[RFC2747] states in section 1.2 that IPsec is not an optimal choice that [RFC2747] states in section 1.2 that IPsec is not an optimal
to protect RSVP. The key argument is that an IPsec SA and an RSVP SA choice to protect RSVP. The key argument is that an IPsec SA and an
are not based on the same parameters. However, when using group RSVP SA are not based on the same parameters. Nevertheless, IPsec
keying, IPsec can be used to protect RSVP. The potential issues and can be used to protect RSVP. Note that the SPD traffic selectors for
solutions using group keying are: related RSVP flows will not be constant. In some cases, the source
and destination addresses are end hosts, and sometimes they are RSVP
o [RFC2747] specifies in section 4.2, bullet 3, that both the key routers. Therefore, traffic selectors in the SPD should specify ANY
identifier and the sending system address are used to uniquely for the source address and destination addresses, and specify IP
determine the key. In a group keying scenario it would be protocol 46 (RSVP).
necessary to either store a list of senders to do this, or to not
use the sending system address to determine the key. Both methods
are valid, and one of the two approaches must be chosen. The pros
and cons are beyond the scope of this document.
o Anti-replay protection in a group keying scenario requires some
changes to the way [RFC2747] defines anti-replay. Possible
solutions are discussed in detail in [I-D.weis-gdoi-mac-tek]).
For example, when using counter-based methods with various senders
in a single SA, the same counter may be received more than once,
this conflicts with [RFC2747], which states that each counter
value may only be accepted once. Time based approaches are a
solution for group keying scenarios.
The document "The Multicast Group Security Architecture" [RFC3740] The document "The Multicast Group Security Architecture" [RFC3740]
defines in detail a "Group Security Association" (GSA). This defines in detail a "Group Security Association" (GSA). This
definition is also applicable in the context discussed here, and definition is also applicable in the context discussed here, and
allows the use of IPsec for RSVP. The existing GDOI standard allows the use of IPsec for RSVP. The existing GDOI standard
[RFC3547] contains all relevant policy options to secure RSVP with [RFC3547] manages group security associations, which can be used by
IPsec, and no extensions are necessary. An example GDOI policy would IPsec. An example GDOI policy would be to encrypt or authenticate
be to encrypt all packets of the RSVP protocol itself (IP protocol all packets of the RSVP protocol itself (IP protocol 46). A router
46). A router implementing GDOI and IPsec protocols is therefore implementing GDOI and the AH and/or ESP protocols is therefore able
able to implement RSVP encryption. to implement this policy.
6.2. Using IPsec ESP
In both tunnel mode and transport mode, ESP does not protect the Because the traffic selectors for an SA cannot be predicted, SA
header (in tunnel mode the outer header). This is an issue with lookup should use only the SPI (or SPI plus protocol).
group keying when using ESP to secure the RSVP packets: the packet
header could be modified by a man-in-the-middle attack, replacing the
destination address with another RSVP router in the network. This
router will receive the packet, use the group key to decrypt the
encapsulated packet, and then act on 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 network off the
actual reservation path, thereby potentially denying resources to
other applications on that part of the network.
6.3. Using IPsec AH 6.2. Comparing AH and the INTEGRITY Object
The INTEGRITY object defined by [RFC2747] provides integrity The INTEGRITY object defined by [RFC2747] provides integrity
protection for RSVP also in a group keying context, as discussed protection for RSVP also in a group keying context, as discussed
above. IPsec AH [RFC4302] is an alternative method to provide above. AH [RFC4302] is an alternative method to provide integrity
integrity protection for RSVP packets. protection for RSVP packets.
The RSVP INTEGRITY object protects the entire RSVP message, but does The RSVP INTEGRITY object protects the entire RSVP message, but does
not protect the IP header of the packet nor the IP options (in IPv4) not protect the IP header of the packet nor the IP options (in IPv4)
or extension headers (in IPv6). or extension headers (in IPv6).
IPsec AH tunnel mode (transport mode is not appliable, see section AH tunnel mode (transport mode is not applicable, see section 6.4)
6.5) protects the entire original IP packet, including the IP header protects the entire original IP packet, including the IP header of
of the original IP packet ("inner header"), IP options or extension the original IP packet ("inner header"), IP options or extension
headers, plus the entire RSVP packet. It also protects the immutable headers, plus the entire RSVP packet. It also protects the immutable
fields of the outer header. fields of the outer header.
The difference between the two schemes in terms of covered fields is The difference between the two schemes in terms of covered fields is
therefore whether the IP header and IP options or extension headers therefore whether the IP header and IP options or extension headers
of the original IP packet are protected (as is the case with AH) or of the original IP packet are protected (as is the case with AH) or
not (as is the case with the INTEGRITY object). Also, IPsec AH not (as is the case with the INTEGRITY object). Also, AH covers the
covers the immutable fields of the outer header. immutable fields of the outer header.
As described in the next section, IPsec tunnel mode can not be As described in the next section, IPsec tunnel mode can not be
applied for RSVP traffic in the presence of non-RSVP nodes; therefore applied for RSVP traffic in the presence of non-RSVP nodes; therefore
the security associations in both cases, AH and INTEGRITY object, are the security associations in both cases, AH and INTEGRITY object, are
between the same RSVP neighbors. From a keying point of view both between the same RSVP neighbors. From a keying point of view both
approaches are therefore comparable. This document focuses on keying approaches are therefore comparable.
approaches only; a general security comparison of these approaches is
outside the scope of this document.
6.4. Applicability of Tunnel Mode 6.3. Applicability of Tunnel Mode
IPsec tunnel mode encapsulates the original packet, prepending a new IPsec tunnel mode encapsulates the original packet, prepending a new
IP tunnel header plus an ESP or AH sub-header. The entire original IP header plus an ESP or AH sub-header. The entire original packet
packet plus the ESP/AH subheader is secured. In the case of ESP the plus the ESP/AH sub-header is secured. In the case of ESP the new,
new, outer IP header however is not cryptographically secured in this outer IP header however is not cryptographically secured in this
process. This leads to the problem described in Section 6.2. AH process. This has consequences when group keying is used; see the
tunnel mode also secures the outer header, and is therefore not Security Considerations section for details.
subject to these man-in-the-middle attacks.
Protecting RSVP packets with IPsec tunnel mode works with any of the Protecting RSVP packets with IPsec tunnel mode works with any of the
above described keying methods (interface, neighbor or group based), above described keying methods (interface, neighbor or group based),
as long as there are no non-RSVP nodes on the path. Note that for 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 tunnel RSVP messages to be visible and considered at each hop, such a tunnel
would not cross routers, but each RSVP node would establish a tunnel would not cross routers, but each RSVP node would establish a tunnel
with each of its peers, effectively leading to link protection. with each of its peers, effectively leading to link protection.
In the presence of a non-RSVP hop, tunnel mode can not be applied, In the presence of a non-RSVP hop, tunnel mode cannot be applied,
because a router upstream a non-RSVP hop does not know the next RSVP because a router upstream from a non-RSVP hop does not know the next
hop, and can thus not apply the correct tunnel header. This is RSVP hop, and can thus not apply the correct tunnel header. This is
independent of the key type used. independent of the key type used.
6.5. Applicability of Transport Mode 6.4. Non-Applicability of Transport Mode
IPsec transport mode, as defined in [RFC4303] is not suitable for IPsec transport mode, as defined in [RFC4303] is not suitable for
securing RSVP Path messages, since those messages preserve the securing RSVP Path messages, since those messages preserve the
original source and destination. [RFC4303] states explicitly that original source and destination. [RFC4303] states explicitly that
"the use of transport mode by an intermediate system (e.g., a "the use of transport mode by an intermediate system (e.g., a
security gateway) is permitted only when applied to packets whose security gateway) is permitted only when applied to packets whose
source address (for outbound packets) or destination address (for source address (for outbound packets) or destination address (for
inbound packets) is an address belonging to the intermediate system inbound packets) is an address belonging to the intermediate system
itself." This would not be the case for RSVP Path messages. itself." This would not be the case for RSVP Path messages.
6.6. Applicability of Tunnel Mode with Address Preservation 6.5. Applicability of Tunnel Mode with Address Preservation
The document "Multicast Extensions to the Security Architecture for When the identity of the next-hop RSVP peer is not known, it is not
the Internet Protocol" [RFC5374] defines in section 3.1 a new tunnel possible to use tunnel-endpoint destination address in the Tunnel
mode: Tunnel mode with address preservation. This mode copies the Mode outer IP header. The document "Multicast Extensions to the
destination and optionally the source address from the inner header Security Architecture for the Internet Protocol" [RFC5374] defines in
to the outer header. Therefore the encapsulated packet will have the section 3.1 a new tunnel mode: Tunnel mode with address preservation.
same destination address as the original packet, and be normally This mode copies the destination and optionally the source address
subject to the same routing decisions. While [RFC5374] is focusing from the inner header to the outer header. Therefore the
on multicast environments, tunnel mode with address preservation can encapsulated packet will have the same destination address as the
be used also to protect unicast traffic in conjunction with group original packet, and be normally subject to the same routing
keying. decisions. While [RFC5374] is focusing on multicast environments,
tunnel mode with address preservation can be used also to protect
unicast traffic in conjunction with group keying. Note that in this
tunnel mode the RSVP speakers act as security gateways, because they
maintain the original end system addresses of the RSVP packets in the
outer tunnel mode IP header. This addressing scheme is used by RSVP
to ensure that the packets continue along the routed path toward the
destination end host.
Tunnel mode with address preservation, in conjunction with group Tunnel mode with address preservation, in conjunction with group
keying, allows the use of IPsec AH or ESP for protection of RSVP even keying, allows the use of AH or ESP for protection of RSVP even in
in cases where non-RSVP nodes have to be traversed. This is because cases where non-RSVP nodes have to be traversed. This is because it
it allows routing of the IPsec protected packet through the non-RSVP allows routing of the IPsec protected packet through the non-RSVP
nodes in the same way as if it was not IPsec protected. nodes in the same way as if it was not IPsec protected.
7. End Host Considerations 7. End Host Considerations
Unless RSVP Proxy entities ([I-D.ietf-tsvwg-rsvp-proxy-approaches] Unless RSVP Proxy entities ([I-D.ietf-tsvwg-rsvp-proxy-approaches]
are used, RSVP signaling is controlled by end systems and not are used, RSVP signaling is controlled by end systems and not
routers. As discussed in [RFC4230], RSVP allows both user-based routers. As discussed in [RFC4230], RSVP allows both user-based
security and host-based security. User-based authentication aims at security and host-based security. User-based authentication aims at
"providing policy based admission control mechanism based on user "providing policy based admission control mechanism based on user
identities or application." To identify the user or the application, identities or application." To identify the user or the application,
a policy element called AUTH_DATA, which is contained in the a policy element called AUTH_DATA, which is contained in the
POLICY_DATA object, is created by the RSVP daemon at the user's host POLICY_DATA object, is created by the RSVP daemon at the user's host
and transmitted inside the RSVP message. This way, a user may and transmitted inside the RSVP message. This way, a user may
authenticate to the Policy Decision Point (or directly to the first authenticate to the Policy Decision Point (or directly to the first
hop router). Host-based security relies on the same mechanisms as hop router). Host-based security relies on the same mechanisms as
between routers (i.e. INTEGRITY object) as specified in [RFC2747]. between routers (i.e., the INTEGRITY object) as specified in
For host-based security, interface or neighbor based keys may be [RFC2747]. For host-based security, per interface or per neighbor
used, however, key management with pre-shared keys can be difficult keys may be used, however, key management with statically provisioned
in a large scale deployment, as described in section 4. In principle keys can be difficult in a large scale deployment, as described in
an end host can also be part of a group key scheme, such as GDOI. If section 4. In principle an end host can also be part of a group key
the end systems are part of the same zone of trust as the network scheme, such as GDOI. If the end systems are part of the same
itself, group keying can be extended to include the end systems. If security domain as the network itself, group keying can be extended
the end systems and the network are in different zones of trust, to include the end systems. If the end systems and the network are
group keying cannot be used. in different zones of trust, group keying cannot be used.
8. Applicability to Other Architectures and Protocols 8. Applicability to Other Architectures and Protocols
While, so far, this document only discusses RSVP security assuming While, so far, this document discusses only RSVP security assuming
the traditional RSVP model as defined by [RFC2205] and [RFC2747], the the traditional RSVP model as defined by [RFC2205] and [RFC2747], the
analysis is also applicable to other RSVP deployment models as well analysis is also applicable to other RSVP deployment models as well
as to similar protocols: as to similar protocols:
o Aggregation of RSVP for IPv4 and IPv6 Reservations [RFC3175]: This o Aggregation of RSVP for IPv4 and IPv6 Reservations [RFC3175]: This
scheme defines aggregation of individual RSVP reservations, and scheme defines aggregation of individual RSVP reservations, and
discusses use of RSVP authentication for the signaling messages. discusses use of RSVP authentication for the signaling messages.
Group keying is applicable to this scheme, particularly when Group keying is applicable to this scheme, particularly when
automatic Deaggregator discovery is used, since in that case, the automatic Deaggregator discovery is used, since in that case, the
Aggregator does not know ahead of time which Deaggregator will Aggregator does not know ahead of time which Deaggregator will
skipping to change at page 14, line 19 skipping to change at page 14, line 38
lot of similarities in scenarios involving RSVP Aggregation over lot of similarities in scenarios involving RSVP Aggregation over
aggregate RSVP reservations ([RFC3175], [RFC4860]), RSVP aggregate RSVP reservations ([RFC3175], [RFC4860]), RSVP
Aggregation over MPLS-TE tunnels ([RFC4804]), and RSVP Aggregation over MPLS-TE tunnels ([RFC4804]), and RSVP
(Aggregation) over PCN ingress-egress aggregates. (Aggregation) over PCN ingress-egress aggregates.
9. Summary 9. Summary
The following table summarizes the various approaches for RSVP The following table summarizes the various approaches for RSVP
keying, and their applicability to various RSVP scenarios. In keying, and their applicability to various RSVP scenarios. In
particular, such keying can be used for RSVP authentication (e.g., particular, such keying can be used for RSVP authentication (e.g.,
using the RSVP INTEGRITY object or IPsec AH) and/ or for RSVP using the RSVP INTEGRITY object or AH) and/ or for RSVP encryption
encryption (e.g., using IPsec ESP in tunnel mode). (e.g., using ESP in tunnel mode).
+-----------------------------+--------------------+----------------+ +-------------------------------+-----------------+-----------------+
| | Neighbor/interface | Group keys | | | per | Group keys |
| | based keys | | | | neighbor/per | |
+-----------------------------+--------------------+----------------+ | | interface keys | |
| Works intra-domain | Yes | Yes | +-------------------------------+-----------------+-----------------+
| Works inter-domain | Yes | No | | Works intra-domain | Yes | Yes |
| Works over non-RSVP hops | No | Yes (1) | | Works inter-domain | Yes | No |
| Dynamic keying | Yes (IKE) | Yes (eg GDOI) | | Works over non-RSVP hops | No | Yes (1) |
+-----------------------------+--------------------+----------------+ | Dynamic keying | Yes (IKE) | Yes (e.g., |
| | | GDOI) |
+-------------------------------+-----------------+-----------------+
Table 1: Overview of keying approaches and their applicability Table 1: Overview of keying approaches and their applicability
(1): RSVP integrity with group keys works over non-RSVP nodes; RSVP (1): RSVP integrity with group keys works over non-RSVP nodes; RSVP
encryption with ESP and RSVP authentication with AH work over non- encryption with ESP and RSVP authentication with AH work over non-
RSVP nodes in 'Tunnel Mode with Address Preservation'; RSVP RSVP nodes in 'Tunnel Mode with Address Preservation'; RSVP
encryption with ESP & RSVP authentication with AH do not work over encryption with ESP & RSVP authentication with AH do not work over
non-RSVP nodes in 'Tunnel Mode'. non-RSVP nodes in 'Tunnel Mode'.
We also make the following observations: We also make the following observations:
o All key types can be used statically, or with dynamic key o All key types can be used statically, or with dynamic key
negotiation. This impacts the managability of the solution, but negotiation. This impacts the manageability of the solution, but
not the applicability itself. not the applicability itself.
o For encryption of RSVP messages IPsec ESP in tunnel mode can be o For encryption of RSVP messages, IPsec ESP in tunnel mode can be
used. There is however a security concern, see Section 6.2. used.
o There are some special cases in RSVP, like non-RSVP hosts, the o There are some special cases in RSVP, like non-RSVP hosts, the
"Notify" message (as discussed in section 5.1), the various RSVP "Notify" message (as discussed in Section 5.1), the various RSVP
deployment models discussed in Section 8 and MPLS Traffic deployment models discussed in Section 8 and MPLS Traffic
Engineering and GMPLS discussed in section 5.2 , which would Engineering and GMPLS discussed in section 5.2 , which would
benefit from a group keying approach. benefit from a group keying approach.
10. Security Considerations 10. Security Considerations
This entire document discusses RSVP security; this section describes This entire document discusses RSVP security; this section describes
a specific security considerations relating to subverted RSVP nodes a specific security considerations relating to subverted RSVP nodes.
10.1. Subverted RSVP Nodes 10.1. Subverted Nodes
A subverted node is defined here as an untrusted node, for example A subverted node is defined here as an untrusted node, for example
because an intruder has gained control over it. Since RSVP because an intruder has gained control over it. Since RSVP
authentication is hop-by-hop and not end-to-end, a subverted node in authentication is hop-by-hop and not end-to-end, a subverted node in
the path breaks the chain of trust. This is to a large extent the path breaks the chain of trust. This is to a large extent
independent of the type of keying used. independent of the type of keying used.
For interface or per-neighbor keying, the subverted node can now For interface or per neighbor keying, the subverted node can now
introduce fake messages to its neighbors. This can be used in a introduce fake messages to its neighbors. This can be used in a
variety of ways, for example by changing the receiver address in the variety of ways, for example by changing the receiver address in the
Path message, or by generating fake Path messages. This allows path Path message, or by generating fake Path messages. This allows path
states to be created on every RSVP router along any arbitrary path states to be created on every RSVP router along any arbitrary path
through the RSVP domain. That in itself could result in a form of through the RSVP domain. That in itself could result in a form of
Denial of Service by allowing exhaustion of some router resources Denial of Service by allowing exhaustion of some router resources
(e.g. memory). The subverted node could also generate fake Resv (e.g. memory). The subverted node could also generate fake Resv
messages upstream corresponding to valid Path states. In doing so, messages upstream corresponding to valid Path states. In doing so,
the subverted node can reserve excessive amounts of bandwidth thereby the subverted node can reserve excessive amounts of bandwidth thereby
possibly performing a denial of service attack. possibly performing a denial of service attack.
Group keying allows the additional abuse of sending fake RSVP Group keying allows the additional abuse of sending fake RSVP
messages to any node in the RSVP domain, not just adjacent RSVP messages to any node in the RSVP domain, not just adjacent RSVP
nodes. However, in practice this can be achieved to a large extent nodes. However, in practice this can be achieved to a large extent
also with per neighbor or interface keys, as discussed above. also with per neighbor or interface keys, as discussed above.
Therefore the impact of subverted nodes on the path is comparable for Therefore the impact of subverted nodes on the path is comparable for
all keying schemes discussed here (per-interface, per-neighbor, group all keying schemes discussed here (per interface, per neighbor, group
keys). keys).
11. Acknowledgements 11. Acknowledgements
The authors would like to thank everybody who provided feedback on The authors would like to thank everybody who provided feedback on
this document. Specific thanks to Bob Briscoe, Hannes Tschofenig, this document. Specific thanks to Bob Briscoe, Hannes Tschofenig,
Brian Weis, Ran Atkinson and Kenneth G. Carlberg. Brian Weis, Ran Atkinson, Stephen Kent, and Kenneth G. Carlberg.
12. Changes to Previous Version 12. Changes to Previous Version
This section provides a change log. It will be removed in the final This section provides a change log. It will be removed in the final
document: document:
12.1. changes from behringer-00 to behringer-01 12.1. changes from behringer-00 to behringer-01
o New section "Applicability to Other Architectures and Protocols": o New section "Applicability to Other Architectures and Protocols":
Goal is to clarify the scope of this document: The idea presented Goal is to clarify the scope of this document: The idea presented
skipping to change at page 17, line 18 skipping to change at page 18, line 4
12.6. changes from ietf-03 to ietf-04 12.6. changes from ietf-03 to ietf-04
o Added below table 1 in note (1) that "RSVP encryption with ESP and o Added below table 1 in note (1) that "RSVP encryption with ESP and
RSVP authentication with AH work over non-RSVP nodes in 'Tunnel RSVP authentication with AH work over non-RSVP nodes in 'Tunnel
Mode with Address Preservation'" Mode with Address Preservation'"
12.7. changes from ietf-04 to ietf-05 12.7. changes from ietf-04 to ietf-05
o Clarified in section 6.3 that IPsec AH also secures the immutable o Clarified in section 6.3 that IPsec AH also secures the immutable
fields of the outer header (comment from Bob Briscoe) fields of the outer header (comment from Bob Briscoe)
o Simplified in section 2 the comment that trust in group keying o Simplified in section 2 the comment that trust in group keying
extends to all members of the group (deleted the words on extends to all members of the group (deleted the words on
"explicit and implicit"). (comment from Brian Weis) "explicit and implicit"). (comment from Brian Weis)
o A number of corrections, re-wordings and clarifications in o A number of corrections, re-wordings and clarifications in
response to Kenneth Carlberg's email from 2 June 2009 response to Kenneth Carlberg's email from 2 June 2009
12.8. changes from ietf-05 to ietf-06
This version addresses extensive comments from Stephen Kent in the
SecDir review (see email from Gorry on 15 Jan 2010). Specifically:
o Many editorial changes, and small corrections.
o Deleted reference to RFC3562, since it is not applicable in this
context.
o Clarification in section 2 that the handshake specified in RFC2747
allows to determine the identity of the next RSVP hop in the
presence of non-RSVP hops.
o Cleared up inconsistent wording on "trust group" and "security
domain", and defined the latter. (Section 3)
o Added a paragraph on the applicability of sequence numbers in
section 3.1 and 3.2.
o Defined static key provisioning. (Section 4.1)
o Clarified wording in 6.1 on the use of GDOI.
o Added in section 6.6 some clarification to the use of tunnel mode
with address preservation.
13. Informative References 13. Informative References
[I-D.ietf-pcn-architecture] [I-D.ietf-pcn-architecture]
Eardley, P., "Pre-Congestion Notification (PCN) Eardley, P., "Pre-Congestion Notification (PCN)
Architecture", draft-ietf-pcn-architecture-11 (work in Architecture", draft-ietf-pcn-architecture-11 (work in
progress), April 2009. progress), April 2009.
[I-D.ietf-tsvwg-rsvp-proxy-approaches] [I-D.ietf-tsvwg-rsvp-proxy-approaches]
Faucheur, F., Manner, J., Wing, D., and L. Faucheur, "RSVP Faucheur, F., Manner, J., Wing, D., and L. Faucheur, "RSVP
Proxy Approaches", Proxy Approaches",
draft-ietf-tsvwg-rsvp-proxy-approaches-07 (work in draft-ietf-tsvwg-rsvp-proxy-approaches-09 (work in
progress), May 2009. progress), March 2010.
[I-D.weis-gdoi-mac-tek] [I-D.weis-gdoi-mac-tek]
Weis, B. and S. Rowles, "GDOI Generic Message Weis, B. and S. Rowles, "GDOI Generic Message
Authentication Code Policy", draft-weis-gdoi-mac-tek-00 Authentication Code Policy", draft-weis-gdoi-mac-tek-00
(work in progress), July 2008. (work in progress), July 2008.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997. Functional Specification", RFC 2205, September 1997.
skipping to change at page 18, line 20 skipping to change at page 19, line 26
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic (GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The
Group Domain of Interpretation", RFC 3547, July 2003. Group Domain of Interpretation", RFC 3547, July 2003.
[RFC3562] Leech, M., "Key Management Considerations for the TCP MD5
Signature Option", RFC 3562, July 2003.
[RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security
Architecture", RFC 3740, March 2004. Architecture", RFC 3740, March 2004.
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
Extensions to RSVP-TE for LSP Tunnels", RFC 4090, Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
May 2005. May 2005.
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
Hierarchy with Generalized Multi-Protocol Label Switching Hierarchy with Generalized Multi-Protocol Label Switching
(GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
[RFC4216] Zhang, R. and J. Vasseur, "MPLS Inter-Autonomous System [RFC4216] Zhang, R. and J. Vasseur, "MPLS Inter-Autonomous System
(AS) Traffic Engineering (TE) Requirements", RFC 4216, (AS) Traffic Engineering (TE) Requirements", RFC 4216,
November 2005. November 2005.
[RFC4230] Tschofenig, H. and R. Graveman, "RSVP Security [RFC4230] Tschofenig, H. and R. Graveman, "RSVP Security
Properties", RFC 4230, December 2005. Properties", RFC 4230, December 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, [RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
December 2005. December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005. RFC 4303, December 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005. RFC 4306, December 2005.
[RFC4804] Le Faucheur, F., "Aggregation of Resource ReSerVation [RFC4804] Le Faucheur, F., "Aggregation of Resource ReSerVation
skipping to change at page 19, line 21 skipping to change at page 20, line 28
Engineering (RSVP-TE) for Point-to-Multipoint TE Label Engineering (RSVP-TE) for Point-to-Multipoint TE Label
Switched Paths (LSPs)", RFC 4875, May 2007. Switched Paths (LSPs)", RFC 4875, May 2007.
[RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast [RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast
Extensions to the Security Architecture for the Internet Extensions to the Security Architecture for the Internet
Protocol", RFC 5374, November 2008. Protocol", RFC 5374, November 2008.
Authors' Addresses Authors' Addresses
Michael H. Behringer Michael H. Behringer
Cisco Systems Inc Cisco Systems
Village d'Entreprises Green Side Village d'Entreprises Green Side
400, Avenue Roumanille, Batiment T 3 400, Avenue Roumanille, Batiment T 3
Biot - Sophia Antipolis 06410 Biot - Sophia Antipolis 06410
France France
Email: mbehring@cisco.com Email: mbehring@cisco.com
URI: http://www.cisco.com URI: http://www.cisco.com
Francois Le Faucheur Francois Le Faucheur
Cisco Systems Inc Cisco Systems
Village d'Entreprises Green Side Village d'Entreprises Green Side
400, Avenue Roumanille, Batiment T 3 400, Avenue Roumanille, Batiment T 3
Biot - Sophia Antipolis 06410 Biot - Sophia Antipolis 06410
France France
Email: flefauch@cisco.com Email: flefauch@cisco.com
URI: http://www.cisco.com URI: http://www.cisco.com
Brian Weis
Cisco Systems
170 W. Tasman Drive
San Jose, California 95134-1706
USA
Email: bew@cisco.com
URI: http://www.cisco.com
 End of changes. 89 change blocks. 
276 lines changed or deleted 300 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/