draft-ietf-tsvwg-rsvp-security-groupkeying-00.txt   draft-ietf-tsvwg-rsvp-security-groupkeying-01.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: August 21, 2008 February 18, 2008 Expires: January 12, 2009 July 11, 2008
Applicability of Keying Methods for RSVP Security Applicability of Keying Methods for RSVP Security
draft-ietf-tsvwg-rsvp-security-groupkeying-00.txt draft-ietf-tsvwg-rsvp-security-groupkeying-01.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 August 21, 2008. This Internet-Draft will expire on January 12, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
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. Draft-weis-gdoi-for-rsvp provides an example of these approaches. For example, the Group Domain of Interpretation
how the Group Domain of Interpretation (GDOI) could be used to (GDOI) could be used to distribute group keys to RSVP nodes. The
distribute group keys to RSVP nodes. The present document also present document also discusses applicability of group keying to RSVP
discusses applicability of group keying to RSVP encryption. encryption.
Table of Contents Table of Contents
1. Introduction and Problem Statement . . . . . . . . . . . . . . 3 1. Introduction and Problem Statement . . . . . . . . . . . . . . 3
2. The RSVP Trust Model . . . . . . . . . . . . . . . . . . . . . 3 2. The RSVP Hop-by-Hop Trust Model . . . . . . . . . . . . . . . 3
3. Key types for RSVP . . . . . . . . . . . . . . . . . . . . . . 4 3. Applicability of Key Types for RSVP . . . . . . . . . . . . . 5
3.1. Interface based keys . . . . . . . . . . . . . . . . . . . 4 3.1. Interface and neighbor based keys . . . . . . . . . . . . 5
3.2. Neighbor based keys . . . . . . . . . . . . . . . . . . . 5 3.2. Group keys . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Group keys . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Key Provisioning Methods for RSVP . . . . . . . . . . . . . . 7
4. Key Provisioning Methods for RSVP . . . . . . . . . . . . . . 5 4.1. Static Key Provisioning . . . . . . . . . . . . . . . . . 7
4.1. Static Key Provisioning . . . . . . . . . . . . . . . . . 5 4.2. Dynamic Keying . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Per Neighbor Key Negotiation . . . . . . . . . . . . . . . 6 4.2.1. Neighbor and Interface Based Key Negotiation . . . . . 8
4.3. Dynamic Group Key Distribution . . . . . . . . . . . . . . 6 4.2.2. Dynamic Group Key Distribution . . . . . . . . . . . . 8
5. Applicability of Various Keying Methods for RSVP . . . . . . . 6 5. Specific Cases . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Per Neighbor or Per Interface Keys for Authentication . . 6 5.1. RSVP Notify Messages . . . . . . . . . . . . . . . . . . . 8
5.2. Group Keys for Authentication . . . . . . . . . . . . . . 6 5.2. RSVP-TE . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.3. Non-RSVP Hops . . . . . . . . . . . . . . . . . . . . . . 7 6. Applicability of IPsec for RSVP . . . . . . . . . . . . . . . 9
5.4. Subverted RSVP Nodes . . . . . . . . . . . . . . . . . . . 8 6.1. Applicability of IPsec ESP . . . . . . . . . . . . . . . . 10
5.5. RSVP Encryption . . . . . . . . . . . . . . . . . . . . . 9 6.2. Applicability of Tunnel Mode . . . . . . . . . . . . . . . 10
5.6. RSVP Notify Messages . . . . . . . . . . . . . . . . . . . 9 6.3. Applicability of Transport Mode . . . . . . . . . . . . . 11
6. End Host Considerations . . . . . . . . . . . . . . . . . . . 10 7. End Host Considerations . . . . . . . . . . . . . . . . . . . 11
7. Applicability to Other Architectures and Protocols . . . . . . 10 8. Applicability to Other Architectures and Protocols . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13
10. Changes to Previous Version . . . . . . . . . . . . . . . . . 11 10.1. Subverted RSVP Nodes . . . . . . . . . . . . . . . . . . . 13
10.1. changes from behringer-00 to behringer-01 . . . . . . . . 11 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
10.2. changes from behringer-01 to ietf-00 . . . . . . . . . . . 12 12. Changes to Previous Version . . . . . . . . . . . . . . . . . 14
11. Informative References . . . . . . . . . . . . . . . . . . . . 12 12.1. changes from behringer-00 to behringer-01 . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 12.2. changes from behringer-01 to ietf-00 . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 14 12.3. changes from ietf-00 to ietf-01 . . . . . . . . . . . . . 15
13. Informative References . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 18
1. Introduction and Problem Statement 1. Introduction and Problem Statement
The Resource reSerVation Protocol [RFC2205] allows hop-by-hop The Resource reSerVation Protocol [RFC2205] allows hop-by-hop
authentication of RSVP neighbors, as specified in [RFC2747]. In this authentication of RSVP neighbors, as specified in [RFC2747]. In this
mode, an integrity object is attached to each RSVP message to mode, an integrity object is attached to each RSVP message to
transmit a keyed message digest. This message digest allows the transmit a keyed message digest. This message digest allows the
recipient to verify the 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
also offers replay protection. also offers replay protection.
[RFC2747] does not dictate how the key for the integrity operation is [RFC2747] does not dictate how the key for the integrity operation is
derived. Currently, most implementations of RSVP use a statically derived. Currently, most implementations of RSVP use a statically
configured key, per interface or per neighbor. However, to manually configured key, per interface or per neighbor. However, to manually
configure 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 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-for-rsvp] provides an example of how group keys could [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, be dynamically distributed to a set of RSVP routers and updated,
using GDOI ([RFC3547]) for the actual key distribution. 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 mandate any particular
method, but is meant as a comparative guideline to understand where method, but is meant as a comparative guideline to understand where
each RSVP keying method is best deployed, and its limitations. 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 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 explicitely 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-for-rsvp]). The trust model is the same as for in [I-D.weis-gdoi-mac-tek]).
RSVP authentication. This is described in more detail in the section
"Using GDOI For RSVP Encryption" in section 5.5.
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. Explicitely 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. Implicitely each node trusts each other node with
which it has a trust relationship established via the mechanisms here which it has a trust relationship established via the mechanisms here
to adhere to the protocol specifications laid out by the various to 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 explicitely as well as implicitely all the other members of
the group. the 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 to work can then process the RSVP message. For RSVP authentication or
in this case, the key used for computing the RSVP message digest encryption to work in this case, the key used for computing the RSVP
needs to be shared by the two RSVP neighbors, even if they are not IP message digest needs to be shared by the two RSVP neighbors, even if
neighbors. However, in the presence of non-RSVP hops, while an RSVP they are not IP neighbors. However, in the presence of non-RSVP
node always know the next IP hop before forwarding an RSVP Message, hops, while an RSVP node always know the next IP hop before
it does not always know the RSVP next hop. Thus, the presence of forwarding an RSVP Message, it does not always know the RSVP next
non-RSVP hops impacts operation of RSVP authentication and may hop. In fact, part of the role of a Path message is precisely to
influence the keying approaches. This is further discussed in discover the RSVP next hop (and to dynamically re-discover it when it
Section 5.3. 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.
3. Key types for RSVP 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.
3.1. Interface based keys ----R3---
/ \
sender----R1---R2(*) R4----receiver
\ /
----R5---
(*) Non-RSVP hop
Figure 1: A non-RSVP Node in the path
This creates a challenge for RSVP authentication and encrpytion. 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 addresed 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.
By contrast, 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 sign a Path message addressed to the
receiver and forwards it to R2. Being a non-RSVP node, R2 and 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 it successfully with the group key.
3. Applicability of Key Types for RSVP
3.1. Interface and neighbor based keys
Most current RSVP authentication implementations support interface Most current RSVP authentication implementations support interface
based RSVP keys. When the interface is point-to-point (and therefore based RSVP keys. When the interface is point-to-point (and therefore
an RSVP router only has a single RSVP neighbor on each interface), an RSVP router only has a single RSVP neighbor on each interface),
this is similar to neighbor based keys in the sense that a different this is equivalent to neighbor based keys in the sense that a
key is used for each neighbor. However, when the interface is different key is used for each neighbor. However, when the interface
multipoint, all RSVP speakers on a given subnet have to share the is multipoint, all RSVP speakers on a given subnet have to share the
same key in this model, which makes it unsuitable for deployment same key in this model, which makes it unsuitable for deployment
scenarios where different trust groups share a subnet, for example scenarios where different trust groups share a subnet, for example
Internet exchange points. In such a case, neighbor based keys are Internet exchange points. In such a case, neighbor based keys are
required. required.
3.2. Neighbor based keys With neighbor based keys, an RSVP key is bound to an interface plus a
neighbor on that interface. It allows the distinction of different
In this model, an RSVP key is bound to an interface plus a neighbor trust groups on a single subnet. (Assuming that layer-2 security is
on that interface. It allows the distinction of different trust
groups on a single subnet. (Assuming that layer-2 security is
correctly implemented to prevent layer-2 attacks.) correctly implemented to prevent layer-2 attacks.)
3.3. Group keys
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
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 withn the group).
4. Key Provisioning Methods for RSVP
4.1. Static Key Provisioning
The simplest way to implement RSVP authentication is to use static,
preconfigured keys. Static keying can be used with interface based
keys, neighbor based keys or group keys.
However, such static key provisioning is expensive on the operational
side, since no secure automated mechanism can be used, and initial
provisioning as well as key updates require configuration. This
method is therefore mostly useful for small deployments, where key
changes can be carried out manually, or for deployments with
automated configuration tools which support key changes.
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, manually configured keys may be applicable to inter-domain RSVP
authentication.
Since it is not practical to carry out the key change at the exact
same time on both sides, 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.
4.2. Per Neighbor Key Negotiation
To avoid the problem of manual key provisioning and updates in static
key deployments, key negotiation between RSVP neighbors could be
used. Key negotiation could be used to derive either interface or
neighbor based keys. However, existing key negotiation protocols
such as IKEv1[RFC2409] or IKEv2 [RFC4306] may not be appropriate in
all environments because of the relative complexity of the protocols
and related operations.
4.3. Dynamic Group Key Distribution
With this approach, group keys are dyanmically distributed among a
set of RSVP routers. For example, [I-D.weis-gdoi-for-rsvp] 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 entire group.
5. Applicability of Various Keying Methods for RSVP
5.1. Per Neighbor or Per Interface Keys for Authentication
Per interface and per neighbor keys can be used within a single Per interface and per neighbor keys can be used within a single
security domain. As mentioned above, per interface keys are only security domain. As mentioned above, per interface keys are only
applicable when all the hosts reachable on the specific interface applicable when all the nodes reachable on the specific interface
belong to the same security domain. belong to the same security domain.
These key types can also be used between security domains, since they These key types can also be used between security domains, since they
are specific to a particular interface or neighbor. Again, interface are specific to a particular interface or neighbor. Again, interface
level keys can only be deployed safely when all the reachable level keys can only be deployed safely when all the reachable
neighbors on the interface belong to the same security domain. neighbors on the interface belong to the same security domain.
As discussed in Section 5.3, per neighbor and per interface keys can As discussed in the previous section, per neighbor and per interface
not be used in the presence of non-RSVP hops. keys can not be used in the presence of non-RSVP hops.
5.2. Group Keys for Authentication 3.2. Group keys
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
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, 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 implicitely 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 1. Figure 2.
......GKS1............. ......GKS1.............
: : : : : : : : : :
: : : : : : : : : :
source--R1--R2--R3-----destination source--R1--R2--R3-----destination
| | | |
|<-----domain 1----------------->| |<-----domain 1----------------->|
Figure 1: Group Key Server within a single security domain Figure 2: Group Key Server within a single security domain
A single group key cannot normally be used to cover multiple security A single group key cannot normally be used to cover multiple security
domains however, because by definition the different domains do not domains however, because by definition the different domains do not
trust each other and would not be willing to trust the same group key trust each other and would not be willing to trust the same group key
server. For a single group key to be used in several security 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 domains, there is a need for a single group key server, which is
trusted by both sides. While this is theoretically possible, in trusted by both sides. While this is theoretically possible, in
practice it is unlikely that there is a single such entity trusted by practice it is unlikely that there is a single such entity trusted by
both domains. Figure 2 illustrates this setup. both domains. Figure 3 illustrates this setup.
...............GKS1.................... ...............GKS1....................
: : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : :
source--R1--R2--R3--------R4--R5--R6--destination source--R1--R2--R3--------R4--R5--R6--destination
| | | | | | | |
|<-----domain 1--->| |<-------domain 2----->| |<-----domain 1--->| |<-------domain 2----->|
Figure 2: A Single Group Key Server across security domains Figure 3: A Single Group Key Server across security domains
A more practical approach for RSVP operation across security domains, A more practical approach for RSVP operation across security domains,
is to use a separate group key server for each security domain, and is to use a separate group key server for each security domain, and
to use per interface or per peer authentication between the two to use per interface or per neighbor authentication between the two
domains. Figure 3 shows this set-up. domains. Figure 4 shows this set-up.
....GKS1...... ....GKS2......... ....GKS1...... ....GKS2.........
: : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : :
source--R1--R2--R3--------R4--R5--R6--destination source--R1--R2--R3--------R4--R5--R6--destination
| | | | | | | |
|<-----domain 1--->| |<-------domain 2----->| |<-----domain 1--->| |<-------domain 2----->|
Figure 3: A group Key Server per security domain Figure 4: A group Key Server per security domain
5.3. Non-RSVP Hops
In the presence of a non-RSVP router in the path from the sender to As discussed in section 2, group keying can be used in the presence
the receiver, regular RSVP keeps working. The non-RSVP node ignores of non-RSVP hops.
the RSVP message, and passes it on transparently to the next node.
Figure 4 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--- 4. Key Provisioning Methods for RSVP
/ \
sender----R1---R2(*) R4----receiver
\ /
----R5---
(*) Non-RSVP hop
Figure 4: A non-RSVP Node in the path 4.1. Static Key Provisioning
However, this creates an additional challenge for RSVP The simplest way to implement RSVP authentication is to use static,
authentication. In the presence of a non-RSVP hop, with some RSVP preconfigured keys. Static keying can be used with interface based
messages such as a Path message, an RSVP router does not know the keys, neighbor based keys or group keys.
RSVP next hop for that message at the time of forwarding it. 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, say
because of a routing change). For example, in Figure 4, R1 knows
that the next IP hop for a Path message addresed 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 However, such static key provisioning is expensive on the operational
used in the presence of non-RSVP routers on the path between senders side, since no secure automated mechanism can be used, and initial
and receivers. provisioning as well as key updates require configuration. This
method is therefore mostly useful for small deployments, where key
changes can be carried out manually, or for deployments with
automated configuration tools which support key changes.
By contrast, group keying will naturally work in the presence of non- Static key provisioning is therefore not an ideal model in a large
RSVP routers. Referring back to Figure 4, with group keying, R1 network.
would use the group key to sign a Path message addressed to the
receiver and forwards it to R2. Being a non-RSVP node, R2 and 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 it successfully with the group key.
5.4. Subverted RSVP Nodes 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, manually configured keys may be applicable to inter-domain RSVP
authentication.
A subverted node is defined here as an untrusted node, for example Since it is not feasible to carry out the key change at the exact
because an intruder has gained control over it. Since RSVP same time on both sides, some grace period needs to be implemented
authentication is hop-by-hop and not end-to-end, a subverted node in during which an RSVP node will accept both the old and the new key.
the path breaks the chain of trust. This is to a large extent Otherwise, RSVP operation would suffer interruptions. (Note that
independent of the type of keying used. 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.)
For interface or per-neighbor keying, the subverted node can now 4.2. Dynamic Keying
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 4.2.1. Neighbor and Interface Based Key Negotiation
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,
independently whether per-interface, per-neighbor or group keys are
used.
5.5. RSVP Encryption 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 interface or neighbor based keys. However, existing
key negotiation protocols such as IKEv1 [RFC2409] or IKEv2 [RFC4306]
may not be appropriate in all environments because of the relative
complexity of the protocols and related operations.
The keying material can also be used to encrypt the RSVP messages 4.2.2. Dynamic Group Key Distribution
using IPsec [RFC2401], instead of, or in addition to authenticating
them. The same considerations apply for this case as discussed above
for the authentication case. Group keys are applicable only within a
trusted domain, but they allow operation through non-RSVP speakers
without further configuration. Per interface or per neighbor keys
work also inter-domain, but do not operate in the presence of a non-
RSVP router.
The existing GDOI standard as described in [RFC3547] contains all With this approach, group keys are dyanmically distributed among a
relevant policy options to allow for RSVP encryption, and no set of RSVP routers. For example, [I-D.weis-gdoi-mac-tek] describes
extensions are necessary. An example GDOI policy would be to encrypt a mechanism to distribute group keys to a group of RSVP speakers,
all packets of the RSVP protocol itself (IP protocol 46). A router using GDOI [RFC3547]. In this solution, a key server authenticates
implementing GDOI is therefore automatically able to encrypt RSVP. each of the RSVP nodes independently, and then distributes a group
key to the entire group.
[Editor's note: Applicability of tunnel vs transport mode still needs 5. Specific Cases
to be discussed.]
5.6. RSVP Notify Messages 5.1. RSVP Notify Messages
[RFC3473] introduces the Notify message and allows such Notify [RFC3473] introduces the Notify message and allows such Notify
messages to be sent in a non-hop-by-hop fashion. As discussed in the messages to be sent in a non-hop-by-hop fashion. As discussed in the
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.
6. End Host Considerations 5.2. RSVP-TE
Use of RSVP authentication for RSVP-TE [RFC3209] and for RSVP-TE Fast
Reroute [RFC4090] deserve additional considerations. For example,
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) from 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 also exchange RSVP control message for the
maintenance the protected LSP over the backup tunnel. Therefore,
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 since the group key could also be easily used between
the PLR and the MP.
6. Applicability of IPsec for RSVP
The discussions about the various keying methods in this document are
applicable to the built-in authentication in the RSVP protocol, using
the INTEGRITY object, as defined in [RFC2747]. In principle, they
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
are not based on the same parameters. We believe that group keying
may solve some of the issues mentioned. [Editorial note: Detailed
discussion will be added in the next version of the document.]
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
The keying approaches discussed in this document can also be used to
encrypt the RSVP messages using IPsec [RFC4301], instead of, or in
addition to authenticating them. The same considerations apply for
this case as discussed above for the authentication case. Group keys
are applicable only within a trusted domain, but they allow operation
through non-RSVP speakers without further configuration. Per
interface or per neighbor keys work also inter-domain, but do not
operate in the presence of a non-RSVP router.
The existing GDOI standard as described in [RFC3547] contains all
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
header (in tunnel mode the outer header), there is an issue with
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
destination address with another RSVP router in the network. This
router will receive the packet, use the group key to decrypt the
encapsulated packet, and then act on the RSVP packet. This way an
attacker cannot create new reservations or affect existing ones, but
he can "re-direct" reservations to parts of the network off the
actual reservation path, thereby potentially denying resources to
other applications on that part of the network.
6.2. Applicability of Tunnel Mode
IPsec tunnel mode for ESP encapsulates and encypts the original
packet, prepending a new IP tunnel header plus an ESP sub-header.
The entire original packet is encrypted, and the integrity of the
original packet plus the ESP subheader is secured. The new, outer IP
header however is not cryptographically secured in this process.
Protecting RSVP packets with IPsec ESP 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,
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
independent of the key type used.
6.3. Applicability of Transport Mode
IPsec transport mode for ESP, as defined in [RFC4303] is not suitable
for securing RSVP Path messages, since those messages preserve the
original source and destination. [RFC4303] states explicitely 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.
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
POLICY_DATA object, is created by the RSVP daemon at the user's host 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 and transmitted inside the RSVP message. This way, a user may
skipping to change at page 10, line 28 skipping to change at page 11, line 41
between routers (i.e. INTEGRITY object ) as specified in [RFC2747]. between routers (i.e. INTEGRITY object ) as specified in [RFC2747].
For host-based security, interface or neighbor based keys may be For host-based security, interface or neighbor based keys may be
used, however, key management with pre-shared keys can be difficult used, however, key management with pre-shared keys can be difficult
in a large scale deployment, as described in section 4. In principle 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 an end host can also be part of a group key scheme, such as GDOI. If
the end systems are part of the same zone of trust as the network the end systems are part of the same zone of trust as the network
itself, group keying can be extended to include the end systems. If itself, group keying can be extended to include the end systems. If
the end systems and the network are in different zones of trust, the end systems and the network are in different zones of trust,
group keying cannot be used. group keying cannot be used.
7. Applicability to Other Architectures and Protocols 8. Applicability to Other Architectures and Protocols
While, so far, this document only discusses RSVP security assuming While, so far, this document only discusses RSVP security assuming
the traditional RSVP model as defined by [RFC2205] and [RFC2747], the the traditional RSVP model as defined by [RFC2205] and [RFC2747], the
analysis is also applicable to other RSVP deployment models as well analysis is also applicable to other RSVP deployment models as well
as to similar protocols: as to similar protocols:
o Aggregation of RSVP for IPv4 and IPv6 Reservations [RFC3175]: This o Aggregation of RSVP for IPv4 and IPv6 Reservations [RFC3175]: This
scheme defines aggregation of individual RSVP reservations, and scheme defines aggregation of individual RSVP reservations, and
discusses use of RSVP authentication for the signaling messages. discusses use of RSVP authentication for the signaling messages.
Group keying is applicable to this scheme, particularly when Group keying is applicable to this scheme, particularly when
skipping to change at page 11, line 24 skipping to change at page 12, line 40
document apply. In particular, group keying may facilitate document apply. In particular, group keying may facilitate
operations since the ingress PCN-boundary-node does not operations since the ingress PCN-boundary-node does not
necessarily know ahead of time which Egress PCN-boundary-node will necessarily know ahead of time which Egress PCN-boundary-node will
intercept and process the initial end-to-end Path message. Note intercept and process the initial end-to-end Path message. Note
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.
8. Security Considerations 9. Summary
This entire document discusses RSVP security. 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 and/ or
for RSVP Encryption (using ESP in Tunnel mode).
9. Acknowledgements +-----------------------------+--------------------+----------------+
| | Neighbor/interface | Group keys |
| | based keys | |
+-----------------------------+--------------------+----------------+
| Works intra-domain | Yes | Yes |
| Works inter-domain | Yes | No |
| Works over non-RSVP hops | No | Yes (1) |
| Dynamic keying | Yes (IKE) | Yes (eg GDOI) |
+-----------------------------+--------------------+----------------+
Table 1: Overview of keying approaches and their applicability
(1): RSVP authentication with group keys works over non-RSVP nodes;
RSVP encryption with IPsec ESP Tunnel mode does not.
We also make the following observations:
o All key types can be used statically, or with dynamic key
negotiation. This impacts the managability of the solution, but
not the applicability itself.
o For encryption of RSVP messages IPsec ESP in tunnel mode can be
used. There is however a security concern, see Section 6.1.
o There are some special cases in RSVP, like non-RSVP hosts, the
"notify" message, the various RSVP deployment models discussed in
Section 8 and MPLS traffic engineering, which would benefit from a
group keying approach.
10. Security Considerations
This entire document discusses RSVP security; this section describes
a specific security considerations relating to subverted RSVP nodes
10.1. 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,
independently whether per-interface, per-neighbor or group keys are
used.
11. Acknowledgements
The authors would like to thank everybody who provided feedback on The authors would like to thank everybody who provided feedback on
this document. Specific thanks to Bob Briscoe, Hannes Tschofenig and this document. Specific thanks to Bob Briscoe, Hannes Tschofenig and
Brian Weis. Brian Weis.
10. Changes to Previous Version 12. Changes to Previous Version
The following changes were made in version 01: This section provides a change log. It will be removed in the final
document:
10.1. changes from behringer-00 to behringer-01 12.1. changes from behringer-00 to behringer-01
o New section "Applicability to Other Architectures and Protocols": o New section "Applicability to Other Architectures and Protocols":
Goal is to clarify the scope of this document: The idea presented Goal is to clarify the scope of this document: The idea presented
here is also applicable to other architectures here is also applicable to other architectures
(PCN[I-D.ietf-pcn-architecture], RFC3175 and RFC4860, etc. (PCN[I-D.ietf-pcn-architecture], RFC3175 and RFC4860, etc.
o Clarified the scope of this document versus RFC4230 (in the o Clarified the scope of this document versus RFC4230 (in the
introduction, last paragraph). introduction, last paragraph).
o Added a section on "End Host Considerations". o Added a section on "End Host Considerations".
o Expanded section 5.5 (RSVP Encryption) to clarify that GDOI o Expanded section 5.5 (RSVP Encryption) to clarify that GDOI
contains all necessary mechanisms to do RSVP encrpytion. contains all necessary mechanisms to do RSVP encrpytion.
skipping to change at page 12, line 4 skipping to change at page 14, line 39
o New section "Applicability to Other Architectures and Protocols": o New section "Applicability to Other Architectures and Protocols":
Goal is to clarify the scope of this document: The idea presented Goal is to clarify the scope of this document: The idea presented
here is also applicable to other architectures here is also applicable to other architectures
(PCN[I-D.ietf-pcn-architecture], RFC3175 and RFC4860, etc. (PCN[I-D.ietf-pcn-architecture], RFC3175 and RFC4860, etc.
o Clarified the scope of this document versus RFC4230 (in the o Clarified the scope of this document versus RFC4230 (in the
introduction, last paragraph). introduction, last paragraph).
o Added a section on "End Host Considerations". o Added a section on "End Host Considerations".
o Expanded section 5.5 (RSVP Encryption) to clarify that GDOI o Expanded section 5.5 (RSVP Encryption) to clarify that GDOI
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.
10.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 necessraily the recommended solution and not necesarily the recommended solution
11. Informative References 12.3. changes from ietf-00 to ietf-01
o Significant re-structuring of the entire document, to improve the
flow, and provide more consistency in various sections.
o Moved the "Subverted RSVP nodes" discussion into the security
considerations section.
o Added a "summary" section.
o Complete re-write of the old section 5.5 (RSVP encryption), and
"promotion" to a separate section.
o Changed reference ID.weis-gdoi-for-rsvp to the new draft ID.weis-
gdoi-mac-tek
o in several places, explicitely mentioned "encryption" for RSVP (in
parallel to authentication).
o Various minor edits.
13. Informative References
[I-D.ietf-pcn-architecture] [I-D.ietf-pcn-architecture]
Eardley, P., "Pre-Congestion Notification Architecture", Eardley, P., "Pre-Congestion Notification Architecture",
October 2007. draft-ietf-pcn-architecture-03 (work in progress),
February 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-03 (work in draft-ietf-tsvwg-rsvp-proxy-approaches-04 (work in
progress), December 2007. progress), April 2008.
[I-D.weis-gdoi-for-rsvp] [I-D.weis-gdoi-mac-tek]
Weis, B., "Group Domain of Interpretation (GDOI) support Weis, B. and S. Rowles, "GDOI Generic Message
for RSVP", July 2007. Authentication Code Policy", draft-weis-gdoi-mac-tek-00
(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.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998. (IKE)", RFC 2409, November 1998.
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic
Authentication", RFC 2747, January 2000. Authentication", RFC 2747, January 2000.
[RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie,
"Aggregation of RSVP for IPv4 and IPv6 Reservations", "Aggregation of RSVP for IPv4 and IPv6 Reservations",
RFC 3175, September 2001. RFC 3175, September 2001.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic (GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The [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.
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
May 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)",
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.
skipping to change at page 14, line 44 skipping to change at line 776
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 60 change blocks. 
234 lines changed or deleted 374 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/