draft-ietf-tsvwg-rsvp-security-groupkeying-10.txt   draft-ietf-tsvwg-rsvp-security-groupkeying-11.txt 
Network Working Group M. Behringer Network Working Group M. Behringer
Internet-Draft F. Le Faucheur Internet-Draft F. Le Faucheur
Intended status: Informational B. Weis Intended status: Informational B. Weis
Expires: December 25, 2011 Cisco Systems Expires: March 12, 2012 Cisco Systems
June 23, 2011 September 9, 2011
Applicability of Keying Methods for RSVP Security Applicability of Keying Methods for RSVP Security
draft-ietf-tsvwg-rsvp-security-groupkeying-10.txt draft-ietf-tsvwg-rsvp-security-groupkeying-11.txt
Abstract Abstract
The Resource reSerVation Protocol (RSVP) allows hop-by-hop integrity The Resource reSerVation Protocol (RSVP) allows hop-by-hop integrity
protection of RSVP neighbors. This requires messages to be protection of RSVP neighbors. This requires messages to be
cryptographically protected using a shared secret between cryptographically protected using a shared secret between
participating nodes. This document compares group keying for RSVP participating nodes. This document compares group keying for RSVP
with per neighbor or per interface keying, and discusses the with per neighbor or per interface keying, and discusses the
associated key provisioning methods as well as applicability and associated key provisioning methods as well as applicability and
limitations of these approaches. The document also discusses limitations of these approaches. The document also discusses
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. 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."
This Internet-Draft will expire on December 25, 2011. This Internet-Draft will expire on March 12, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction and Problem Statement . . . . . . . . . . . . . . 3 1. Introduction and Problem Statement . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. The RSVP Hop-by-Hop Trust Model . . . . . . . . . . . . . . . 3 2. The RSVP Hop-by-Hop Trust Model . . . . . . . . . . . . . . . 4
3. Applicability of Key Types for RSVP . . . . . . . . . . . . . 5 3. Applicability of Key Types for RSVP . . . . . . . . . . . . . 5
3.1. Per interface and per neighbor 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. Per Neighbor and Per Interface 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 Supporting Use of Group Keying . . . . . . . . 9 5. Specific Cases Supporting Use of Group Keying . . . . . . . . 9
5.1. RSVP Notify Messages . . . . . . . . . . . . . . . . . . . 9 5.1. RSVP Notify Messages . . . . . . . . . . . . . . . . . . . 9
5.2. RSVP-TE and GMPLS . . . . . . . . . . . . . . . . . . . . 9 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. Comparing AH and the INTEGRITY Object . . . . . . . . . . 11 6.2. Comparing AH and the INTEGRITY Object . . . . . . . . . . 11
6.3. Applicability of Tunnel Mode . . . . . . . . . . . . . . . 11 6.3. Applicability of Tunnel Mode . . . . . . . . . . . . . . . 12
6.4. Non-Applicability of Transport Mode . . . . . . . . . . . 12 6.4. Non-Applicability of Transport Mode . . . . . . . . . . . 12
6.5. Applicability of Tunnel Mode with Address Preservation . . 12 6.5. Applicability of Tunnel Mode with Address Preservation . . 13
7. End Host Considerations . . . . . . . . . . . . . . . . . . . 13 7. End Host Considerations . . . . . . . . . . . . . . . . . . . 13
8. Applicability to Other Architectures and Protocols . . . . . . 13 8. Applicability to Other Architectures and Protocols . . . . . . 14
9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16
10.1. Subverted Nodes . . . . . . . . . . . . . . . . . . . . . 15 10.1. Subverted Nodes . . . . . . . . . . . . . . . . . . . . . 16
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
13. Informative References . . . . . . . . . . . . . . . . . . . . 16 13. Informative References . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
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 identity 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
skipping to change at page 3, line 24 skipping to change at page 3, line 24
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 a key per router pair across an entire network is configure a key per router pair across an entire network is
operationally hard, especially when key changes are to be performed operationally hard, especially when key changes are to be performed
on a regular basis. Effectively, many users of RSVP therefore resort on a regular basis. Effectively, many users of RSVP therefore resort
to using the same key throughout their RSVP network, and they change to using the same key throughout their RSVP network, and they change
it rarely if ever, because of the operational burden. It is however it rarely if ever, because of the operational burden. It is however
often necessary to regularly change keys due to network operational often necessary to change keys due to network operational
requirements. requirements (e.g., change of operational staff).
This document discusses a variety of 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 is meant as a comparative guide message integrity and encryption. It is meant as a comparative guide
to understand where each RSVP keying method is best deployed, and the to understand where each RSVP keying method is best deployed, and the
limitations of each method. Furthermore, it discusses how RSVP hop limitations of each method. Furthermore, it discusses how RSVP hop
by hop authentication is impacted in the presence of non-RSVP nodes, by hop authentication is impacted in the presence of non-RSVP nodes,
or subverted nodes, in the reservation path. 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].
1.1. Terminology 1.1. Terminology
A security domain is defined in this document as a set of nodes that A security domain is defined in this document as two or more nodes
shares a common RSVP security policy. that share a common RSVP security policy.
When a key is mentioned in this document, it is a symmetric key. A
symmetric key best meets the operational requirements of RSVP
deployments, and is the only type of key currently explicitly
supported for protecting RSVP messages.
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 messages from its per peer authentication. Each hop authenticates messages from its
neighbor with a shared key or certificate. This is also the model neighbor with a shared key or certificate. This is also the model
used for RSVP. Trust in this model is transitive. Each RSVP node used for RSVP. Trust in this model is transitive. Each RSVP node
trusts explicitly only its RSVP next hop peers, through the message trusts explicitly only its RSVP next hop peers, through the message
digest contained in the INTEGRITY object. The next hop RSVP speaker 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 in turn trusts its own peers and so on. See also the document "RSVP
security properties" [RFC4230] for more background. security properties" [RFC4230] for more background.
The keys used for protecting 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 the Group Domain of
in [I-D.weis-gdoi-mac-tek]). If a group key is used, the Interpretations (GDOI) [I-D.ietf-msec-gdoi-update], as discussed in
authentication granularity becomes group membership of devices, not [I-D.weis-gdoi-mac-tek]). If a group key is used, the authentication
(individual) peer authentication between devices. granularity becomes group membership of devices, not (individual)
peer authentication between devices.
The trust an RSVP node has to another RSVP node has an explicit and The trust an RSVP node has to another RSVP node within a common
an implicit component. Explicitly the node trusts the other node to security domain has an explicit and an implicit component.
maintain the RSVP messages intact or confidential, depending on Explicitly the node trusts the other node to maintain the RSVP
whether authentication or encryption (or both) is used. This means messages intact or confidential, depending on whether authentication
only that the message has not been altered or seen by another, non- or encryption (or both) is used. This means only that the message
trusted node. Implicitly each node trusts each other node with which has not been altered or seen by another, non-trusted node.
it has a trust relationship established via the mechanisms here to Implicitly each node trusts the other node to maintain the level of
adhere to the protocol specifications laid out by the various protection specified within that security domain. In any group
standards. In any group keying scheme like GDOI a node trusts all keying scheme like GDOI a node trusts all the other members of the
the other members of the group (because the authentication is now group (because the authentication is now based on group membership,
based on group membership, as noted above). 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. In the presence of non-RSVP hops, while they are not IP neighbors. In the presence of non-RSVP hops, while
an RSVP node always knows the next IP hop before forwarding an RSVP an RSVP node always knows the next IP hop before forwarding an RSVP
Message, it does not always know the RSVP next hop. In fact, part of Message, it does not always know the RSVP next hop. In fact, part of
skipping to change at page 5, line 47 skipping to change at page 5, line 47
successfully using the group key. successfully using the group key.
3. Applicability of Key Types for RSVP 3. Applicability of Key Types for RSVP
3.1. Per interface and per neighbor keys 3.1. Per interface and per neighbor keys
Most current RSVP authentication implementations support per Most current RSVP authentication implementations support per
interface RSVP keys. When the interface is point-to-point (and interface RSVP keys. When the interface is point-to-point (and
therefore an RSVP router has only a single RSVP neighbor on each therefore an RSVP router has only a single RSVP neighbor on each
interface), this is equivalent to per neighbor keys in the sense that interface), this is equivalent to per neighbor keys in the sense that
a different key is used for each neighbor. However, when the a different key is used for each neighbor. In the point-to-point
interface is multipoint, all RSVP speakers on a given subnet have to case, the security domain is simply between the router and its
belong to the same security domain and share the same key in this neighbor. However, when the interface is multipoint, all RSVP
model. This makes it unsuitable for deployment scenarios where nodes speakers on a given subnet have to belong to the same security domain
from different security domains are present on a subnet, for example and share the same key in this model. This makes it unsuitable for
Internet exchange points. In such cases, per neighbor keys are deployment scenarios where nodes from different security domains are
required. present on a subnet, for example Internet exchange points. In such
cases, per neighbor keys are required and the security domain is
between the router and its neighbor.
With per neighbor keys, each 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 for the existence of different neighbor on that interface. It allows for the existence of different
security domains on a single interface and subnet. security domains on a single interface and subnet.
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. 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. are specific to a particular interface or neighbor.
skipping to change at page 6, line 37 skipping to change at page 6, line 39
In the case of group keys, all members of a group of RSVP nodes share In the case of group keys, all members of a group of RSVP nodes share
the same key. This implies that a node uses the same key regardless 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 the next RSVP hop that will process the message (within the group
of nodes sharing the particular key). It also implies that a node 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 will use the same key on the receiving as on the sending side (when
exchanging RSVP messages within the group). exchanging RSVP messages within the group).
Group keys apply naturally to intra-domain RSVP authentication, where Group keys apply naturally to intra-domain RSVP authentication, where
all RSVP nodes are part of the same security domain and implicitly all RSVP nodes are part of the same security domain and implicitly
trust each other. Using group keys, they extend this trust to the trust each other. The nodes also extended trust to a group key
group key server. This is represented in Figure 2. server (GKS), which administers group membership and provides group
keys. 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 21 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 keys between the two domains. to use per interface or per neighbor keys between the two domains
Figure 4 shows this setup. (thus comprising a third security domain). 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----->|
|<-->|
domain 3
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 Because a group key may be used to verify messages from different
peers, monotonically increasing sequence number methods are not peers, monotonically increasing sequence number methods are not
appropriate. Time based anti-replay methods (e.g., the INTEGITY appropriate. Time based anti-replay methods (e.g., the INTEGRITY
sequence numbers based on a clock [RFC2747]) can be used with group sequence numbers based on a clock [RFC2747]) can be used with group
keys. keys.
4. Key Provisioning Methods for RSVP 4. Key Provisioning Methods for RSVP
4.1. Static Key Provisioning 4.1. Static Key Provisioning
Static keys are preconfigured, either manually, or through a network Static keys are preconfigured, either manually, or through a network
management system. The simplest way to implement RSVP authentication management system. The simplest way to implement RSVP authentication
is to use static keys. Static keying can be used with per interface is to use static keys. Static keying can be used with per interface
skipping to change at page 8, line 43 skipping to change at page 9, line 10
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 per interface or per neighbor keys. to derive either per interface or per neighbor keys.
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 [I-D.ietf-msec-gdoi-update]. In this solution, each RSVP
each of the RSVP nodes independently, and then distributes a group node requests a group key from a key server as part of an encrypted
key to the group as part of an encrypted and integrity protected key and integrity protected key agreement protocol. Once the key server
agreement protocol. The authentication in this model can be based on has authenticated and authorized the RSVP nodes it distributes a
public key mechanisms, thereby avoiding the need for static key group key to the group member. The authentication in this model can
provisioning. be based on public key mechanisms, thereby avoiding the need for
static key provisioning.
5. Specific Cases Supporting Use of Group Keying 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 messages to [RFC3473] introduces the Notify message and allows such messages to
be sent in a non-hop-by-hop fashion. As discussed in the Security be sent in a non-hop-by-hop fashion. As discussed in the Security
Considerations section of [RFC3473], this can interfere with RSVP's Considerations section of [RFC3473], this can interfere with RSVP's
hop-by-hop integrity and authentication model. [RFC3473] describes hop-by-hop integrity and authentication model. [RFC3473] describes
how standard IPsec based integrity and authentication can be used to how standard IPsec based integrity and authentication can be used to
skipping to change at page 10, line 34 skipping to change at page 10, line 47
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 [RFC4301] to protect RSVP. also applicable when using IPsec [RFC4301] to protect RSVP.
[RFC2747] states in section 1.2 that IPsec is not an optimal choice [RFC2747] states in section 1.2 that IPsec is not an optimal choice
to protect RSVP. The key argument is that an IPsec SA and an RSVP SA to protect RSVP. The key argument is that an IPsec SA and an RSVP SA
are not based on the same parameters. Nevertheless, IPsec can be are not based on the same parameters. Nevertheless, IPsec can be
used to protect RSVP. The SPD traffic selectors for related RSVP used to protect RSVP. The Security Policy Database (SPD) traffic
flows will not be constant. In some cases, the source and selectors for related RSVP flows will not be constant. In some
destination addresses are end hosts, and sometimes they are RSVP cases, the source and destination addresses are end hosts, and
routers. Therefore, traffic selectors in the SPD are expected to sometimes they are RSVP routers. Therefore, traffic selectors in the
specify ANY for the source address and destination addresses, and SPD are expected to specify ANY for the source address and
specify IP protocol 46 (RSVP). destination addresses, and specify IP protocol 46 (RSVP).
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] manages group security associations, which can be used by [I-D.ietf-msec-gdoi-update] manages group security associations,
IPsec. An example GDOI policy would be to encrypt or authenticate which can be used by IPsec. An example GDOI policy would be to
all packets of the RSVP protocol itself (IP protocol 46). A router encrypt or authenticate all packets of the RSVP protocol itself (IP
implementing GDOI and the AH and/or ESP protocols is therefore able protocol 46). A router implementing GDOI and the AH and/or ESP
to implement this policy. protocols is therefore able to implement this policy.
Because the traffic selectors for an SA cannot be predicted, SA Because the traffic selectors for an SA cannot be predicted, SA
lookup is expected to use only the SPI (or SPI plus protocol). lookup is expected to use only the Security Parameters Index (SPI)
(or SPI plus protocol).
6.2. Comparing AH and the INTEGRITY Object 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. AH [RFC4302] is an alternative method to provide integrity above. AH [RFC4302] is an alternative method to provide 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)
skipping to change at page 12, line 5 skipping to change at page 12, line 23
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 (however, see as long as there are no non-RSVP nodes on the path (however, see
group keying considerations below). For RSVP messages to be visible group keying considerations below). For RSVP messages to be visible
and considered at each hop, such a tunnel would not cross routers, and considered at each hop, such a tunnel would not cross routers,
but each RSVP node would establish a tunnel with each of its peers, but each RSVP node would establish a tunnel with each of its peers,
effectively leading to link protection. effectively leading to link protection.
In the presence of a non-RSVP hop, tunnel mode cannot be applied, In the presence of a non-RSVP hop, tunnel mode cannot be applied,
because a router upstream from a non-RSVP hop does not know the next because a router upstream from a non-RSVP hop does not know the next
RSVP hop, and can thus not apply the correct tunnel header. This is RSVP hop, and can thus not apply the correct tunnel header. The same
independent of the key type used. situation applies to a host attached to the network by a non-RSVP
enabled first hop. This is independent of the key type used.
The use of group keying with ESP tunnel mode where a security gateway The use of group keying with ESP tunnel mode where a security gateway
places a peer security gateway address as the destination of the ESP places a peer security gateway address as the destination of the ESP
packet has consequences. In particular, if a man-in-the-middle packet has consequences. In particular, if a man-in-the-middle
attacker re-directs the ESP-protected reservation to a different attacker re-directs the ESP-protected reservation to a different
security gateway, the receiving security gateway cannot detect that security gateway, the receiving security gateway cannot detect that
the destination address was changed. However, it has received and the destination address was changed. However, it has received and
will act upon or route a RSVP reservation that will be be routed will act upon or route a RSVP reservation that will be routed along
along an unintended path. Because RSVP routers encountering the RSVP an unintended path. Because RSVP routers encountering the RSVP
packet path will not be aware that this is an unintended path, they packet path will not be aware that this is an unintended path, they
will act upon it and the resulting RSVP state along both the intended will act upon it and the resulting RSVP state along both the intended
path and unintended path will both be incorrect. Therefore group path and unintended path will both be incorrect. Therefore group
keying is recommended not be used with ESP tunnel mode except with keying is recommended not be used with ESP tunnel mode except with
address preservation (see Section 6.5). address preservation (see Section 6.5).
6.4. Non-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
skipping to change at page 13, line 39 skipping to change at page 14, line 11
AUTH_DATA, which is contained in the POLICY_DATA object, is created AUTH_DATA, which is contained in the POLICY_DATA object, is created
by the RSVP daemon at the user's host and transmitted inside the RSVP by the RSVP daemon at the user's host and transmitted inside the RSVP
message. This way, a user may authenticate to the Policy Decision message. This way, a user may authenticate to the Policy Decision
Point (or directly to the first hop router). Host-based security Point (or directly to the first hop router). Host-based security
relies on the same mechanisms as between routers (i.e., the INTEGRITY relies on the same mechanisms as between routers (i.e., the INTEGRITY
object) as specified in [RFC2747]. For host-based security, per object) as specified in [RFC2747]. For host-based security, per
interface or per neighbor keys may be used, however, key management interface or per neighbor keys may be used, however, key management
with statically provisioned keys can be difficult in a large scale with statically provisioned keys can be difficult in a large scale
deployment, as described in section 4. In principle an end host can deployment, as described in section 4. In principle an end host can
also be part of a group key scheme, such as GDOI. If the end systems also be part of a group key scheme, such as GDOI. If the end systems
are part of the same security domain as the network itself, group are part of the same security domain as the RSVP hops in the network,
keying can be extended to include the end systems. If the end group keying can be extended to include the end systems. If the end
systems and the network are in different zones of trust, group keying systems and the network are in different zones of trust, group keying
cannot be used. cannot be used.
8. Applicability to Other Architectures and Protocols 8. Applicability to Other Architectures and Protocols
While, so far, this document discusses only 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:
skipping to change at page 14, line 34 skipping to change at page 15, line 5
this architecture is based on IntServ over DiffServ: the DiffServ this architecture is based on IntServ over DiffServ: the DiffServ
region is PCN-enabled, RSVP signalling is used end-to-end but the region is PCN-enabled, RSVP signalling is used end-to-end but the
PCN-domain is a single RSVP hop, i.e. only the PCN- boundary-nodes PCN-domain is a single RSVP hop, i.e. only the PCN- boundary-nodes
process RSVP messages. In this scenario, RSVP authentication may process RSVP messages. In this scenario, RSVP authentication may
be required among PCN-boundary-nodes and the considerations about be required among PCN-boundary-nodes and the considerations about
keying approaches discussed earlier in this document apply. In keying approaches discussed earlier in this document apply. In
particular, group keying may facilitate operations since the particular, group keying may facilitate operations since the
ingress PCN-boundary-node does not necessarily know ahead of time ingress PCN-boundary-node does not necessarily know ahead of time
which Egress PCN-boundary-node will intercept and process the which Egress PCN-boundary-node will intercept and process the
initial end-to-end Path message. From the viewpoint of securing initial end-to-end Path message. From the viewpoint of securing
end-to-end RSVP, there are a lot of similarities in scenarios end-to-end RSVP in this scenario (from the end host to the ingress
involving RSVP Aggregation over aggregate RSVP reservations edge PCN node, to the egress PCN node, to the other end host),
([RFC3175], [RFC4860]), RSVP Aggregation over MPLS-TE tunnels there are a lot of similarities in scenarios involving RSVP
([RFC4804]), and RSVP (Aggregation) over PCN ingress-egress Aggregation over aggregate RSVP reservations ([RFC3175],
aggregates. [RFC4860]), RSVP Aggregation over MPLS-TE tunnels ([RFC4804]), and
RSVP (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 AH) and/ or for RSVP encryption using the RSVP INTEGRITY object or AH) and/ or for RSVP encryption
(e.g., using ESP in tunnel mode). (e.g., using ESP in tunnel mode).
+-------------------------------+-----------------+-----------------+ +-------------------------------+-----------------+-----------------+
skipping to change at page 15, line 45 skipping to change at page 16, line 13
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 Nodes 10.1. Subverted Nodes
A subverted node is defined here as an untrusted node, for example An undetected subverted node, for example one that an intruder has
because an intruder has gained control over it. Since RSVP gained control over, it is still implicitly a trusted node. However
authentication is hop-by-hop and not end-to-end, a subverted node in it is a threat to the security of RSVP. Since RSVP authentication is
the path breaks the chain of trust. This is to a large extent hop-by-hop and not end-to-end, a subverted node in the path breaks
independent of the type of keying used. the chain of trust. This is to a large extent 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,
skipping to change at page 16, line 36 skipping to change at page 17, line 8
this document. Specific thanks to Bob Briscoe, Hannes Tschofenig, this document. Specific thanks to Bob Briscoe, Hannes Tschofenig,
Ran Atkinson, Stephen Kent, and Kenneth G. Carlberg. Ran Atkinson, Stephen Kent, and Kenneth G. Carlberg.
12. IANA Considerations 12. IANA Considerations
There are no IANA considerations within this document. This section There are no IANA considerations within this document. This section
can be removed if this document is published as an RFC. can be removed if this document is published as an RFC.
13. Informative References 13. Informative References
[I-D.ietf-msec-gdoi-update]
Weis, B., Rowles, S., and T. Hardjono, "The Group Domain
of Interpretation", draft-ietf-msec-gdoi-update-11 (work
in progress), August 2011.
[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-02 Authentication Code Policy", draft-weis-gdoi-mac-tek-02
(work in progress), March 2011. (work in progress), March 2011.
[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.
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic
skipping to change at page 17, line 15 skipping to change at page 17, line 37
RFC 3175, September 2001. RFC 3175, September 2001.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
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
Group Domain of Interpretation", RFC 3547, 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.
 End of changes. 30 change blocks. 
83 lines changed or deleted 102 lines changed or added

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