| Network Working Group | M. Behringer |
| Internet-Draft | F. Le Faucheur |
| Intended status: Informational | B. Weis |
| Expires: December 26, 2011 | Cisco Systems |
| June 24, 2011 |
Applicability of Keying Methods for RSVP Security
draft-ietf-tsvwg-rsvp-security-groupkeying-10.txt
The Resource reSerVation Protocol (RSVP) allows hop-by-hop integrity protection of RSVP neighbors. This requires messages to be cryptographically protected using a shared secret between participating nodes. This document compares group keying for RSVP with per neighbor or per interface keying, and discusses the associated key provisioning methods as well as applicability and limitations of these approaches. The document also discusses applicability of encrypting RSVP messages.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 26, 2011.
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
The Resource reSerVation Protocol [RFC2205] allows hop-by-hop authentication of RSVP neighbors, as specified in [RFC2747]. In this mode, an integrity object is attached to each RSVP message to transmit a keyed message digest. This message digest allows the recipient to verify the identity of the RSVP node that sent the message, and to validate the integrity of the message. Through the inclusion of a sequence number in the scope of the digest, the digest also offers replay protection.
[RFC2747] does not dictate how the key for the integrity operation is derived. Currently, most implementations of RSVP use a statically configured key, per interface or per neighbor. However, to manually configure a key per router pair across an entire network is operationally hard, especially when key changes are to be performed on a regular basis. Effectively, many users of RSVP therefore resort to using the same key throughout their RSVP network, and they change it rarely if ever, because of the operational burden. It is however often necessary to regularly change keys due to network operational requirements.
This document discusses a variety of keying methods and their applicability to different RSVP deployment environments, for both message integrity and encryption. It is meant as a comparative guide to understand where each RSVP keying method is best deployed, and the limitations of each method. Furthermore, it discusses how RSVP hop by hop authentication is impacted in the presence of non-RSVP nodes, or subverted nodes, in the reservation path.
The document "RSVP Security Properties" ([RFC4230]) provides an overview of RSVP security, including RSVP Cryptographic Authentication [RFC2747], but does not discuss key management. It states that "RFC 2205 assumes that security associations are already available". The present document focuses specifically on key management with different key types, including group keys. Therefore this document complements [RFC4230].
A security domain is defined in this document as a set of nodes that shares a common RSVP security policy.
Many protocol security mechanisms used in networks require and use per peer authentication. Each hop authenticates messages from its neighbor with a shared key or certificate. This is also the model used for RSVP. Trust in this model is transitive. Each RSVP node trusts explicitly only its RSVP next hop peers, through the message digest contained in the INTEGRITY object. The next hop RSVP speaker in turn trusts its own peers and so on. See also the document "RSVP security properties" [RFC4230] for more background.
The keys used for protecting RSVP messages can, in particular, be group keys (for example distributed via GDOI [RFC3547], as discussed in [I-D.weis-gdoi-mac-tek]). If a group key is used, the authentication granularity becomes group membership of devices, not (individual) peer authentication between devices.
The trust an RSVP node has to another RSVP node has an explicit and an implicit component. Explicitly the node trusts the other node to maintain the RSVP messages intact or confidential, depending on whether authentication or encryption (or both) is used. This means only that the message has not been altered or seen by another, non-trusted node. Implicitly each node trusts each other node with which it has a trust relationship established via the mechanisms here to adhere to the protocol specifications laid out by the various standards. In any group keying scheme like GDOI a node trusts all the other members of the group (because the authentication is now based on group membership, as noted above).
The RSVP protocol can operate in the presence of a non-RSVP router in the path from the sender to the receiver. The non-RSVP hop will ignore the RSVP message and just pass it along. The next RSVP node can then process the RSVP message. For RSVP authentication or encryption to work in this case, the key used for computing the RSVP message digest needs to be shared by the two RSVP neighbors, even if they are not IP neighbors. In the presence of non-RSVP hops, while an RSVP node always knows the next IP hop before forwarding an RSVP Message, it does not always know the RSVP next hop. In fact, part of the role of a Path message is precisely to discover the RSVP next hop (and to dynamically re-discover it when it changes, for example because of a routing change). Thus, the presence of non-RSVP hops impacts operation of RSVP authentication or encryption and may influence the selection of keying approaches.
Figure 1 illustrates this scenario. R2 in this picture does not participate in RSVP, the other nodes do. In this case, R2 will pass on any RSVP messages unchanged, and will ignore them.
----R3---
/ \
sender----R1---R2(*) R4----receiver
\ /
----R5---
(*) Non-RSVP hop
This creates a challenge for RSVP authentication and encryption. In 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 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 receiver is R2, but it does necessarily not know if the RSVP next hop is R3 or R5. This means that per interface and per neighbor keys cannot easily be used in the presence of non-RSVP routers on the path between senders and receivers.
Section 4.3 of [RFC2747] states that "... the receiver MAY initiate an integrity handshake with the sender." If this handshake is taking place, it can be used to determine the identity of the next RSVP hop. In this case, non-RSVP hops can be traversed also using per interface or per neighbor keys.
Group keying will naturally work in the presence of non-RSVP routers. Referring back to Figure 1, with group keying, R1 would use the group key to 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 message to R3 or R5 depending on the current shortest path as determined by routing. Whether it is R3 or R5, the RSVP router that receives the Path message will be able to authenticate the message successfully using the group key.
Most current RSVP authentication implementations support per interface RSVP keys. When the interface is point-to-point (and therefore an RSVP router has only a single RSVP neighbor on each interface), this is equivalent to per neighbor keys in the sense that a different key is used for each neighbor. However, when the interface is multipoint, all RSVP speakers on a given subnet have to belong to the same security domain and share the same key in this model. This makes it unsuitable for deployment scenarios where nodes from different security domains are present on a subnet, for example Internet exchange points. In such cases, per neighbor keys are required.
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 security domains on a single interface and subnet.
Per interface and per neighbor keys can be used within a single security domain.
These key types can also be used between security domains, since they are specific to a particular interface or neighbor.
Both monotonically increasing sequence number (e.g., the INTEGRITY object simple sequence numbers [RFC2747], or the ESP and AH anti-replay service [RFC4301] sequence numbers) and time based anti-replay methods (e.g., the INTEGRITY sequence numbers based on a clock [RFC2747]) can be used with per neighbor and per interface keys.
As discussed in the previous section, per neighbor and per interface keys can not be used in the presence of non-RSVP hops.
In the case of group keys, all members of a group of RSVP nodes share the same key. This implies that a node uses the same key regardless of the next RSVP hop that will process the message (within the group of nodes sharing the particular key). It also implies that a node will use the same key on the receiving as on the sending side (when exchanging RSVP messages within the group).
Group keys apply naturally to intra-domain RSVP authentication, where all RSVP nodes are part of the same security domain and implicitly trust each other. Using group keys, they extend this trust to the group key server. This is represented in Figure 2.
......GKS1.............
: : : : :
: : : : :
source--R1--R2--R3-----destination
| |
|<-----domain 1----------------->|
A single group key cannot normally be used to cover multiple security domains, because by definition the different domains do not trust each other. They would therefore not be willing to trust the same group key server. For a single group key to be used in several security domains, there is a need for a single group key server, which is trusted by both sides. While this is theoretically possible, in practice it is unlikely that there is a single such entity trusted by both domains. Figure 3 illustrates this setup.
...............GKS1....................
: : : : : : : :
: : : : : : : :
source--R1--R2--R3--------R4--R5--R6--destination
| | | |
|<-----domain 1--->| |<-------domain 2----->|
A more practical approach for RSVP operation across security domains, is to use a separate group key server for each security domain, and to use per interface or per neighbor keys between the two domains. Figure 4 shows this setup.
....GKS1...... ....GKS2.........
: : : : : : : :
: : : : : : : :
source--R1--R2--R3--------R4--R5--R6--destination
| | | |
|<-----domain 1--->| |<-------domain 2----->|
As discussed in Section 2, group keying can be used in the presence of non-RSVP hops.
Because a group key may be used to verify messages from different peers, monotonically increasing sequence number methods are not appropriate. Time based anti-replay methods (e.g., the INTEGITY sequence numbers based on a clock [RFC2747]) can be used with group keys.
Static keys are preconfigured, either manually, or through a network management system. The simplest way to implement RSVP authentication is to use static keys. Static keying can be used with per interface keys, per neighbor keys or group keys.
The provisioning of static keys requires either manual operator intervention on each node, or a network management system performing the same task. Time synchronization of static key provisioning and changes is critical, to avoid inconsistent keys within a security domain.
Static key provisioning is therefore not an ideal model in a large network.
Often, the number of interconnection points across two domains where RSVP is allowed to transit is relatively small and well controlled. Also, the different domains may not be in a position to use an infrastructure trusted by both domains to update keys on both sides. Thus, statically provisioned keys may be applicable to inter-domain RSVP authentication.
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 implemented during which an RSVP node will accept both the old and the new key. Otherwise, RSVP operation would suffer interruptions. (Also with dynamic keying approaches there can be a grace period where two keys are valid at the same time; however, the grace period in manual keying tends to be significantly longer than with dynamic key rollover schemes.)
To avoid the problem of manual key provisioning and updates in static key deployments, key negotiation between RSVP neighbors could be used to derive either per interface or per neighbor keys.
With this approach, group keys are dynamically distributed among a set of RSVP routers. For example, [I-D.weis-gdoi-mac-tek] describes a mechanism to distribute group keys to a group of RSVP speakers, using GDOI [RFC3547]. In this solution, a key server authenticates each of the RSVP nodes independently, and then distributes a group key to the group as part of an encrypted and integrity protected key agreement protocol. The authentication in this model can be based on public key mechanisms, thereby avoiding the need for static key provisioning.
[RFC3473] introduces the Notify message and allows such messages to be sent in a non-hop-by-hop fashion. As discussed in the Security Considerations section of [RFC3473], this can interfere with RSVP's hop-by-hop integrity and authentication model. [RFC3473] describes how standard IPsec based integrity and authentication can be used to protect Notify messages.
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 engineering in MPLS networks are non-hop-by-hop messages. Such messages may be sent from an ingress node directly to an egress node. Group keying in such a case avoids the establishment of node-to-node keying when node-to-node keying is not otherwise used.
Use of RSVP authentication for RSVP-TE [RFC3209] and for RSVP-TE Fast Reroute [RFC4090] deserves additional considerations.
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 protect Label Switched Paths (protected LSPs) against the failure of a facility (e.g., a router) located between the PLR and the MP. During the failure of the facility, the PLR redirects a protected LSP inside the backup tunnel and as a result, the PLR and MP then need to exchange RSVP control messages between each other (e.g., for the 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 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." 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 PLR and MP authenticate messages from each other can be authenticated, without requiring prior specific configuration of keys, or activation of key update mechanism, for every possible pair of PLR and MP.
Where RSVP-TE or RSVP-TE Fast Reroute is deployed across AS boundaries (see [RFC4216]), the considerations presented above in 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 (independently of the keying method used by the RSVP router to talk to the RSVP routers in the same AS).
[RFC4875] specifies protocol extensions for support of Point-to- Multipoint (P2MP) RSVP-TE. RSVP message integrity mechanisms for hop-by-hop RSVP signaling apply to the hop-by-hop P2MP RSVP-TE signaling (see [RFC4875] Security Considerations) .
[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. Group keying can simplify protection of non-hop-by-hop signaling for LSP Hierarchy and P2MP RSVP-TE.
The discussions about the various keying methods in this document are also applicable when using IPsec [RFC4301] to protect RSVP. [RFC2747] states in section 1.2 that IPsec is not an optimal choice to protect RSVP. The key argument is that an IPsec SA and an RSVP SA are not based on the same parameters. Nevertheless, IPsec can be used to protect RSVP. The SPD traffic selectors for related RSVP flows will not be constant. In some cases, the source and destination addresses are end hosts, and sometimes they are RSVP routers. Therefore, traffic selectors in the SPD are expected to specify ANY for the source address and destination addresses, and specify IP protocol 46 (RSVP).
The document "The Multicast Group Security Architecture" [RFC3740] defines in detail a "Group Security Association" (GSA). This definition is also applicable in the context discussed here, and allows the use of IPsec for RSVP. The existing GDOI standard [RFC3547] manages group security associations, which can be used by IPsec. An example GDOI policy would be to encrypt or authenticate all packets of the RSVP protocol itself (IP protocol 46). A router implementing GDOI and the AH and/or ESP protocols is therefore able to implement this policy.
Because the traffic selectors for an SA cannot be predicted, SA lookup is expected to use only the SPI (or SPI plus protocol).
The INTEGRITY object defined by [RFC2747] provides integrity protection for RSVP also in a group keying context, as discussed above. AH [RFC4302] is an alternative method to provide integrity protection for RSVP packets.
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) or extension headers (in IPv6).
AH tunnel mode (transport mode is not applicable, see section 6.4) protects the entire original IP packet, including the IP header of the original IP packet ("inner header"), IP options or extension headers, plus the entire RSVP packet. It also protects the immutable fields of the outer header.
The difference between the two schemes in terms of covered fields is therefore whether the IP header and IP options or extension headers of the original IP packet are protected (as is the case with AH) or not (as is the case with the INTEGRITY object). Also, AH covers the immutable fields of the outer header.
As described in the next section, IPsec tunnel mode can not be applied for RSVP traffic in the presence of non-RSVP nodes; therefore the security associations in both cases, AH and INTEGRITY object, are between the same RSVP neighbors. From a keying point of view both approaches are therefore comparable.
IPsec tunnel mode encapsulates the original packet, prepending a new 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, outer IP header however is not cryptographically secured in this process.
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 (however, see group keying considerations below). 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 cannot be applied, 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 independent of the key type used.
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 packet has consequences. In particular, if a man-in-the-middle attacker re-directs the ESP-protected reservation to a different security gateway, the receiving security gateway cannot detect that the destination address was changed. However, it has received and will act upon or route a RSVP reservation that will be be routed along an unintended path. Because RSVP routers encountering the RSVP 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 path and unintended path will both be incorrect. Therefore group keying is recommended not be used with ESP tunnel mode except with address preservation (see Section 6.5).
IPsec transport mode, as defined in [RFC4303] is not suitable for securing RSVP Path messages, since those messages preserve the original source and destination. [RFC4303] states explicitly that "the use of transport mode by an intermediate system (e.g., a security gateway) is permitted only when applied to packets whose source address (for outbound packets) or destination address (for inbound packets) is an address belonging to the intermediate system itself." This would not be the case for RSVP Path messages.
When the identity of the next-hop RSVP peer is not known, it is not possible to use a tunnel-endpoint destination address in the Tunnel Mode outer IP header. The document "Multicast Extensions to the Security Architecture for the Internet Protocol" [RFC5374] defines in section 3.1 a new tunnel mode: Tunnel mode with address preservation. This mode copies the destination and optionally the source address from the inner header to the outer header. Therefore the encapsulated packet will have the same destination address as the original packet, and be normally subject to the same routing decisions. While [RFC5374] is focusing on multicast environments, tunnel mode with address preservation can be used also to protect unicast traffic in conjunction with group keying. In this tunnel mode the RSVP speakers act as security gateways, because they maintain the original end system addresses of the RSVP packets in the outer tunnel mode IP header. This addressing scheme is used by RSVP to ensure that the packets continue along the routed path toward the destination end host.
Tunnel mode with address preservation, in conjunction with group 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 allows routing of the IPsec protected packet through the non-RSVP nodes in the same way as if it was not IPsec protected.
When used with group keying, tunnel mode with address preservation 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 mode packet. The inbound processing rules for tunnel mode with address preservation (Section 5.2 of [RFC5374]) require that the receiver verify that the addresses in the outer IP header and the inner IP header are consistent. Therefore, the attack can be detected and RSVP reservations will not proceed along an unintended path.
Unless RSVP Proxy entities ([RFC5945] are used, RSVP signaling is controlled by end systems and not routers. As discussed in [RFC4230], RSVP allows both user-based security and host-based security. User-based authentication aims at "providing policy based admission control mechanism based on user identities or application." To identify the user or the application, a policy element called AUTH_DATA, which is contained in the POLICY_DATA object, is created by the RSVP daemon at the user's host and transmitted inside the RSVP message. This way, a user may authenticate to the Policy Decision Point (or directly to the first hop router). Host-based security relies on the same mechanisms as between routers (i.e., the INTEGRITY object) as specified in [RFC2747]. For host-based security, per interface or per neighbor keys may be used, however, key management with statically provisioned keys can be difficult in a large scale deployment, as described in section 4. In principle an end host can also be part of a group key scheme, such as GDOI. If the end systems are part of the same security domain as the network itself, group keying can be extended to include the end systems. If the end systems and the network are in different zones of trust, group keying cannot be used.
While, so far, this document discusses only RSVP security assuming the traditional RSVP model as defined by [RFC2205] and [RFC2747], the analysis is also applicable to other RSVP deployment models as well as to similar protocols:
The following table summarizes the various approaches for RSVP keying, and their applicability to various RSVP scenarios. In particular, such keying can be used for RSVP authentication (e.g., using the RSVP INTEGRITY object or AH) and/ or for RSVP encryption (e.g., using ESP in tunnel mode).
| per neighbor/per interface keys | Group keys | |
|---|---|---|
| Works intra-domain | Yes | Yes |
| Works inter-domain | Yes | No |
| Works over non-RSVP hops | No | Yes (1) |
| Dynamic keying | Yes (IKE) | Yes (e.g., GDOI) |
Table 1: Overview of keying approaches and their applicability
(1): RSVP integrity with group keys works over non-RSVP nodes; RSVP encryption with ESP and RSVP authentication with AH work over non-RSVP nodes in 'Tunnel Mode with Address Preservation'; RSVP encryption with ESP & RSVP authentication with AH do not work over non-RSVP nodes in 'Tunnel Mode'.
We also make the following observations:
This entire document discusses RSVP security; this section describes a specific security considerations relating to subverted RSVP nodes.
A subverted node is defined here as an untrusted node, for example because an intruder has gained control over it. Since RSVP authentication is hop-by-hop and not end-to-end, a subverted node in the path breaks the chain of trust. This is to a large extent independent of the type of keying used.
For interface or per neighbor keying, the subverted node can now introduce fake messages to its neighbors. This can be used in a variety of ways, for example by changing the receiver address in the Path message, or by generating fake Path messages. This allows path states to be created on every RSVP router along any arbitrary path through the RSVP domain. That in itself could result in a form of Denial of Service by allowing exhaustion of some router resources (e.g. memory). The subverted node could also generate fake Resv messages upstream corresponding to valid Path states. In doing so, the subverted node can reserve excessive amounts of bandwidth thereby possibly performing a denial of service attack.
Group keying allows the additional abuse of sending fake RSVP messages to any node in the RSVP domain, not just adjacent RSVP nodes. However, in practice this can be achieved to a large extent also with per neighbor or interface keys, as discussed above. Therefore the impact of subverted nodes on the path is comparable for all keying schemes discussed here (per interface, per neighbor, group keys).
The authors would like to thank everybody who provided feedback on this document. Specific thanks to Bob Briscoe, Hannes Tschofenig, Ran Atkinson, Stephen Kent, and Kenneth G. Carlberg.
There are no IANA considerations within this document. This section can be removed if this document is published as an RFC.