draft-ietf-tsvwg-rsvp-security-groupkeying-04.txt   draft-ietf-tsvwg-rsvp-security-groupkeying-05.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: September 25, 2009 March 24, 2009 Expires: December 6, 2009 June 4, 2009
Applicability of Keying Methods for RSVP Security Applicability of Keying Methods for RSVP Security
draft-ietf-tsvwg-rsvp-security-groupkeying-04.txt draft-ietf-tsvwg-rsvp-security-groupkeying-05.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and 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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 32 skipping to change at page 1, line 32
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 September 25, 2009. This Internet-Draft will expire on December 6, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 35 skipping to change at page 2, line 35
6. Applicability of IPsec for RSVP . . . . . . . . . . . . . . . 10 6. Applicability of IPsec for RSVP . . . . . . . . . . . . . . . 10
6.1. General Considerations Using IPsec . . . . . . . . . . . . 10 6.1. General Considerations Using IPsec . . . . . . . . . . . . 10
6.2. Using IPsec ESP . . . . . . . . . . . . . . . . . . . . . 10 6.2. Using IPsec ESP . . . . . . . . . . . . . . . . . . . . . 10
6.3. Using IPsec AH . . . . . . . . . . . . . . . . . . . . . . 11 6.3. Using IPsec AH . . . . . . . . . . . . . . . . . . . . . . 11
6.4. Applicability of Tunnel Mode . . . . . . . . . . . . . . . 11 6.4. Applicability of Tunnel Mode . . . . . . . . . . . . . . . 11
6.5. Applicability of Transport Mode . . . . . . . . . . . . . 12 6.5. Applicability of Transport Mode . . . . . . . . . . . . . 12
6.6. Applicability of Tunnel Mode with Address Preservation . . 12 6.6. Applicability of Tunnel Mode with Address Preservation . . 12
7. End Host Considerations . . . . . . . . . . . . . . . . . . . 12 7. End Host Considerations . . . . . . . . . . . . . . . . . . . 12
8. Applicability to Other Architectures and Protocols . . . . . . 13 8. Applicability to Other Architectures and Protocols . . . . . . 13
9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10.1. Subverted RSVP Nodes . . . . . . . . . . . . . . . . . . . 15 10.1. Subverted RSVP Nodes . . . . . . . . . . . . . . . . . . . 15
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
12. Changes to Previous Version . . . . . . . . . . . . . . . . . 15 12. Changes to Previous Version . . . . . . . . . . . . . . . . . 15
12.1. changes from behringer-00 to behringer-01 . . . . . . . . 15 12.1. changes from behringer-00 to behringer-01 . . . . . . . . 16
12.2. changes from behringer-01 to ietf-00 . . . . . . . . . . . 16 12.2. changes from behringer-01 to ietf-00 . . . . . . . . . . . 16
12.3. changes from ietf-00 to ietf-01 . . . . . . . . . . . . . 16 12.3. changes from ietf-00 to ietf-01 . . . . . . . . . . . . . 16
12.4. changes from ietf-01 to ietf-02 . . . . . . . . . . . . . 16 12.4. changes from ietf-01 to ietf-02 . . . . . . . . . . . . . 16
12.5. changes from ietf-02 to ietf-03 . . . . . . . . . . . . . 16 12.5. changes from ietf-02 to ietf-03 . . . . . . . . . . . . . 16
12.6. changes from ietf-03 to ietf-04 . . . . . . . . . . . . . 17 12.6. changes from ietf-03 to ietf-04 . . . . . . . . . . . . . 17
12.7. changes from ietf-04 to ietf-05 . . . . . . . . . . . . . 17
13. Informative References . . . . . . . . . . . . . . . . . . . . 17 13. Informative References . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction and Problem Statement 1. Introduction and Problem Statement
The Resource reSerVation Protocol [RFC2205] allows hop-by-hop The Resource reSerVation Protocol [RFC2205] allows hop-by-hop
authentication of RSVP neighbors, as specified in [RFC2747]. In this authentication of RSVP neighbors, as specified in [RFC2747]. In this
mode, an integrity object is attached to each RSVP message to mode, an integrity object is attached to each RSVP message to
transmit a keyed message digest. This message digest allows the transmit a keyed message digest. This message digest allows the
recipient to verify the authenticity of the RSVP node that sent the recipient to verify the authenticity of the RSVP node that sent the
skipping to change at page 4, line 20 skipping to change at page 4, line 20
The trust an RSVP node has to another RSVP node has an explicit and The trust an RSVP node has to another RSVP node has an explicit and
an implicit component. Explicitly the node trusts the other node to an implicit component. Explicitly the node trusts the other node to
maintain the RSVP messages intact or confidential, depending on maintain the RSVP messages intact or confidential, depending on
whether authentication or encryption (or both) is used. This means whether authentication or encryption (or both) is used. This means
only that the message has not been altered or seen by another, non- only that the message has not been altered or seen by another, non-
trusted node. Implicitly each node trusts each other node with which trusted node. Implicitly each node trusts each other node with which
it has a trust relationship established via the mechanisms here to it has a trust relationship established via the mechanisms here to
adhere to the protocol specifications laid out by the various adhere to the protocol specifications laid out by the various
standards. Note that in any group keying scheme like GDOI a node standards. Note that in any group keying scheme like GDOI a node
trusts explicitly as well as implicitly all the other members of the trusts all the other members of the group.
group.
The RSVP protocol can operate in the presence of a non-RSVP router in The RSVP protocol can operate in the presence of a non-RSVP router in
the path from the sender to the receiver. The non-RSVP hop will the path from the sender to the receiver. The non-RSVP hop will
ignore the RSVP message and just pass it along. The next RSVP node ignore the RSVP message and just pass it along. The next RSVP node
can then process the RSVP message. For RSVP authentication or can then process the RSVP message. For RSVP authentication or
encryption to work in this case, the key used for computing the RSVP encryption to work in this case, the key used for computing the RSVP
message digest needs to be shared by the two RSVP neighbors, even if message digest needs to be shared by the two RSVP neighbors, even if
they are not IP neighbors. However, in the presence of non-RSVP they are not IP neighbors. However, in the presence of non-RSVP
hops, while an RSVP node always knows the next IP hop before hops, while an RSVP node always knows the next IP hop before
forwarding an RSVP Message, it does not always know the RSVP next forwarding an RSVP Message, it does not always know the RSVP next
skipping to change at page 5, line 18 skipping to change at page 5, line 17
receiver is R2, but it does necessarily not know if the RSVP next hop receiver is R2, but it does necessarily not know if the RSVP next hop
is R3 or R5. is R3 or R5.
This means that per interface and per neighbor keys cannot easily be This means that per interface and per neighbor keys cannot easily be
used in the presence of non-RSVP routers on the path between senders used in the presence of non-RSVP routers on the path between senders
and receivers. and receivers.
By contrast, group keying will naturally work in the presence of non- By contrast, group keying will naturally work in the presence of non-
RSVP routers. Referring back to Figure 1, with group keying, R1 RSVP routers. Referring back to Figure 1, with group keying, R1
would use the group key to sign a Path message addressed to the would use the group key to sign a Path message addressed to the
receiver and forwards it to R2. Being a non-RSVP node, R2 and will 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 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 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 R5, the RSVP router that receives the Path message will be able to
authenticate it successfully with the group key. authenticate it successfully with the group key.
3. Applicability of Key Types for RSVP 3. Applicability of Key Types for RSVP
3.1. Interface and neighbor based keys 3.1. Interface and neighbor based keys
Most current RSVP authentication implementations support interface Most current RSVP authentication implementations support interface
skipping to change at page 5, line 41 skipping to change at page 5, line 40
this is equivalent to neighbor based keys in the sense that a this is equivalent to neighbor based keys in the sense that a
different key is used for each neighbor. However, when the interface different key is used for each neighbor. However, when the interface
is 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.
With neighbor based keys, an RSVP key is bound to an interface plus a With neighbor based keys, an RSVP key is bound to an interface plus a
neighbor on that interface. It allows the distinction of different neighbor on that interface. It allows the distinction of different
trust groups on a single subnet. (Assuming that layer-2 security is trust groups on a single interface and subnet. (Assuming that
correctly implemented to prevent layer-2 attacks.) layer-2 security is correctly implemented to prevent layer-2
attacks.)
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 nodes 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.
skipping to change at page 6, line 34 skipping to change at page 6, line 34
......GKS1............. ......GKS1.............
: : : : : : : : : :
: : : : : : : : : :
source--R1--R2--R3-----destination source--R1--R2--R3-----destination
| | | |
|<-----domain 1----------------->| |<-----domain 1----------------->|
Figure 2: 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, because by definition the different domains do not trust
trust each other and would not be willing to trust the same group key each other. They would therefore not be willing to trust the same
server. For a single group key to be used in several security group key server. For a single group key to be used in several
domains, there is a need for a single group key server, which is security domains, there is a need for a single group key server,
trusted by both sides. While this is theoretically possible, in which is trusted by both sides. While this is theoretically
practice it is unlikely that there is a single such entity trusted by possible, in practice it is unlikely that there is a single such
both domains. Figure 3 illustrates this setup. entity trusted by 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 3: A Single Group Key Server across security domains Figure 3: A Single Group Key Server across security domains
skipping to change at page 11, line 17 skipping to change at page 11, line 17
6.3. Using IPsec AH 6.3. Using IPsec AH
The INTEGRITY object defined by [RFC2747] provides integrity The INTEGRITY object defined by [RFC2747] provides integrity
protection for RSVP also in a group keying context, as discussed protection for RSVP also in a group keying context, as discussed
above. IPsec AH [RFC4302] is an alternative method to provide above. IPsec AH [RFC4302] is an alternative method to provide
integrity protection for RSVP packets. integrity protection for RSVP packets.
The RSVP INTEGRITY object protects the entire RSVP message, but does The RSVP INTEGRITY object protects the entire RSVP message, but does
not protect the IP header of the packet nor the IP options (in IPv4) not protect the IP header of the packet nor the IP options (in IPv4)
or extension headers (in IPv6). IPsec AH tunnel mode (transport mode or extension headers (in IPv6).
is not appliable, see section 6.5) protects the entire original IP
packet, including the IP header, IP options or extension headers, IPsec AH tunnel mode (transport mode is not appliable, see section
plus the entire RSVP packet. The difference between the two schemes 6.5) protects the entire original IP packet, including the IP header
in terms of covered fields is therefore whether the IP header and IP of the original IP packet ("inner header"), IP options or extension
options or extension headers are protected (as is the case with AH) headers, plus the entire RSVP packet. It also protects the immutable
or not (as is the case with the INTEGRITY object). fields of the outer header.
The difference between the two schemes in terms of covered fields is
therefore whether the IP header and IP options or extension headers
of the original IP packet are protected (as is the case with AH) or
not (as is the case with the INTEGRITY object). Also, IPsec AH
covers the immutable fields of the outer header.
As described in the next section, IPsec tunnel mode can not be As described in the next section, IPsec tunnel mode can not be
applied for RSVP traffic in the presence of non-RSVP nodes; therefore applied for RSVP traffic in the presence of non-RSVP nodes; therefore
the security associations in both cases, AH and INTEGRITY object, are the security associations in both cases, AH and INTEGRITY object, are
between the same RSVP neighbors. From a keying point of view both between the same RSVP neighbors. From a keying point of view both
approaches are therefore comparable. This document focuses on keying approaches are therefore comparable. This document focuses on keying
approaches only; a general security comparison of these approaches is approaches only; a general security comparison of these approaches is
outside the scope of this document. outside the scope of this document.
6.4. Applicability of Tunnel Mode 6.4. Applicability of Tunnel Mode
skipping to change at page 14, line 13 skipping to change at page 14, line 19
lot of similarities in scenarios involving RSVP Aggregation over lot of similarities in scenarios involving RSVP Aggregation over
aggregate RSVP reservations ([RFC3175], [RFC4860]), RSVP aggregate RSVP reservations ([RFC3175], [RFC4860]), RSVP
Aggregation over MPLS-TE tunnels ([RFC4804]), and RSVP Aggregation over MPLS-TE tunnels ([RFC4804]), and RSVP
(Aggregation) over PCN ingress-egress aggregates. (Aggregation) over PCN ingress-egress aggregates.
9. Summary 9. Summary
The following table summarizes the various approaches for RSVP The following table summarizes the various approaches for RSVP
keying, and their applicability to various RSVP scenarios. In keying, and their applicability to various RSVP scenarios. In
particular, such keying can be used for RSVP authentication (e.g., particular, such keying can be used for RSVP authentication (e.g.,
using RSVP authentication or IPsec AH) and/ or for RSVP encryption using the RSVP INTEGRITY object or IPsec AH) and/ or for RSVP
(e.g., using IPsec ESP in tunnel mode). encryption (e.g., using IPsec ESP in tunnel mode).
+-----------------------------+--------------------+----------------+ +-----------------------------+--------------------+----------------+
| | Neighbor/interface | Group keys | | | Neighbor/interface | Group keys |
| | based keys | | | | based keys | |
+-----------------------------+--------------------+----------------+ +-----------------------------+--------------------+----------------+
| Works intra-domain | Yes | Yes | | Works intra-domain | Yes | Yes |
| Works inter-domain | Yes | No | | Works inter-domain | Yes | No |
| Works over non-RSVP hops | No | Yes (1) | | Works over non-RSVP hops | No | Yes (1) |
| Dynamic keying | Yes (IKE) | Yes (eg GDOI) | | Dynamic keying | Yes (IKE) | Yes (eg GDOI) |
+-----------------------------+--------------------+----------------+ +-----------------------------+--------------------+----------------+
skipping to change at page 15, line 30 skipping to change at page 15, line 35
Denial of Service by allowing exhaustion of some router resources Denial of Service by allowing exhaustion of some router resources
(e.g. memory). The subverted node could also generate fake Resv (e.g. memory). The subverted node could also generate fake Resv
messages upstream corresponding to valid Path states. In doing so, messages upstream corresponding to valid Path states. In doing so,
the subverted node can reserve excessive amounts of bandwidth thereby the subverted node can reserve excessive amounts of bandwidth thereby
possibly performing a denial of service attack. possibly performing a denial of service attack.
Group keying allows the additional abuse of sending fake RSVP Group keying allows the additional abuse of sending fake RSVP
messages to any node in the RSVP domain, not just adjacent 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 nodes. However, in practice this can be achieved to a large extent
also with per neighbor or interface keys, as discussed above. also with per neighbor or interface keys, as discussed above.
Therefore the impact of subverted nodes on the path is comparable, Therefore the impact of subverted nodes on the path is comparable for
independently whether per-interface, per-neighbor or group keys are all keying schemes discussed here (per-interface, per-neighbor, group
used. keys).
11. Acknowledgements 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, this document. Specific thanks to Bob Briscoe, Hannes Tschofenig,
Brian Weis and Ran Atkinson . Brian Weis, Ran Atkinson and Kenneth G. Carlberg.
12. Changes to Previous Version 12. Changes to Previous Version
This section provides a change log. It will be removed in the final This section provides a change log. It will be removed in the final
document: document:
12.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
skipping to change at page 16, line 47 skipping to change at page 17, line 4
o Re-wrote and re-structured the section on IPsec (section 6). o Re-wrote and re-structured the section on IPsec (section 6).
o Re-wrote the section on RSVP-TE and GMPLS (section 5.2). o Re-wrote the section on RSVP-TE and GMPLS (section 5.2).
o Various editorial changes. o Various editorial changes.
12.5. changes from ietf-02 to ietf-03 12.5. changes from ietf-02 to ietf-03
o Extension of section 6.3 (Using IPsec AH), to address comments o Extension of section 6.3 (Using IPsec AH), to address comments
received from Ran Atkinson. Included a comparison of what AH received from Ran Atkinson. Included a comparison of what AH
protects vs what the INTEGRITY object protects. protects vs what the INTEGRITY object protects.
o Added section 6.5 on "tunnel mode with address preservation. o Added section 6.5 on "tunnel mode with address preservation.
o Some minor edits. o Some minor edits.
12.6. changes from ietf-03 to ietf-04 12.6. changes from ietf-03 to ietf-04
o Added below table 1 in note (1) that "RSVP encryption with ESP and o Added below table 1 in note (1) that "RSVP encryption with ESP and
RSVP authentication with AH work over non-RSVP nodes in 'Tunnel RSVP authentication with AH work over non-RSVP nodes in 'Tunnel
Mode with Address Preservation'" Mode with Address Preservation'"
12.7. changes from ietf-04 to ietf-05
o Clarified in section 6.3 that IPsec AH also secures the immutable
fields of the outer header (comment from Bob Briscoe)
o Simplified in section 2 the comment that trust in group keying
extends to all members of the group (deleted the words on
"explicit and implicit"). (comment from Brian Weis)
o A number of corrections, re-wordings and clarifications in
13. Informative References 13. Informative References
[I-D.ietf-pcn-architecture] [I-D.ietf-pcn-architecture]
Eardley, P., "Pre-Congestion Notification (PCN) Eardley, P., "Pre-Congestion Notification (PCN)
Architecture", draft-ietf-pcn-architecture-10 (work in Architecture", draft-ietf-pcn-architecture-11 (work in
progress), March 2009. progress), April 2009.
[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 L. Faucheur, "RSVP
Proxy Approaches", Proxy Approaches",
draft-ietf-tsvwg-rsvp-proxy-approaches-06 (work in draft-ietf-tsvwg-rsvp-proxy-approaches-07 (work in
progress), October 2008. progress), May 2009.
[I-D.weis-gdoi-mac-tek] [I-D.weis-gdoi-mac-tek]
Weis, B. and S. Rowles, "GDOI Generic Message Weis, B. and S. Rowles, "GDOI Generic Message
Authentication Code Policy", draft-weis-gdoi-mac-tek-00 Authentication Code Policy", draft-weis-gdoi-mac-tek-00
(work in progress), July 2008. (work in progress), July 2008.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997. Functional Specification", RFC 2205, September 1997.
 End of changes. 19 change blocks. 
35 lines changed or deleted 52 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/