draft-ietf-tsvwg-rsvp-security-groupkeying-01.txt   draft-ietf-tsvwg-rsvp-security-groupkeying-02.txt 
Network Working Group M. Behringer Network Working Group M. Behringer
Internet-Draft F. Le Faucheur Internet-Draft F. Le Faucheur
Intended status: Informational Cisco Systems Inc Intended status: Informational Cisco Systems Inc
Expires: January 12, 2009 July 11, 2008 Expires: May 7, 2009 November 3, 2008
Applicability of Keying Methods for RSVP Security Applicability of Keying Methods for RSVP Security
draft-ietf-tsvwg-rsvp-security-groupkeying-01.txt draft-ietf-tsvwg-rsvp-security-groupkeying-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 12, 2009. This Internet-Draft will expire on May 7, 2009.
Abstract Abstract
The Resource reSerVation Protocol (RSVP) allows hop-by-hop The Resource reSerVation Protocol (RSVP) allows hop-by-hop
authentication of RSVP neighbors. This requires messages to be authentication of RSVP neighbors. This requires messages to be
cryptographically signed using a shared secret between participating cryptographically signed using a shared secret between participating
nodes. This document compares group keying for RSVP with per nodes. This document compares group keying for RSVP with per
neighbor or per interface keying, and discusses the associated key neighbor or per interface keying, and discusses the associated key
provisioning methods as well as applicability and limitations of provisioning methods as well as applicability and limitations of
these approaches. For example, the Group Domain of Interpretation these approaches. The present document also discusses applicability
(GDOI) could be used to distribute group keys to RSVP nodes. The of group keying to RSVP encryption.
present document also discusses applicability of group keying to RSVP
encryption.
Table of Contents Table of Contents
1. Introduction and Problem Statement . . . . . . . . . . . . . . 3 1. Introduction and Problem Statement . . . . . . . . . . . . . . 3
2. The RSVP Hop-by-Hop Trust Model . . . . . . . . . . . . . . . 3 2. The RSVP Hop-by-Hop Trust Model . . . . . . . . . . . . . . . 3
3. Applicability of Key Types for RSVP . . . . . . . . . . . . . 5 3. Applicability of Key Types for RSVP . . . . . . . . . . . . . 5
3.1. Interface and neighbor based keys . . . . . . . . . . . . 5 3.1. Interface and neighbor based 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 . . . . . . . . . . . . . . 7
4.1. Static Key Provisioning . . . . . . . . . . . . . . . . . 7 4.1. Static Key Provisioning . . . . . . . . . . . . . . . . . 7
4.2. Dynamic Keying . . . . . . . . . . . . . . . . . . . . . . 8 4.2. Dynamic Keying . . . . . . . . . . . . . . . . . . . . . . 8
4.2.1. Neighbor and Interface Based Key Negotiation . . . . . 8 4.2.1. Neighbor and Interface Based Key Negotiation . . . . . 8
4.2.2. Dynamic Group Key Distribution . . . . . . . . . . . . 8 4.2.2. Dynamic Group Key Distribution . . . . . . . . . . . . 8
5. Specific Cases . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Specific Cases . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. RSVP Notify Messages . . . . . . . . . . . . . . . . . . . 8 5.1. RSVP Notify Messages . . . . . . . . . . . . . . . . . . . 8
5.2. RSVP-TE . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.2. RSVP-TE and GMPLS . . . . . . . . . . . . . . . . . . . . 8
6. Applicability of IPsec for RSVP . . . . . . . . . . . . . . . 9 6. Applicability of IPsec for RSVP . . . . . . . . . . . . . . . 10
6.1. Applicability of IPsec ESP . . . . . . . . . . . . . . . . 10 6.1. General Considerations Using IPsec . . . . . . . . . . . . 10
6.2. Applicability of Tunnel Mode . . . . . . . . . . . . . . . 10 6.2. Using IPsec ESP . . . . . . . . . . . . . . . . . . . . . 10
6.3. Applicability of Transport Mode . . . . . . . . . . . . . 11 6.3. Using IPsec AH . . . . . . . . . . . . . . . . . . . . . . 11
6.4. Applicability of Tunnel Mode . . . . . . . . . . . . . . . 11
6.5. Applicability of Transport Mode . . . . . . . . . . . . . 11
7. End Host Considerations . . . . . . . . . . . . . . . . . . . 11 7. End Host Considerations . . . . . . . . . . . . . . . . . . . 11
8. Applicability to Other Architectures and Protocols . . . . . . 11 8. Applicability to Other Architectures and Protocols . . . . . . 12
9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14
10.1. Subverted RSVP Nodes . . . . . . . . . . . . . . . . . . . 13 10.1. Subverted RSVP Nodes . . . . . . . . . . . . . . . . . . . 14
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
12. Changes to Previous Version . . . . . . . . . . . . . . . . . 14 12. Changes to Previous Version . . . . . . . . . . . . . . . . . 15
12.1. changes from behringer-00 to behringer-01 . . . . . . . . 14 12.1. changes from behringer-00 to behringer-01 . . . . . . . . 15
12.2. changes from behringer-01 to ietf-00 . . . . . . . . . . . 14 12.2. changes from behringer-01 to ietf-00 . . . . . . . . . . . 15
12.3. changes from ietf-00 to ietf-01 . . . . . . . . . . . . . 15 12.3. changes from ietf-00 to ietf-01 . . . . . . . . . . . . . 15
13. Informative References . . . . . . . . . . . . . . . . . . . . 15 12.4. changes from ietf-01 to ietf-02 . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 13. Informative References . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 19
1. Introduction and Problem Statement 1. Introduction and Problem Statement
The Resource reSerVation Protocol [RFC2205] allows hop-by-hop The Resource reSerVation Protocol [RFC2205] allows hop-by-hop
authentication of RSVP neighbors, as specified in [RFC2747]. In this authentication of RSVP neighbors, as specified in [RFC2747]. In this
mode, an integrity object is attached to each RSVP message to mode, an integrity object is attached to each RSVP message to
transmit a keyed message digest. This message digest allows the transmit a keyed message digest. This message digest allows the
recipient to verify the authenticity of the RSVP node that sent the recipient to verify the authenticity of the RSVP node that sent the
message, and to validate the integrity of the message. Through the message, and to validate the integrity of the message. Through the
inclusion of a sequence number in the scope of the digest, the digest inclusion of a sequence number in the scope of the digest, the digest
skipping to change at page 3, line 26 skipping to change at page 3, line 26
[RFC2747] does not dictate how the key for the integrity operation is [RFC2747] does not dictate how the key for the integrity operation is
derived. Currently, most implementations of RSVP use a statically derived. Currently, most implementations of RSVP use a statically
configured key, per interface or per neighbor. However, to manually configured key, per interface or per neighbor. However, to manually
configure key per router pair across an entire network is configure key per router pair across an entire network is
operationally hard, especially for key changes. Effectively, many operationally hard, especially for key changes. Effectively, many
users of RSVP therefore resort to the same key throughout their RSVP users of RSVP therefore resort to the same key throughout their RSVP
network, and change it rarely if ever, because of the operational network, and change it rarely if ever, because of the operational
burden. [RFC3562] however recommends regular key changes, at least burden. [RFC3562] however recommends regular key changes, at least
every 90 days. every 90 days.
[I-D.weis-gdoi-mac-tek] provides an example of how group keys could
be dynamically distributed to a set of RSVP routers and updated,
using GDOI ([RFC3547]) for the actual key distribution.
The present document discusses the various keying methods and their The present document discusses the various keying methods and their
applicability to different RSVP deployment environments, for both applicability to different RSVP deployment environments, for both
message integrity and encryption. It does not mandate any particular message integrity and encryption. It does not recommend any
method, but is meant as a comparative guideline to understand where particular method or protocol (e.g., RSVP authentication versus IPsec
each RSVP keying method is best deployed, and its limitations. AH), but is meant as a comparative guideline to understand where each
RSVP keying method is best deployed, and its limitations.
Furthermore, it discusses how RSVP hop by hop authentication is Furthermore, it discusses how RSVP hop by hop authentication is
impacted in the presence of non-RSVP nodes, or subverted nodes, in impacted in the presence of non-RSVP nodes, or subverted nodes, in
the reservation path. the reservation path.
The document "RSVP Security Properties" ([RFC4230]) provides an The document "RSVP Security Properties" ([RFC4230]) provides an
overview of RSVP security, including RSVP Cryptographic overview of RSVP security, including RSVP Cryptographic
Authentication [RFC2747], but does not discuss key management. It Authentication [RFC2747], but does not discuss key management. It
states that "RFC 2205 assumes that security associations are already states that "RFC 2205 assumes that security associations are already
available". The present document focuses specifically on key available". The present document focuses specifically on key
management with different key types, including group keys. Therefore management with different key types, including group keys. Therefore
this document complements [RFC4230]. this document complements [RFC4230].
2. The RSVP Hop-by-Hop Trust Model 2. The RSVP Hop-by-Hop Trust Model
Many protocol security mechanisms used in networks require and use Many protocol security mechanisms used in networks require and use
per peer authentication. Each hop authenticates its neighbor with a per peer authentication. Each hop authenticates its neighbor with a
shared key or certificate. This is also the model used for RSVP. shared key or certificate. This is also the model used for RSVP.
Trust in this model is transitive. Each RSVP node trusts explicitly
Trust in this model is transitive. Each RSVP node trusts explicitely
only its RSVP next hop peers, through the message digest contained in only its RSVP next hop peers, through the message digest contained in
the INTEGRITY object. The next hop RSVP speaker in turn trusts its the INTEGRITY object. The next hop RSVP speaker in turn trusts its
own peers and so on. See also the document "RSVP security own peers and so on. See also the document "RSVP security
properties" [RFC4230] for more background. properties" [RFC4230] for more background.
The keys used for generating the RSVP messages can, in particular, be The keys used for generating the RSVP messages can, in particular, be
group keys (for example distributed via GDOI [RFC3547], as discussed group keys (for example distributed via GDOI [RFC3547], as discussed
in [I-D.weis-gdoi-mac-tek]). in [I-D.weis-gdoi-mac-tek]).
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. Explicitely 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. Implicitely each node trusts each other node with trusted node. Implicitly each node trusts each other node with which
which it has a trust relationship established via the mechanisms here it has a trust relationship established via the mechanisms here to
to adhere to the protocol specifications laid out by the various adhere to the protocol specifications laid out by the various
standards. Note that in any group keying scheme like GDOI a node standards. Note that in any group keying scheme like GDOI a node
trusts explicitely as well as implicitely all the other members of trusts explicitly as well as implicitly all the other members of the
the group. group.
The RSVP protocol can operate in the presence of a non-RSVP router in The RSVP protocol can operate in the presence of a non-RSVP router in
the path from the sender to the receiver. The non-RSVP hop will the path from the sender to the receiver. The non-RSVP hop will
ignore the RSVP message and just pass it along. The next RSVP node ignore the RSVP message and just pass it along. The next RSVP node
can then process the RSVP message. For RSVP authentication or can then process the RSVP message. For RSVP authentication or
encryption to work in this case, the key used for computing the RSVP encryption to work in this case, the key used for computing the RSVP
message digest needs to be shared by the two RSVP neighbors, even if message digest needs to be shared by the two RSVP neighbors, even if
they are not IP neighbors. However, in the presence of non-RSVP they are not IP neighbors. However, in the presence of non-RSVP
hops, while an RSVP node always know the next IP hop before hops, while an RSVP node always knows the next IP hop before
forwarding an RSVP Message, it does not always know the RSVP next forwarding an RSVP Message, it does not always know the RSVP next
hop. In fact, part of the role of a Path message is precisely to hop. In fact, part of the role of a Path message is precisely to
discover the RSVP next hop (and to dynamically re-discover it when it discover the RSVP next hop (and to dynamically re-discover it when it
changes, for example because of a routing change). Thus, the changes, for example because of a routing change). Thus, the
presence of non-RSVP hops impacts operation of RSVP authentication or presence of non-RSVP hops impacts operation of RSVP authentication or
encryption and may influence the selection of keying approaches. encryption and may 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 encrpytion. 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 addresed to the knows that the next IP hop for a Path message addressed to the
receiver is R2, but it does necessarily not know if the RSVP next hop receiver is R2, but it does necessarily not know if the RSVP next hop
is R3 or R5. is R3 or R5.
This means that per interface and per neighbor keys cannot easily be This means that per interface and per neighbor keys cannot easily be
used in the presence of non-RSVP routers on the path between senders used in the presence of non-RSVP routers on the path between senders
and receivers. and receivers.
By contrast, group keying will naturally work in the presence of non- By contrast, group keying will naturally work in the presence of non-
RSVP routers. Referring back to Figure 1, with group keying, R1 RSVP routers. Referring back to Figure 1, with group keying, R1
would use the group key to sign a Path message addressed to the would use the group key to sign a Path message addressed to the
skipping to change at page 6, line 30 skipping to change at page 6, line 20
3.2. Group keys 3.2. Group keys
Here, all members of a group of RSVP nodes share the same key. This Here, all members of a group of RSVP nodes share the same key. This
implies that a node uses the same key regardless of the next RSVP hop implies that a node uses the same key regardless of the next RSVP hop
that will process the message (within the group of nodes sharing the that will process the message (within the group of nodes sharing the
particular key). It also implies that a node will use the same key particular key). It also implies that a node will use the same key
on the receiving as on the sending side (when exchanging RSVP on the receiving as on the sending side (when exchanging RSVP
messages within the group). messages within the group).
Group keys apply naturally to intra-domain RSVP authentication, since Group keys apply naturally to intra-domain RSVP authentication, since
all RSVP nodes implicitely trust each other. Using group keys, they all RSVP nodes implicitly trust each other. Using group keys, they
extend this trust to the group key server. This is represented in extend this trust to the group key server. This is represented in
Figure 2. Figure 2.
......GKS1............. ......GKS1.............
: : : : : : : : : :
: : : : : : : : : :
source--R1--R2--R3-----destination source--R1--R2--R3-----destination
| | | |
|<-----domain 1----------------->| |<-----domain 1----------------->|
skipping to change at page 8, line 30 skipping to change at page 8, line 20
To avoid the problem of manual key provisioning and updates in static To avoid the problem of manual key provisioning and updates in static
key deployments, key negotiation between RSVP neighbors could be used key deployments, key negotiation between RSVP neighbors could be used
to derive either interface or neighbor based keys. However, existing to derive either interface or neighbor based keys. However, existing
key negotiation protocols such as IKEv1 [RFC2409] or IKEv2 [RFC4306] key negotiation protocols such as IKEv1 [RFC2409] or IKEv2 [RFC4306]
may not be appropriate in all environments because of the relative may not be appropriate in all environments because of the relative
complexity of the protocols and related operations. complexity of the protocols and related operations.
4.2.2. Dynamic Group Key Distribution 4.2.2. Dynamic Group Key Distribution
With this approach, group keys are dyanmically distributed among a With this approach, group keys are dynamically distributed among a
set of RSVP routers. For example, [I-D.weis-gdoi-mac-tek] describes set of RSVP routers. For example, [I-D.weis-gdoi-mac-tek] describes
a mechanism to distribute group keys to a group of RSVP speakers, a mechanism to distribute group keys to a group of RSVP speakers,
using GDOI [RFC3547]. In this solution, a key server authenticates using GDOI [RFC3547]. In this solution, a key server authenticates
each of the RSVP nodes independently, and then distributes a group each of the RSVP nodes independently, and then distributes a group
key to the entire group. key to the entire group.
5. Specific Cases 5. Specific Cases
5.1. RSVP Notify Messages 5.1. RSVP Notify Messages
skipping to change at page 9, line 6 skipping to change at page 8, line 43
Security Considerations section of [RFC3473], this can interfere with Security Considerations section of [RFC3473], this can interfere with
RSVP's hop-by-hop integrity and authentication model. [RFC3473] RSVP's hop-by-hop integrity and authentication model. [RFC3473]
describes how standard IPsec based integrity and authentication can describes how standard IPsec based integrity and authentication can
be used to protect Notify messages. We observe that, alternatively, be used to protect Notify messages. We observe that, alternatively,
in some environments, group keying may allow use of regular RSVP in some environments, group keying may allow use of regular RSVP
authentication ([RFC2747]) for protection of non-hop-by-hop Notify authentication ([RFC2747]) for protection of non-hop-by-hop Notify
messages. For example, this may be applicable to controlled messages. For example, this may be applicable to controlled
environments where nodes invoking notification requests are known to environments where nodes invoking notification requests are known to
belong to the same key group as nodes generating Notify messages. belong to the same key group as nodes generating Notify messages.
5.2. RSVP-TE 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] deserve additional considerations. For example, 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) from the failure of a protect Label Switched Paths (protected LSPs) against the failure of
facility (e.g. a router) located between the PLR and the MP. During a facility (e.g. a router) located between the PLR and the MP.
the failure of the facility, the PLR redirects a protected LSP inside During the failure of the facility, the PLR redirects a protected LSP
the backup tunnel and also exchange RSVP control message for the inside the backup tunnel and as a result, the PLR and MP then need to
maintenance the protected LSP over the backup tunnel. Therefore, exchange RSVP control messages between each other (e.g. for the
during the rerouted period, the PLR and the MP effectively become maintenance of the protected LSP). Some of the RSVP messages between
RSVP neighbors while they may not be directly connected to each other the PLR and MP are sent over the backup tunnel (e.g. a Path message
and thus do not behave as RSVP neighbors in the absence of failure. 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,
the PLR and the MP effectively become RSVP neighbors, while they may
not be directly connected to each other and thus do not behave as
RSVP neighbors in the absence of failure. This point is raised in
the Security Considerations section of [RFC4090] that says: "Note
that the facility backup method requires that a PLR and its selected
merge point trust RSVP messages received from each other." We
observe that such environments may benefit from group keying: a group
key can be used among a set of routers enabled for Fast Reroute
thereby easily ensuring that a PLR and MP authenticate messages from
each other, without requiring prior specific configuration of keys,
or activation of key update mechanism, for every possible pair of PLR
and MP.
This point is raised in the Security Considerations section of Where RSVP-TE or RSVP-TE Fast Reroute is deployed across AS
[RFC4090] that says: "Note that the facility backup method requires boundaries (see [RFC4216]), the considerations presented above in
that a PLR and its selected merge point trust RSVP messages received section 3.1 and 3.2 apply such that per interface or per neighbor
from each other." We observe that such environments may benefit from keys can be used between two RSVP neighbors in different ASes
group keying since the group key could also be easily used between (independently of the keying method used by the RSVP router to talk
the PLR and the MP. to the RSVP routers in the same AS).
[RFC4875] specifies protocol extensions for support of Point-to-
Multipoint (P2MP) RSVP-TE. In its security considerations section,
[RFC4875] points out that RSVP message integrity mechanisms for hop-
by-hop RSVP signaling apply to the hop-by-hop P2MP RSVP-TE signaling.
In turn, we observe that the considerations in this document on
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
signaling. Because it reuses LSP Hierarchy procedures for some of
its operations, P2MP RSVP-TE also uses non-hop-by-hop signaling.
Both LSP hierarchy and P2MP RSVP-TE rely on the security mechanisms
defined in [RFC3473] and [RFC4206] for non hop-by-hop RSVP-TE
signaling. We note that the observation in section 3.1 of this
document about use of group keying for protection of non-hop-by-hop
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
The discussions about the various keying methods in this document are The discussions about the various keying methods in this document are
applicable to the built-in authentication in the RSVP protocol, using also applicable when using IPsec to protect RSVP. Note that
the INTEGRITY object, as defined in [RFC2747]. In principle, they [RFC2747] states in section 1.2 that IPsec is not an optimal choice
are also applicable to using IPsec to protect RSVP, however,
[RFC2747] discusses in section 1.2 why IPsec is not an optimal choice
to protect RSVP. The key argument is that an IPsec SA and an RSVP SA to protect RSVP. The key argument is that an IPsec SA and an RSVP SA
are not based on the same parameters. We believe that group keying are not based on the same parameters. However, when using group
may solve some of the issues mentioned. [Editorial note: Detailed keying, IPsec can be used to protect RSVP. The potential issues and
discussion will be added in the next version of the document.] solutions using group keying are:
To address specific requirements for RSVP encryption, we focus the
discussion here on IPsec ESP (Encapsulation security payload;
[RFC4303]).
IPsec Authentication Header (AH) is currently not considered in this
document, since authentication is built into RSVP through the
mechansims defined by [RFC2747].
6.1. Applicability of IPsec ESP o [RFC2747] specifies in section 4.2, bullet 3, that both the key
identifier and the sending system address are used to uniquely
determine the key. In a group keying scenario it would be
necessary to either store a list of senders to do this, or to not
use the sending system address to determine the key. Both methods
are valid, and one of the two approaches must be chosen. The pros
and cons are beyond the scope of this document.
o Anti-replay protection in a group keying scenario requires some
changes to the way [RFC2747] defines anti-replay. Possible
solutions are discussed in detail in [I-D.weis-gdoi-mac-tek]).
For example, when using counter-based methods with various senders
in a single SA, the same counter may be received more than once,
this conflicts with [RFC2747], which states that each counter
value may only be accepted once. Time based approaches are a
solution for group keying scenarios.
The keying approaches discussed in this document can also be used to The document "The Multicast Group Security Architecture" [RFC3740]
encrypt the RSVP messages using IPsec [RFC4301], instead of, or in defines in detail a "Group Security Association" (GSA). This
addition to authenticating them. The same considerations apply for definition is also applicable in the context discussed here, and
this case as discussed above for the authentication case. Group keys allows the use of IPsec for RSVP. The existing GDOI standard
are applicable only within a trusted domain, but they allow operation [RFC3547] contains all relevant policy options to secure RSVP with
through non-RSVP speakers without further configuration. Per IPsec, and no extensions are necessary. An example GDOI policy would
interface or per neighbor keys work also inter-domain, but do not be to encrypt all packets of the RSVP protocol itself (IP protocol
operate in the presence of a non-RSVP router. 46). A router implementing GDOI and IPsec protocols is therefore
able to implement RSVP encryption.
The existing GDOI standard as described in [RFC3547] contains all 6.2. Using IPsec ESP
relevant policy options to allow for RSVP encryption, and no
extensions are necessary. An example GDOI policy would be to encrypt
all packets of the RSVP protocol itself (IP protocol 46). A router
implementing GDOI and IPsec is therefore able to implement RSVP
encryption.
Since in both tunnel mode and transport mode ESP does not protect the In both tunnel mode and transport mode, ESP does not protect the
header (in tunnel mode the outer header), there is an issue with header (in tunnel mode the outer header). This is an issue with
group keying, when using ESP to secure the RSVP packets: The packet group keying when using ESP to secure the RSVP packets: the packet
header could be modified by a man-in-the-middle attack, replacing the header could be modified by a man-in-the-middle attack, replacing the
destination address with another RSVP router in the network. This destination address with another RSVP router in the network. This
router will receive the packet, use the group key to decrypt the router will receive the packet, use the group key to decrypt the
encapsulated packet, and then act on the RSVP packet. This way an encapsulated packet, and then act on the RSVP packet. This way an
attacker cannot create new reservations or affect existing ones, but attacker cannot create new reservations or affect existing ones, but
he can "re-direct" reservations to parts of the network off the he can "re-direct" reservations to parts of the network off the
actual reservation path, thereby potentially denying resources to actual reservation path, thereby potentially denying resources to
other applications on that part of the network. other applications on that part of the network.
6.2. Applicability of Tunnel Mode 6.3. Using IPsec AH
IPsec tunnel mode for ESP encapsulates and encypts the original The INTEGRITY object defined by [RFC2747] provides integrity
packet, prepending a new IP tunnel header plus an ESP sub-header. protection for RSVP also in a group keying context, as discussed
The entire original packet is encrypted, and the integrity of the above. IPsec AH is an alternative method to provide integrity
original packet plus the ESP subheader is secured. The new, outer IP protection for RSVP. Both methods provide comparable security.
header however is not cryptographically secured in this process.
Protecting RSVP packets with IPsec ESP tunnel mode works with any of 6.4. Applicability of Tunnel Mode
the above described keying methods (interface, neighbor or group
based), as long as there are no non-RSVP nodes on the path. Note IPsec tunnel mode encapsulates the original packet, prepending a new
that for RSVP messages to be visible and considered at each hop, such IP tunnel header plus an ESP or AH sub-header. The entire original
a tunnel would not cross routers, but each RSVP node would establish packet plus the ESP/AH subheader is secured. In the case of ESP the
a tunnel with each of its peers, effectively leading to link new, outer IP header however is not cryptographically secured in this
protection. process. This leads to the problem described in Section 6.2. AH
tunnel mode also secures the outer header, and is therefore not
subject to these man-in-the-middle attacks.
Protecting RSVP packets with IPsec tunnel mode works with any of the
above described keying methods (interface, neighbor or group based),
as long as there are no non-RSVP nodes on the path. Note that for
RSVP messages to be visible and considered at each hop, such a tunnel
would not cross routers, but each RSVP node would establish a tunnel
with each of its peers, effectively leading to link protection.
In the presence of a non-RSVP hop, tunnel mode can not be applied, In the presence of a non-RSVP hop, tunnel mode can not be applied,
because a router upstream a non-RSVP hop does not know the next RSVP because a router upstream a non-RSVP hop does not know the next RSVP
hop, and can thus not apply the correct tunnel header. This is hop, and can thus not apply the correct tunnel header. This is
independent of the key type used. independent of the key type used.
6.3. Applicability of Transport Mode 6.5. Applicability of Transport Mode
IPsec transport mode for ESP, as defined in [RFC4303] is not suitable IPsec transport mode, as defined in [RFC4303] is not suitable for
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 explicitely that original source and destination. [RFC4303] states explicitly that
"the use of transport mode by an intermediate system (e.g., a "the use of transport mode by an intermediate system (e.g., a
security gateway) is permitted only when applied to packets whose security gateway) is permitted only when applied to packets whose
source address (for outbound packets) or destination address (for source address (for outbound packets) or destination address (for
inbound packets) is an address belonging to the intermediate system inbound packets) is an address belonging to the intermediate system
itself. This would not be the case for RSVP Path messages. itself." This would not be the case for RSVP Path messages.
7. End Host Considerations 7. End Host Considerations
Unless RSVP Proxy entities ([I-D.ietf-tsvwg-rsvp-proxy-approaches] Unless RSVP Proxy entities ([I-D.ietf-tsvwg-rsvp-proxy-approaches]
are used, RSVP signaling is controlled by end systems and not are used, RSVP signaling is controlled by end systems and not
routers. As discussed in [RFC4230], RSVP allows both user-based routers. As discussed in [RFC4230], RSVP allows both user-based
security and host-based security. User-based authentication aims at security and host-based security. User-based authentication aims at
"providing policy based admission control mechanism based on user "providing policy based admission control mechanism based on user
identities or application." To identify the user or the application, identities or application." To identify the user or the application,
a policy element called AUTH_DATA, which is contained in the a policy element called AUTH_DATA, which is contained in the
skipping to change at page 12, line 44 skipping to change at page 13, line 23
that from the viewpoint of securing end-to-end RSVP, there are a that from the viewpoint of securing end-to-end RSVP, there are a
lot of similarities in scenarios involving RSVP Aggregation over lot of similarities in scenarios involving RSVP Aggregation over
aggregate RSVP reservations ([RFC3175], [RFC4860]), RSVP aggregate RSVP reservations ([RFC3175], [RFC4860]), RSVP
Aggregation over MPLS-TE tunnels ([RFC4804]), and RSVP Aggregation over MPLS-TE tunnels ([RFC4804]), and RSVP
(Aggregation) over PCN ingress-egress aggregates. (Aggregation) over PCN ingress-egress aggregates.
9. Summary 9. Summary
The following table summarizes the various approaches for RSVP The following table summarizes the various approaches for RSVP
keying, and their applicability to various RSVP scenarios. In keying, and their applicability to various RSVP scenarios. In
particular, such keying can be used for RSVP Authentication and/ or particular, such keying can be used for RSVP authentication (e.g.,
for RSVP Encryption (using ESP in Tunnel mode). using RSVP authentication or IPsec AH) and/ or for RSVP encryption
(e.g., using IPsec ESP in tunnel mode).
+-----------------------------+--------------------+----------------+ +-----------------------------+--------------------+----------------+
| | Neighbor/interface | Group keys | | | Neighbor/interface | Group keys |
| | based keys | | | | based keys | |
+-----------------------------+--------------------+----------------+ +-----------------------------+--------------------+----------------+
| Works intra-domain | Yes | Yes | | Works intra-domain | Yes | Yes |
| Works inter-domain | Yes | No | | Works inter-domain | Yes | No |
| Works over non-RSVP hops | No | Yes (1) | | Works over non-RSVP hops | No | Yes (1) |
| Dynamic keying | Yes (IKE) | Yes (eg GDOI) | | Dynamic keying | Yes (IKE) | Yes (eg GDOI) |
+-----------------------------+--------------------+----------------+ +-----------------------------+--------------------+----------------+
skipping to change at page 13, line 26 skipping to change at page 13, line 48
(1): RSVP authentication with group keys works over non-RSVP nodes; (1): RSVP authentication with group keys works over non-RSVP nodes;
RSVP encryption with IPsec ESP Tunnel mode does not. RSVP encryption with IPsec ESP Tunnel mode does not.
We also make the following observations: We also make the following observations:
o All key types can be used statically, or with dynamic key o All key types can be used statically, or with dynamic key
negotiation. This impacts the managability of the solution, but negotiation. This impacts the managability of the solution, but
not the applicability itself. not the applicability itself.
o For encryption of RSVP messages IPsec ESP in tunnel mode can be o For encryption of RSVP messages IPsec ESP in tunnel mode can be
used. There is however a security concern, see Section 6.1. used. There is however a security concern, see Section 6.2.
o There are some special cases in RSVP, like non-RSVP hosts, the o There are some special cases in RSVP, like non-RSVP hosts, the
"notify" message, the various RSVP deployment models discussed in "Notify" message (as discussed in section 5.1), the various RSVP
Section 8 and MPLS traffic engineering, which would benefit from a deployment models discussed in Section 8 and MPLS Traffic
group keying approach. Engineering and GMPLS discussed in section 5.2 , which would
benefit from a group keying approach.
10. Security Considerations 10. Security Considerations
This entire document discusses RSVP security; this section describes This entire document discusses RSVP security; this section describes
a specific security considerations relating to subverted RSVP nodes a specific security considerations relating to subverted RSVP nodes
10.1. Subverted RSVP Nodes 10.1. Subverted RSVP Nodes
A subverted node is defined here as an untrusted node, for example A subverted node is defined here as an untrusted node, for example
because an intruder has gained control over it. Since RSVP because an intruder has gained control over it. Since RSVP
skipping to change at page 14, line 48 skipping to change at page 15, line 30
contains all necessary mechanisms to do RSVP encrpytion. contains all necessary mechanisms to do RSVP encrpytion.
o Tried to clarify the "trust to do what?" question raised by Bob o Tried to clarify the "trust to do what?" question raised by Bob
Briscoe in a mail on 26 Jul 2007. See the section on trust model. Briscoe in a mail on 26 Jul 2007. See the section on trust model.
o Lots of small editorial changes (references, typos, figures, etc). o Lots of small editorial changes (references, typos, figures, etc).
o Added an Acknowledgements section. o Added an Acknowledgements section.
12.2. changes from behringer-01 to ietf-00 12.2. changes from behringer-01 to ietf-00
o various edits to make it clearer that draft-weis-gdoi-for-rsvp is o various edits to make it clearer that draft-weis-gdoi-for-rsvp is
an example of how dynamic group keying could be achieved for RSVP an example of how dynamic group keying could be achieved for RSVP
and not necesarily the recommended solution and not necessarily the recommended solution
12.3. changes from ietf-00 to ietf-01 12.3. changes from ietf-00 to ietf-01
o Significant re-structuring of the entire document, to improve the o Significant re-structuring of the entire document, to improve the
flow, and provide more consistency in various sections. flow, and provide more consistency in various sections.
o Moved the "Subverted RSVP nodes" discussion into the security o Moved the "Subverted RSVP nodes" discussion into the security
considerations section. considerations section.
o Added a "summary" section. o Added a "summary" section.
o Complete re-write of the old section 5.5 (RSVP encryption), and o Complete re-write of the old section 5.5 (RSVP encryption), and
"promotion" to a separate section. "promotion" to a separate section.
o Changed reference ID.weis-gdoi-for-rsvp to the new draft ID.weis- o Changed reference ID.weis-gdoi-for-rsvp to the new draft ID.weis-
gdoi-mac-tek gdoi-mac-tek
o in several places, explicitely mentioned "encryption" for RSVP (in o in several places, explicitly mentioned "encryption" for RSVP (in
parallel to authentication). parallel to authentication).
o Various minor edits. o Various minor edits.
12.4. changes from ietf-01 to ietf-02
o Re-wrote and re-structured the section on IPsec (section 6).
o Re-wrote the section on RSVP-TE and GMPLS (section 5.2).
o Various editorial changes.
13. Informative References 13. Informative References
[I-D.ietf-pcn-architecture] [I-D.ietf-pcn-architecture]
Eardley, P., "Pre-Congestion Notification Architecture", Eardley, P., "Pre-Congestion Notification (PCN)
draft-ietf-pcn-architecture-03 (work in progress), Architecture", draft-ietf-pcn-architecture-08 (work in
February 2008. progress), October 2008.
[I-D.ietf-tsvwg-rsvp-proxy-approaches] [I-D.ietf-tsvwg-rsvp-proxy-approaches]
Faucheur, F., Manner, J., Wing, D., and A. Guillou, "RSVP Faucheur, F., Manner, J., Wing, D., and A. Guillou, "RSVP
Proxy Approaches", Proxy Approaches",
draft-ietf-tsvwg-rsvp-proxy-approaches-04 (work in draft-ietf-tsvwg-rsvp-proxy-approaches-06 (work in
progress), April 2008. progress), October 2008.
[I-D.weis-gdoi-mac-tek] [I-D.weis-gdoi-mac-tek]
Weis, B. and S. Rowles, "GDOI Generic Message Weis, B. and S. Rowles, "GDOI Generic Message
Authentication Code Policy", draft-weis-gdoi-mac-tek-00 Authentication Code Policy", draft-weis-gdoi-mac-tek-00
(work in progress), July 2008. (work in progress), July 2008.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997. Functional Specification", RFC 2205, September 1997.
skipping to change at page 16, line 19 skipping to change at page 17, line 5
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic (GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The
Group Domain of Interpretation", RFC 3547, July 2003. Group Domain of Interpretation", RFC 3547, July 2003.
[RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 [RFC3562] Leech, M., "Key Management Considerations for the TCP MD5
Signature Option", RFC 3562, July 2003. Signature Option", RFC 3562, July 2003.
[RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security
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)
Hierarchy with Generalized Multi-Protocol Label Switching
(GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
[RFC4216] Zhang, R. and J. Vasseur, "MPLS Inter-Autonomous System
(AS) Traffic Engineering (TE) Requirements", RFC 4216,
November 2005.
[RFC4230] Tschofenig, H. and R. Graveman, "RSVP Security [RFC4230] Tschofenig, H. and R. Graveman, "RSVP Security
Properties", RFC 4230, December 2005. Properties", RFC 4230, December 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005. RFC 4303, December 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005. RFC 4306, December 2005.
[RFC4804] Le Faucheur, F., "Aggregation of Resource ReSerVation [RFC4804] Le Faucheur, F., "Aggregation of Resource ReSerVation
Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels", Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels",
RFC 4804, February 2007. RFC 4804, February 2007.
[RFC4860] Le Faucheur, F., Davie, B., Bose, P., Christou, C., and M. [RFC4860] Le Faucheur, F., Davie, B., Bose, P., Christou, C., and M.
Davenport, "Generic Aggregate Resource ReSerVation Davenport, "Generic Aggregate Resource ReSerVation
Protocol (RSVP) Reservations", RFC 4860, May 2007. Protocol (RSVP) Reservations", RFC 4860, May 2007.
[RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa,
"Extensions to Resource Reservation Protocol - Traffic
Engineering (RSVP-TE) for Point-to-Multipoint TE Label
Switched Paths (LSPs)", RFC 4875, May 2007.
Authors' Addresses Authors' Addresses
Michael H. Behringer Michael H. Behringer
Cisco Systems Inc Cisco Systems Inc
Village d'Entreprises Green Side Village d'Entreprises Green Side
400, Avenue Roumanille, Batiment T 3 400, Avenue Roumanille, Batiment T 3
Biot - Sophia Antipolis 06410 Biot - Sophia Antipolis 06410
France France
Email: mbehring@cisco.com Email: mbehring@cisco.com
 End of changes. 48 change blocks. 
126 lines changed or deleted 188 lines changed or added

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