draft-ietf-tsvwg-rsvp-security-groupkeying-08.txt   draft-ietf-tsvwg-rsvp-security-groupkeying-09.txt 
Network Working Group M. Behringer Network Working Group M. Behringer
Internet-Draft F. Le Faucheur Internet-Draft F. Le Faucheur
Intended status: Informational B. Weis Intended status: Informational B. Weis
Expires: April 25, 2011 Cisco Systems Expires: June 10, 2011 Cisco Systems
October 22, 2010 December 7, 2010
Applicability of Keying Methods for RSVP Security Applicability of Keying Methods for RSVP Security
draft-ietf-tsvwg-rsvp-security-groupkeying-08.txt draft-ietf-tsvwg-rsvp-security-groupkeying-09.txt
Abstract Abstract
The Resource reSerVation Protocol (RSVP) allows hop-by-hop integrity The Resource reSerVation Protocol (RSVP) allows hop-by-hop integrity
protection of RSVP neighbors. This requires messages to be protection of RSVP neighbors. This requires messages to be
cryptographically protected using a shared secret between cryptographically protected using a shared secret between
participating nodes. This document compares group keying for RSVP participating nodes. This document compares group keying for RSVP
with per neighbor or per interface keying, and discusses the with per neighbor or per interface keying, and discusses the
associated key provisioning methods as well as applicability and associated key provisioning methods as well as applicability and
limitations of these approaches. The document also discusses limitations of these approaches. The document also discusses
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on April 25, 2011. This Internet-Draft will expire on June 10, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 13, line 43 skipping to change at page 13, line 43
middle modifies the destination of the outer IP header of the tunnel middle modifies the destination of the outer IP header of the tunnel
mode packet. The inbound processing rules for tunnel mode with mode packet. The inbound processing rules for tunnel mode with
address preservation (Section 5.2 of [RFC5374]) require that the address preservation (Section 5.2 of [RFC5374]) require that the
receiver verify that the addresses in the outer IP header and the receiver verify that the addresses in the outer IP header and the
inner IP header are consistent. Therefore, the attack should be inner IP header are consistent. Therefore, the attack should be
detected and RSVP reservations will not proceed along an unintended detected and RSVP reservations will not proceed along an unintended
path. path.
7. End Host Considerations 7. End Host Considerations
Unless RSVP Proxy entities ([I-D.ietf-tsvwg-rsvp-proxy-approaches] Unless RSVP Proxy entities ([RFC5945] are used, RSVP signaling is
are used, RSVP signaling is controlled by end systems and not controlled by end systems and not routers. As discussed in
routers. As discussed in [RFC4230], RSVP allows both user-based [RFC4230], RSVP allows both user-based security and host-based
security and host-based security. User-based authentication aims at security. User-based authentication aims at "providing policy based
"providing policy based admission control mechanism based on user admission control mechanism based on user identities or application."
identities or application." To identify the user or the application, To identify the user or the application, a policy element called
a policy element called AUTH_DATA, which is contained in the AUTH_DATA, which is contained in the POLICY_DATA object, is created
POLICY_DATA object, is created by the RSVP daemon at the user's host by the RSVP daemon at the user's host and transmitted inside the RSVP
and transmitted inside the RSVP message. This way, a user may message. This way, a user may authenticate to the Policy Decision
authenticate to the Policy Decision Point (or directly to the first Point (or directly to the first hop router). Host-based security
hop router). Host-based security relies on the same mechanisms as relies on the same mechanisms as between routers (i.e., the INTEGRITY
between routers (i.e., the INTEGRITY object) as specified in object) as specified in [RFC2747]. For host-based security, per
[RFC2747]. For host-based security, per interface or per neighbor interface or per neighbor keys may be used, however, key management
keys may be used, however, key management with statically provisioned with statically provisioned keys can be difficult in a large scale
keys can be difficult in a large scale deployment, as described in deployment, as described in section 4. In principle an end host can
section 4. In principle an end host can also be part of a group key also be part of a group key scheme, such as GDOI. If the end systems
scheme, such as GDOI. If the end systems are part of the same are part of the same security domain as the network itself, group
security domain as the network itself, group keying can be extended keying can be extended to include the end systems. If the end
to include the end systems. If the end systems and the network are systems and the network are in different zones of trust, group keying
in different zones of trust, group keying cannot be used. cannot be used.
8. Applicability to Other Architectures and Protocols 8. Applicability to Other Architectures and Protocols
While, so far, this document discusses only RSVP security assuming While, so far, this document discusses only 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
skipping to change at page 14, line 39 skipping to change at page 14, line 39
intercept the initial end-to-end RSVP Path message. intercept the initial end-to-end RSVP Path message.
o Generic Aggregate Resource ReSerVation Protocol (RSVP) o Generic Aggregate Resource ReSerVation Protocol (RSVP)
Reservations [RFC4860]: This document also discusses aggregation Reservations [RFC4860]: This document also discusses aggregation
of individual RSVP reservations. Here again, group keying applies of individual RSVP reservations. Here again, group keying applies
and is mentioned in the Security Considerations section. and is mentioned in the Security Considerations section.
o Aggregation of Resource ReSerVation Protocol (RSVP) Reservations o Aggregation of Resource ReSerVation Protocol (RSVP) Reservations
over MPLS TE/DS-TE Tunnels [RFC4804]([RFC4804]): This scheme also over MPLS TE/DS-TE Tunnels [RFC4804]([RFC4804]): This scheme also
defines a form of aggregation of RSVP reservation but this time defines a form of aggregation of RSVP reservation but this time
over MPLS TE Tunnels. Similarly, group keying may be used in such over MPLS TE Tunnels. Similarly, group keying may be used in such
an environment. an environment.
o Pre-Congestion Notification (PCN): [I-D.ietf-pcn-architecture] o Pre-Congestion Notification (PCN): [RFC5559] defines an
defines an architecture for flow admission and termination based architecture for flow admission and termination based on
on aggregated pre-congestion information. One deployment model aggregated pre-congestion information. One deployment model for
for this architecture is based on IntServ over DiffServ: the this architecture is based on IntServ over DiffServ: the DiffServ
DiffServ region is PCN-enabled, RSVP signalling is used end-to-end region is PCN-enabled, RSVP signalling is used end-to-end but the
but the PCN-domain is a single RSVP hop, i.e. only the PCN- PCN-domain is a single RSVP hop, i.e. only the PCN- boundary-nodes
boundary-nodes process RSVP messages. In this scenario, RSVP process RSVP messages. In this scenario, RSVP authentication may
authentication may be required among PCN-boundary-nodes and the be required among PCN-boundary-nodes and the considerations about
considerations about keying approaches discussed earlier in this keying approaches discussed earlier in this document apply. In
document apply. In particular, group keying may facilitate particular, group keying may facilitate operations since the
operations since the ingress PCN-boundary-node does not ingress PCN-boundary-node does not necessarily know ahead of time
necessarily know ahead of time which Egress PCN-boundary-node will which Egress PCN-boundary-node will intercept and process the
intercept and process the initial end-to-end Path message. Note initial end-to-end Path message. Note that from the viewpoint of
that from the viewpoint of securing end-to-end RSVP, there are a securing end-to-end RSVP, there are a lot of similarities in
lot of similarities in scenarios involving RSVP Aggregation over scenarios involving RSVP Aggregation over aggregate RSVP
aggregate RSVP reservations ([RFC3175], [RFC4860]), RSVP reservations ([RFC3175], [RFC4860]), RSVP Aggregation over MPLS-TE
Aggregation over MPLS-TE tunnels ([RFC4804]), and RSVP tunnels ([RFC4804]), and RSVP (Aggregation) over PCN ingress-
(Aggregation) over PCN ingress-egress aggregates. 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 the RSVP INTEGRITY object or AH) and/ or for RSVP encryption using the RSVP INTEGRITY object or AH) and/ or for RSVP encryption
(e.g., using ESP in tunnel mode). (e.g., using ESP in tunnel mode).
+-------------------------------+-----------------+-----------------+ +-------------------------------+-----------------+-----------------+
skipping to change at page 17, line 7 skipping to change at page 17, line 7
this document. Specific thanks to Bob Briscoe, Hannes Tschofenig, this document. Specific thanks to Bob Briscoe, Hannes Tschofenig,
Ran Atkinson, Stephen Kent, and Kenneth G. Carlberg. Ran Atkinson, Stephen Kent, and Kenneth G. Carlberg.
12. IANA Considerations 12. IANA Considerations
There are no IANA considerations within this document. This section There are no IANA considerations within this document. This section
can be removed if this document is published as an RFC. can be removed if this document is published as an RFC.
13. Informative References 13. Informative References
[I-D.ietf-pcn-architecture]
Eardley, P., "Pre-Congestion Notification (PCN)
Architecture", draft-ietf-pcn-architecture-11 (work in
progress), April 2009.
[I-D.ietf-tsvwg-rsvp-proxy-approaches]
Faucheur, F., Manner, J., Wing, D., and L. Faucheur, "RSVP
Proxy Approaches",
draft-ietf-tsvwg-rsvp-proxy-approaches-09 (work in
progress), March 2010.
[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-01 Authentication Code Policy", draft-weis-gdoi-mac-tek-01
(work in progress), June 2010. (work in progress), June 2010.
[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.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(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., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
skipping to change at page 18, line 26 skipping to change at page 18, line 12
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, [RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
December 2005. December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005. RFC 4303, December 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[RFC4804] Le Faucheur, F., "Aggregation of Resource ReSerVation [RFC4804] Le Faucheur, F., "Aggregation of Resource ReSerVation
Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels", Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels",
RFC 4804, February 2007. RFC 4804, February 2007.
[RFC4860] Le Faucheur, F., Davie, B., Bose, P., Christou, C., and M. [RFC4860] Le Faucheur, F., Davie, B., Bose, P., Christou, C., and M.
Davenport, "Generic Aggregate Resource ReSerVation Davenport, "Generic Aggregate Resource ReSerVation
Protocol (RSVP) Reservations", RFC 4860, May 2007. Protocol (RSVP) Reservations", RFC 4860, May 2007.
[RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa,
"Extensions to Resource Reservation Protocol - Traffic "Extensions to Resource Reservation Protocol - Traffic
Engineering (RSVP-TE) for Point-to-Multipoint TE Label Engineering (RSVP-TE) for Point-to-Multipoint TE Label
Switched Paths (LSPs)", RFC 4875, May 2007. Switched Paths (LSPs)", RFC 4875, May 2007.
[RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast [RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast
Extensions to the Security Architecture for the Internet Extensions to the Security Architecture for the Internet
Protocol", RFC 5374, November 2008. Protocol", RFC 5374, November 2008.
[RFC5559] Eardley, P., "Pre-Congestion Notification (PCN)
Architecture", RFC 5559, June 2009.
[RFC5945] Le Faucheur, F., Manner, J., Wing, D., and A. Guillou,
"Resource Reservation Protocol (RSVP) Proxy Approaches",
RFC 5945, October 2010.
Authors' Addresses Authors' Addresses
Michael H. Behringer Michael H. Behringer
Cisco Systems Cisco Systems
Village d'Entreprises Green Side Village d'Entreprises Green Side
400, Avenue Roumanille, Batiment T 3 400, Avenue Roumanille, Batiment T 3
Biot - Sophia Antipolis 06410 Biot - Sophia Antipolis 06410
France France
Email: mbehring@cisco.com Email: mbehring@cisco.com
 End of changes. 9 change blocks. 
59 lines changed or deleted 49 lines changed or added

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