One document matched: draft-ietf-tsvwg-rsvp-security-groupkeying-10.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- edited by Michael Behringer -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2205 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2205.xml">
<!ENTITY rfc2747 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2747.xml">
<!ENTITY rfc3175 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3175.xml">
<!ENTITY rfc3209 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3209.xml">
<!ENTITY rfc3473 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3473.xml">
<!ENTITY rfc3547 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3547.xml">
<!ENTITY rfc3740 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3740.xml">
<!ENTITY rfc4206 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4206.xml">
<!ENTITY rfc4216 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4216.xml">
<!ENTITY rfc4230 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4230.xml">
<!ENTITY rfc4090 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4090.xml">
<!ENTITY rfc4301 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4301.xml">
<!ENTITY rfc4302 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4302.xml">
<!ENTITY rfc4303 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4303.xml">
<!ENTITY rfc4804 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4804.xml">
<!ENTITY rfc4860 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4860.xml">
<!ENTITY rfc4875 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4875.xml">
<!ENTITY rfc5374 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5374.xml">
<!ENTITY rfc5559 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5559.xml">
<!ENTITY rfc5945 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5945.xml">
<!ENTITY I-D.weis-gdoi-mac-tek SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.weis-gdoi-mac-tek.xml">
]>
<rfc category="info"
docName="draft-ietf-tsvwg-rsvp-security-groupkeying-10.txt"
ipr="trust200902">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc compact="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title abbrev="RSVP Keying Applicability">Applicability of Keying Methods
for RSVP Security</title>
<author fullname="Michael H. Behringer" initials="M." surname="Behringer">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>Village d'Entreprises Green Side</street>
<street>400, Avenue Roumanille, Batiment T 3</street>
<city>Biot - Sophia Antipolis</city>
<code>06410</code>
<country>France</country>
</postal>
<email>mbehring@cisco.com</email>
<uri>http://www.cisco.com</uri>
</address>
</author>
<author fullname="Francois Le Faucheur" initials="F."
surname="Le Faucheur">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>Village d'Entreprises Green Side</street>
<street>400, Avenue Roumanille, Batiment T 3</street>
<city>Biot - Sophia Antipolis</city>
<code>06410</code>
<country>France</country>
</postal>
<email>flefauch@cisco.com</email>
<uri>http://www.cisco.com</uri>
</address>
</author>
<author fullname="Brian Weis" initials="B" surname="Weis">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>170 W. Tasman Drive</street>
<city>San Jose, California</city>
<country>USA</country>
<code>95134-1706</code>
</postal>
<email>bew@cisco.com</email>
<uri>http://www.cisco.com</uri>
</address>
</author>
<date day="23" month="June" year="2011" />
<keyword>RSVP authentication</keyword>
<keyword>RSVP integrity</keyword>
<keyword>Resource reservation protocol</keyword>
<keyword>GDOI</keyword>
<keyword>Group domain of interpretation</keyword>
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<section title="Introduction and Problem Statement">
<t>The Resource reSerVation Protocol <xref target="RFC2205"></xref>
allows hop-by-hop authentication of RSVP neighbors, as specified in
<xref target="RFC2747"></xref>. 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.</t>
<t><xref target="RFC2747"></xref> 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.</t>
<t>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.</t>
<t>The document "RSVP Security Properties" (<xref
target="RFC4230"></xref>) provides an overview of RSVP security,
including RSVP Cryptographic Authentication <xref
target="RFC2747"></xref>, 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 <xref target="RFC4230"></xref>.</t>
<section title="Terminology">
<t> A security domain is defined in this document as a set of nodes
that shares a common RSVP security policy.</t>
</section>
</section>
<section title="The RSVP Hop-by-Hop Trust Model">
<t>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" <xref target="RFC4230"></xref> for more background.</t>
<t>The keys used for protecting RSVP messages can, in particular, be
group keys (for example distributed via GDOI <xref
target="RFC3547"></xref>, as discussed in <xref
target="I-D.weis-gdoi-mac-tek"></xref>). If a group key is used, the
authentication granularity becomes group membership of devices, not
(individual) peer authentication between devices.</t>
<t>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).</t>
<t>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.</t>
<t><xref target="non-rsvp-hop"></xref> 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.</t>
<figure anchor="non-rsvp-hop" title="A non-RSVP Node in the path">
<artwork><![CDATA[
----R3---
/ \
sender----R1---R2(*) R4----receiver
\ /
----R5---
(*) Non-RSVP hop
]]></artwork>
<postamble></postamble>
</figure>
<t>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 <xref
target="non-rsvp-hop"></xref>, 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. </t>
<t>Section 4.3 of <xref target="RFC2747"></xref> 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.</t>
<t>Group keying will naturally work in the presence of non-RSVP routers.
Referring back to <xref target="non-rsvp-hop"></xref>, 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.</t>
</section>
<section title="Applicability of Key Types for RSVP">
<section title="Per interface and per neighbor keys">
<t>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.</t>
<t>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.</t>
<t>Per interface and per neighbor keys can be used within a single
security domain.</t>
<t>These key types can also be used between security domains, since
they are specific to a particular interface or neighbor. </t>
<t>Both monotonically increasing sequence number (e.g., the INTEGRITY
object simple sequence numbers <xref target="RFC2747"></xref>, or the
ESP and AH anti-replay service <xref target="RFC4301"></xref> sequence
numbers) and time based anti-replay methods (e.g., the INTEGRITY
sequence numbers based on a clock <xref target="RFC2747"></xref>) can
be used with per neighbor and per interface keys.</t>
<t>As discussed in the previous section, per neighbor and per
interface keys can not be used in the presence of non-RSVP hops.</t>
</section>
<section title="Group keys">
<t>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).</t>
<t>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 <xref
target="intra-single"></xref>.</t>
<figure anchor="intra-single"
title="Group Key Server within a single security domain">
<artwork><![CDATA[
......GKS1.............
: : : : :
: : : : :
source--R1--R2--R3-----destination
| |
|<-----domain 1----------------->|
]]></artwork>
<postamble></postamble>
</figure>
<t>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. <xref target="inter-single"></xref> illustrates this
setup.</t>
<figure anchor="inter-single"
title="A Single Group Key Server across security domains">
<artwork><![CDATA[
...............GKS1....................
: : : : : : : :
: : : : : : : :
source--R1--R2--R3--------R4--R5--R6--destination
| | | |
|<-----domain 1--->| |<-------domain 2----->|
]]></artwork>
<postamble></postamble>
</figure>
<t>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. <xref target="inter-multiple"></xref> shows this setup.</t>
<figure anchor="inter-multiple"
title="A group Key Server per security domain">
<artwork><![CDATA[
....GKS1...... ....GKS2.........
: : : : : : : :
: : : : : : : :
source--R1--R2--R3--------R4--R5--R6--destination
| | | |
|<-----domain 1--->| |<-------domain 2----->|
]]></artwork>
</figure>
<t>As discussed in Section 2, group keying can be used in the presence
of non-RSVP hops.</t>
<t>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 <xref target="RFC2747"></xref>) can
be used with group keys.</t>
</section>
</section>
<section title="Key Provisioning Methods for RSVP">
<section title="Static Key Provisioning">
<t>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.</t>
<t>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.</t>
<t>Static key provisioning is therefore not an ideal model in a large
network.</t>
<t>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.</t>
<t>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.)</t>
</section>
<section title="Dynamic Keying">
<section title="Per Neighbor and Per Interface Key Negotiation">
<t>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.</t>
</section>
<section title="Dynamic Group Key Distribution">
<t>With this approach, group keys are dynamically distributed among
a set of RSVP routers. For example, <xref
target="I-D.weis-gdoi-mac-tek"></xref> describes a mechanism to
distribute group keys to a group of RSVP speakers, using GDOI <xref
target="RFC3547"></xref>. 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.</t>
</section>
</section>
</section>
<section title="Specific Cases Supporting Use of Group Keying">
<section title="RSVP Notify Messages">
<t><xref target="RFC3473"></xref> 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 <xref
target="RFC3473"></xref>, this can interfere with RSVP's hop-by-hop
integrity and authentication model. <xref target="RFC3473"></xref>
describes how standard IPsec based integrity and authentication can be
used to protect Notify messages. </t>
<t>Group keying may allow use of regular RSVP authentication (<xref
target="RFC2747"></xref>) 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.</t>
</section>
<section title="RSVP-TE and GMPLS">
<t>Use of RSVP authentication for RSVP-TE <xref
target="RFC3209"></xref> and for RSVP-TE Fast Reroute <xref
target="RFC4090"></xref> deserves additional considerations.</t>
<t>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 <xref target="RFC4090"></xref> 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.</t>
<t>Where RSVP-TE or RSVP-TE Fast Reroute is deployed across AS
boundaries (see <xref target="RFC4216"></xref>), 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).</t>
<t><xref target="RFC4875"></xref> 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 <xref target="RFC4875"></xref> Security
Considerations) . </t>
<t><xref target="RFC4206"></xref> 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 <xref target="RFC3473"></xref> and
<xref target="RFC4206"></xref> 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.</t>
</section>
</section>
<section title="Applicability of IPsec for RSVP">
<section title="General Considerations Using IPsec">
<t>The discussions about the various keying methods in this document
are also applicable when using IPsec <xref target="RFC4301"></xref> to
protect RSVP. <xref target="RFC2747"></xref> 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).</t>
<t>The document "The Multicast Group Security Architecture" <xref
target="RFC3740"></xref> 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 <xref target="RFC3547"></xref> 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.</t>
<t>Because the traffic selectors for an SA cannot be predicted, SA
lookup is expected to use only the SPI (or SPI plus protocol).</t>
</section>
<section title="Comparing AH and the INTEGRITY Object">
<t>The INTEGRITY object defined by <xref target="RFC2747"></xref>
provides integrity protection for RSVP also in a group keying context,
as discussed above. AH <xref target="RFC4302"></xref> is an
alternative method to provide integrity protection for RSVP
packets.</t>
<t>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).</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="Applicability of Tunnel Mode">
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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).</t>
</section>
<section title="Non-Applicability of Transport Mode">
<t>IPsec transport mode, as defined in <xref target="RFC4303"></xref>
is not suitable for securing RSVP Path messages, since those messages
preserve the original source and destination. <xref
target="RFC4303"></xref> 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.</t>
</section>
<section title="Applicability of Tunnel Mode with Address Preservation">
<t>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" <xref
target="RFC5374"></xref> 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 <xref target="RFC5374"></xref> 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.</t>
<t>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.</t>
<t>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 <xref target="RFC5374"></xref>) 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.</t>
</section>
</section>
<section title="End Host Considerations">
<t>Unless RSVP Proxy entities (<xref target="RFC5945"></xref> are used,
RSVP signaling is controlled by end systems and not routers. As
discussed in <xref target="RFC4230"></xref>, 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 <xref target="RFC2747"></xref>. 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.</t>
</section>
<section title="Applicability to Other Architectures and Protocols">
<t>While, so far, this document discusses only RSVP security assuming
the traditional RSVP model as defined by <xref target="RFC2205"></xref>
and <xref target="RFC2747"></xref>, the analysis is also applicable to
other RSVP deployment models as well as to similar protocols:</t>
<t><list style="symbols">
<t>Aggregation of RSVP for IPv4 and IPv6 Reservations <xref
target="RFC3175"></xref>: This scheme defines aggregation of
individual RSVP reservations, and discusses use of RSVP
authentication for the signaling messages. Group keying is
applicable to this scheme, particularly when automatic Deaggregator
discovery is used, since in that case, the Aggregator does not know
ahead of time which Deaggregator will intercept the initial
end-to-end RSVP Path message.</t>
<t>Generic Aggregate Resource ReSerVation Protocol (RSVP)
Reservations <xref target="RFC4860"></xref>: This document also
discusses aggregation of individual RSVP reservations. Here again,
group keying applies and is mentioned in the Security Considerations
section.</t>
<t>Aggregation of Resource ReSerVation Protocol (RSVP) Reservations
over MPLS TE/DS-TE Tunnels <xref
target="RFC4804"></xref>([RFC4804]): This scheme also defines a form
of aggregation of RSVP reservation but this time over MPLS TE
Tunnels. Similarly, group keying may be used in such an
environment.</t>
<t>Pre-Congestion Notification (PCN): <xref target="RFC5559"></xref>
defines an architecture for flow admission and termination based on
aggregated pre-congestion information. One deployment model for this
architecture is based on IntServ over DiffServ: the DiffServ 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
process RSVP messages. In this scenario, RSVP authentication may be
required among PCN-boundary-nodes and the considerations about
keying approaches discussed earlier in this document apply. In
particular, group keying may facilitate operations since the ingress
PCN-boundary-node does not necessarily know ahead of time which
Egress PCN-boundary-node will intercept and process the initial
end-to-end Path message. From the viewpoint of securing end-to-end
RSVP, there are a lot of similarities in scenarios involving RSVP
Aggregation over aggregate RSVP reservations ([RFC3175], [RFC4860]),
RSVP Aggregation over MPLS-TE tunnels ([RFC4804]), and RSVP
(Aggregation) over PCN ingress-egress aggregates.</t>
</list></t>
</section>
<section title="Summary">
<t>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).</t>
<t></t>
<texttable>
<preamble></preamble>
<ttcol width="50%"></ttcol>
<ttcol align="center" width="25%">per neighbor/per interface
keys</ttcol>
<ttcol align="center" width="25%">Group keys</ttcol>
<c>Works intra-domain</c>
<c>Yes</c>
<c>Yes</c>
<c>Works inter-domain</c>
<c>Yes</c>
<c>No</c>
<c>Works over non-RSVP hops</c>
<c>No</c>
<c>Yes (1)</c>
<c>Dynamic keying</c>
<c>Yes (IKE)</c>
<c>Yes (e.g., GDOI)</c>
<postamble>Table 1: Overview of keying approaches and their
applicability</postamble>
</texttable>
<t>(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'.</t>
<t>We also make the following observations:</t>
<t><list style="symbols">
<t>All key types can be used statically, or with dynamic key
negotiation. This impacts the manageability of the solution, but not
the applicability itself.</t>
<t>For encryption of RSVP messages, IPsec ESP in tunnel mode can be
used.</t>
<t>There are some special cases in RSVP, like non-RSVP hosts, the
"Notify" message (as discussed in Section 5.1), the various RSVP
deployment models discussed in Section 8 and MPLS Traffic
Engineering and GMPLS discussed in section 5.2 , which would benefit
from a group keying approach.</t>
</list></t>
</section>
<section title="Security Considerations">
<t>This entire document discusses RSVP security; this section describes
a specific security considerations relating to subverted RSVP nodes.</t>
<section title="Subverted Nodes">
<t>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.</t>
<t>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.</t>
<t>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).</t>
</section>
</section>
<section title="Acknowledgements">
<t>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.</t>
</section>
<section title="IANA Considerations">
<t>There are no IANA considerations within this document. This section
can be removed if this document is published as an RFC.</t>
</section>
</middle>
<back>
<references title="Informative References">
&rfc2205;
&rfc2747;
&rfc3175;
&rfc3209;
&rfc3473;
&rfc3547;
&rfc3740;
&rfc4206;
&rfc4216;
&rfc4230;
&rfc4090;
&rfc4301;
&rfc4302;
&rfc4303;
&rfc4804;
&rfc4860;
&rfc4875;
&rfc5374;
&rfc5559;
&rfc5945;
&I-D.weis-gdoi-mac-tek;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 09:02:37 |