draft-ietf-tsvwg-rsvp-security-groupkeying-09.txt   draft-ietf-tsvwg-rsvp-security-groupkeying-10.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: June 10, 2011 Cisco Systems Expires: December 25, 2011 Cisco Systems
December 7, 2010 June 23, 2011
Applicability of Keying Methods for RSVP Security Applicability of Keying Methods for RSVP Security
draft-ietf-tsvwg-rsvp-security-groupkeying-09.txt draft-ietf-tsvwg-rsvp-security-groupkeying-10.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 June 10, 2011. This Internet-Draft will expire on December 25, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 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
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. 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 . . . . . . . . . . . . . . 8 4. Key Provisioning Methods for RSVP . . . . . . . . . . . . . . 7
4.1. Static Key Provisioning . . . . . . . . . . . . . . . . . 8 4.1. Static Key Provisioning . . . . . . . . . . . . . . . . . 7
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 . . . . . . . . . . . . 9 4.2.2. Dynamic Group Key Distribution . . . . . . . . . . . . 8
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 . . . . . . . . . . . . . . . 12 6.3. Applicability of Tunnel Mode . . . . . . . . . . . . . . . 11
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 . . 13 6.5. Applicability of Tunnel Mode with Address Preservation . . 12
7. End Host Considerations . . . . . . . . . . . . . . . . . . . 13 7. End Host Considerations . . . . . . . . . . . . . . . . . . . 13
8. Applicability to Other Architectures and Protocols . . . . . . 14 8. Applicability to Other Architectures and Protocols . . . . . . 13
9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10.1. Subverted Nodes . . . . . . . . . . . . . . . . . . . . . 16 10.1. Subverted Nodes . . . . . . . . . . . . . . . . . . . . . 15
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
13. Informative References . . . . . . . . . . . . . . . . . . . . 17 13. Informative References . . . . . . . . . . . . . . . . . . . . 16
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 43 skipping to change at page 3, line 43
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
A security domain is defined in this document as a set of nodes that
shares a common RSVP security policy.
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 messages from its
shared key or certificate. This is also the model used for RSVP. neighbor with a shared key or certificate. This is also the model
Trust in this model is transitive. Each RSVP node trusts explicitly used for RSVP. Trust in this model is transitive. Each RSVP node
only its RSVP next hop peers, through the message digest contained in trusts explicitly only its RSVP next hop peers, through the message
the INTEGRITY object. The next hop RSVP speaker in turn trusts its digest contained in the INTEGRITY object. The next hop RSVP speaker
own peers and so on. See also the document "RSVP security in turn trusts its own peers and so on. See also the document "RSVP
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 GDOI [RFC3547], as discussed
in [I-D.weis-gdoi-mac-tek]). If a group key is used, the in [I-D.weis-gdoi-mac-tek]). If a group key is used, the
authentication granularity becomes group membership of devices, not authentication granularity becomes group membership of devices, not
(individual) peer authentication between devices. (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 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) is 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. In any group keying scheme like GDOI a node trusts all
trusts all the other members of the group (because the authentication the other members of the group (because the authentication is now
is now based on group membership, as noted above). 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. In the presence of non-RSVP hops, while
hops, while an RSVP node always knows the next IP hop before an RSVP node always knows the next IP hop before forwarding an RSVP
forwarding an RSVP Message, it does not always know the RSVP next Message, it does not always know the RSVP next hop. In fact, part of
hop. In fact, part of the role of a Path message is precisely to the role of a Path message is precisely to discover the RSVP next hop
discover the RSVP next hop (and to dynamically re-discover it when it (and to dynamically re-discover it when it changes, for example
changes, for example because of a routing change). Thus, the because of a routing change). Thus, the presence of non-RSVP hops
presence of non-RSVP hops impacts operation of RSVP authentication or impacts operation of RSVP authentication or encryption and may
encryption and may influence the selection of keying approaches. influence the selection of keying approaches.
Figure 1 illustrates this scenario. R2 in this picture does not Figure 1 illustrates this scenario. R2 in this picture does not
participate in RSVP, the other nodes do. In this case, R2 will pass participate in RSVP, the other nodes do. In this case, R2 will pass
on any RSVP messages unchanged, and will ignore them. on any RSVP messages unchanged, and will ignore them.
----R3--- ----R3---
/ \ / \
sender----R1---R2(*) R4----receiver sender----R1---R2(*) R4----receiver
\ / \ /
----R5--- ----R5---
(*) Non-RSVP hop (*) Non-RSVP hop
Figure 1: A non-RSVP Node in the path Figure 1: A non-RSVP Node in the path
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 used in the presence of non-RSVP routers on the path
between senders and receivers.
This means that per interface and per neighbor keys cannot easily be Section 4.3 of [RFC2747] states that "... the receiver MAY initiate
used in the presence of non-RSVP routers on the path between senders an integrity handshake with the sender." If this handshake is taking
and receivers. Section 4.3 of [RFC2747] states that "... the place, it can be used to determine the identity of the next RSVP hop.
receiver MAY initiate an integrity handshake with the sender." We In this case, non-RSVP hops can be traversed also using per interface
note that if this handshake is taking place, it can be used to or per neighbor keys.
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.
Group keying will naturally work in the presence of non-RSVP routers. Group keying will naturally work in the presence of non-RSVP routers.
Referring back to Figure 1, with group keying, R1 would use the group Referring back to Figure 1, with group keying, R1 would use the group
key to protect a Path message addressed to the receiver and forwards key to protect a Path message addressed to the receiver and forwards
it to R2. Being a non-RSVP node, R2 will ignore and forward the Path it to R2. Being a non-RSVP node, R2 will ignore and forward the Path
message to R3 or R5 depending on the current shortest path as message to R3 or R5 depending on the current shortest path as
determined by routing. Whether it is R3 or R5, the RSVP router that determined by routing. Whether it is R3 or R5, the RSVP router that
receives the Path message will be able to authenticate it receives the Path message will be able to authenticate the message
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. However, when the
interface is multipoint, all RSVP speakers on a given subnet have to interface is multipoint, all RSVP speakers on a given subnet have to
share the same key in this model. This makes it unsuitable for belong to the same security domain and share the same key in this
deployment scenarios where nodes from different security domains are model. This makes it unsuitable for deployment scenarios where nodes
present on a subnet, for example Internet exchange points. A from different security domains are present on a subnet, for example
security domain is defined here as a set of nodes that shares a Internet exchange points. In such cases, per neighbor keys are
common RSVP security policy. In such cases, per neighbor keys are
required. required.
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. As mentioned above, per interface keys are only security domain.
applicable when all the nodes reachable on the specific interface
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.
level keys can be deployed safely only when all the reachable
neighbors on the interface belong to the same security domain.
Both monotonically increasing sequence number (e.g., the INTEGRITY Both monotonically increasing sequence number (e.g., the INTEGRITY
object simple sequence numbers [RFC2747], or the ESP and AH anti- object simple sequence numbers [RFC2747], or the ESP and AH anti-
replay service [RFC4301] sequence numbers) and time based anti-replay replay service [RFC4301] sequence numbers) and time based anti-replay
methods (e.g., the INTEGRITY sequence numbers based on a clock methods (e.g., the INTEGRITY sequence numbers based on a clock
[RFC2747]) can be used with per neighbor and per interface keys. [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.
skipping to change at page 8, line 35 skipping to change at page 8, line 25
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, statically provisioned keys may be applicable to inter-domain Thus, statically provisioned keys may be applicable to inter-domain
RSVP authentication. RSVP authentication.
Since it is not feasible to carry out a key change at the exact same Since it is not feasible to carry out a key change at the exact same
time in communicating RSVP nodes, some grace period needs to be time in communicating RSVP nodes, some grace period needs to be
implemented during which an RSVP node will accept both the old and implemented during which an RSVP node will accept both the old and
the new key. Otherwise, RSVP operation would suffer interruptions. the new key. Otherwise, RSVP operation would suffer interruptions.
(Note that also with dynamic keying approaches there can be a grace (Also with dynamic keying approaches there can be a grace period
period where two keys are valid at the same time; however, the grace where two keys are valid at the same time; however, the grace period
period in manual keying tends to be significantly longer than with in manual keying tends to be significantly longer than with dynamic
dynamic key rollover schemes.) key rollover schemes.)
4.2. Dynamic Keying 4.2. Dynamic Keying
4.2.1. Per Neighbor and Per Interface 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 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
skipping to change at page 9, line 26 skipping to change at page 9, line 14
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
protect Notify messages. We observe that, alternatively, in some protect Notify messages.
environments, group keying may allow use of regular RSVP
authentication ([RFC2747]) for protection of non-hop-by-hop Notify
messages.
For example, RSVP Notify messages commonly used for traffic Group keying may allow use of regular RSVP authentication ([RFC2747])
engineering in MPLS networks are non-hop-by-hop messages. Such for protection of non-hop-by-hop Notify messages. For example, RSVP
messages may be sent from an ingress node directly to an egress node. Notify messages commonly used for traffic engineering in MPLS
Group keying in such a case avoids the establishment of node-to-node networks are non-hop-by-hop messages. Such messages may be sent from
keying when node-to-node keying is not otherwise used. 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.
skipping to change at page 10, line 10 skipping to change at page 9, line 45
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." Such
observe that such environments may benefit from group keying. A environments may benefit from group keying. A group key can be used
group key can be used among a set of routers enabled for Fast Reroute among a set of routers enabled for Fast Reroute thereby easily
thereby easily ensuring that PLR and MP authenticate messages from ensuring that PLR and MP authenticate messages from each other can be
each other can be authenticated, without requiring prior specific authenticated, without requiring prior specific configuration of
configuration of keys, or activation of key update mechanism, for keys, or activation of key update mechanism, for every possible pair
every possible pair of PLR and MP. 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. RSVP message integrity mechanisms for
[RFC4875] points out that RSVP message integrity mechanisms for hop- hop-by-hop RSVP signaling apply to the hop-by-hop P2MP RSVP-TE
by-hop RSVP signaling apply to the hop-by-hop P2MP RSVP-TE signaling. signaling (see [RFC4875] Security Considerations) .
In turn, we observe that the analyses in this document of keying
methods apply equally to P2MP RSVP-TE for the hop-by-hop 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. Group keying can simplify protection of non-hop-by-hop
document about use of group keying for protection of non-hop-by-hop signaling for LSP Hierarchy and P2MP RSVP-TE.
messages apply to protection of non-hop-by-hop signaling for LSP
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 [RFC4301] to protect RSVP. Note also applicable when using IPsec [RFC4301] to protect RSVP.
that [RFC2747] states in section 1.2 that IPsec is not an optimal [RFC2747] states in section 1.2 that IPsec is not an optimal choice
choice to protect RSVP. The key argument is that an IPsec SA and an to protect RSVP. The key argument is that an IPsec SA and an RSVP SA
RSVP SA are not based on the same parameters. Nevertheless, IPsec are not based on the same parameters. Nevertheless, IPsec can be
can be used to protect RSVP. Note that the SPD traffic selectors for used to protect RSVP. The SPD traffic selectors for related RSVP
related RSVP flows will not be constant. In some cases, the source flows will not be constant. In some cases, the source and
and destination addresses are end hosts, and sometimes they are RSVP destination addresses are end hosts, and sometimes they are RSVP
routers. Therefore, traffic selectors in the SPD should specify ANY routers. Therefore, traffic selectors in the SPD are expected to
for the source address and destination addresses, and specify IP specify ANY for the source address and destination addresses, and
protocol 46 (RSVP). 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 [RFC3547] manages group security associations, which can be used by
IPsec. An example GDOI policy would be to encrypt or authenticate IPsec. An example GDOI policy would be to encrypt or authenticate
all packets of the RSVP protocol itself (IP protocol 46). A router all packets of the RSVP protocol itself (IP protocol 46). A router
implementing GDOI and the AH and/or ESP protocols is therefore able implementing GDOI and the AH and/or ESP protocols is therefore able
to implement this policy. 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 should use only the SPI (or SPI plus protocol). lookup is expected to use only the 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 16 skipping to change at page 11, line 46
IPsec tunnel mode encapsulates the original packet, prepending a new IPsec tunnel mode encapsulates the original packet, prepending a new
IP header plus an ESP or AH sub-header. The entire original packet IP header plus an ESP or AH sub-header. The entire original packet
plus the ESP/AH sub-header is secured. In the case of ESP the new, plus the ESP/AH sub-header is secured. In the case of ESP the new,
outer IP header however is not cryptographically secured in this outer IP header however is not cryptographically secured in this
process. process.
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). Note that for RSVP messages to group keying considerations below). For RSVP messages to be visible
be visible and considered at each hop, such a tunnel would not cross and considered at each hop, such a tunnel would not cross routers,
routers, but each RSVP node would establish a tunnel with each of its but each RSVP node would establish a tunnel with each of its peers,
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. This is
independent of the key type used. 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 be routed
along an unintended path. Because RSVP routers encountering the RSVP along 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 should not be used with ESP tunnel mode except with address keying is recommended not be used with ESP tunnel mode except with
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
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
skipping to change at page 13, line 18 skipping to change at page 12, line 46
possible to use a tunnel-endpoint destination address in the Tunnel possible to use a tunnel-endpoint destination address in the Tunnel
Mode outer IP header. The document "Multicast Extensions to the Mode outer IP header. The document "Multicast Extensions to the
Security Architecture for the Internet Protocol" [RFC5374] defines in Security Architecture for the Internet Protocol" [RFC5374] defines in
section 3.1 a new tunnel mode: Tunnel mode with address preservation. section 3.1 a new tunnel mode: Tunnel mode with address preservation.
This mode copies the destination and optionally the source address This mode copies the destination and optionally the source address
from the inner header to the outer header. Therefore the from the inner header to the outer header. Therefore the
encapsulated packet will have the same destination address as the encapsulated packet will have the same destination address as the
original packet, and be normally subject to the same routing original packet, and be normally subject to the same routing
decisions. While [RFC5374] is focusing on multicast environments, decisions. While [RFC5374] is focusing on multicast environments,
tunnel mode with address preservation can be used also to protect tunnel mode with address preservation can be used also to protect
unicast traffic in conjunction with group keying. Note that in this unicast traffic in conjunction with group keying. In this tunnel
tunnel mode the RSVP speakers act as security gateways, because they mode the RSVP speakers act as security gateways, because they
maintain the original end system addresses of the RSVP packets in the maintain the original end system addresses of the RSVP packets in the
outer tunnel mode IP header. This addressing scheme is used by RSVP outer tunnel mode IP header. This addressing scheme is used by RSVP
to ensure that the packets continue along the routed path toward the to ensure that the packets continue along the routed path toward the
destination end host. 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 AH or ESP for protection of RSVP even in keying, allows the use of AH or ESP for protection of RSVP even in
cases where non-RSVP nodes have to be traversed. This is because it cases where non-RSVP nodes have to be traversed. This is because 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.
When used with group keying, tunnel mode with address preservation When used with group keying, tunnel mode with address preservation
can be used to mitigate re-direction attacks where a man-in-the- can be used to mitigate re-direction attacks where a man-in-the-
middle modifies the destination of the outer IP header of the tunnel middle modifies the destination of the outer IP header of the tunnel
mode packet. The inbound processing rules for tunnel mode with mode packet. The inbound processing rules for tunnel mode with
address preservation (Section 5.2 of [RFC5374]) require that the address preservation (Section 5.2 of [RFC5374]) require that the
receiver verify that the addresses in the outer IP header and the receiver verify that the addresses in the outer IP header and the
inner IP header are consistent. Therefore, the attack should be inner IP header are consistent. Therefore, the attack can be
detected and RSVP reservations will not proceed along an unintended detected and RSVP reservations will not proceed along an unintended
path. path.
7. End Host Considerations 7. End Host Considerations
Unless RSVP Proxy entities ([RFC5945] are used, RSVP signaling is Unless RSVP Proxy entities ([RFC5945] are used, RSVP signaling is
controlled by end systems and not routers. As discussed in controlled by end systems and not routers. As discussed in
[RFC4230], RSVP allows both user-based security and host-based [RFC4230], RSVP allows both user-based security and host-based
security. User-based authentication aims at "providing policy based security. User-based authentication aims at "providing policy based
admission control mechanism based on user identities or application." admission control mechanism based on user identities or application."
skipping to change at page 15, line 4 skipping to change at page 14, line 33
aggregated pre-congestion information. One deployment model for aggregated pre-congestion information. One deployment model for
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. Note that from the viewpoint of initial end-to-end Path message. From the viewpoint of securing
securing end-to-end RSVP, there are a lot of similarities in end-to-end RSVP, there are a lot of similarities in scenarios
scenarios involving RSVP Aggregation over aggregate RSVP involving RSVP Aggregation over aggregate RSVP reservations
reservations ([RFC3175], [RFC4860]), RSVP Aggregation over MPLS-TE ([RFC3175], [RFC4860]), RSVP Aggregation over MPLS-TE tunnels
tunnels ([RFC4804]), and RSVP (Aggregation) over PCN ingress- ([RFC4804]), and RSVP (Aggregation) over PCN ingress-egress
egress aggregates. 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 17, line 9 skipping to change at page 16, line 38
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.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-01 Authentication Code Policy", draft-weis-gdoi-mac-tek-02
(work in progress), June 2010. (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
Authentication", RFC 2747, January 2000. Authentication", RFC 2747, January 2000.
[RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie,
"Aggregation of RSVP for IPv4 and IPv6 Reservations", "Aggregation of RSVP for IPv4 and IPv6 Reservations",
 End of changes. 35 change blocks. 
111 lines changed or deleted 107 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/