draft-ietf-tsvwg-rsvp-security-groupkeying-02.txt   draft-ietf-tsvwg-rsvp-security-groupkeying-03.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: May 7, 2009 November 3, 2008 Expires: September 6, 2009 March 5, 2009
Applicability of Keying Methods for RSVP Security Applicability of Keying Methods for RSVP Security
draft-ietf-tsvwg-rsvp-security-groupkeying-02.txt draft-ietf-tsvwg-rsvp-security-groupkeying-03.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
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.
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.
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."
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 May 7, 2009. This Internet-Draft will expire on September 6, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
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. The present document also discusses applicability these approaches. The present document also discusses applicability
skipping to change at page 2, line 25 skipping to change at page 2, line 30
4.2.1. Neighbor and Interface Based Key Negotiation . . . . . 8 4.2.1. Neighbor and Interface Based Key Negotiation . . . . . 8
4.2.2. Dynamic Group Key Distribution . . . . . . . . . . . . 8 4.2.2. Dynamic Group Key Distribution . . . . . . . . . . . . 8
5. Specific Cases . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Specific Cases . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. RSVP Notify Messages . . . . . . . . . . . . . . . . . . . 8 5.1. RSVP Notify Messages . . . . . . . . . . . . . . . . . . . 8
5.2. RSVP-TE and GMPLS . . . . . . . . . . . . . . . . . . . . 8 5.2. RSVP-TE and GMPLS . . . . . . . . . . . . . . . . . . . . 8
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 . . . . . . . . . . . . . 11 6.5. Applicability of Transport Mode . . . . . . . . . . . . . 12
7. End Host Considerations . . . . . . . . . . . . . . . . . . . 11 6.6. Applicability of Tunnel Mode with Address Preservation . . 12
8. Applicability to Other Architectures and Protocols . . . . . . 12 7. End Host Considerations . . . . . . . . . . . . . . . . . . . 12
9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. Applicability to Other Architectures and Protocols . . . . . . 13
9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14
10.1. Subverted RSVP Nodes . . . . . . . . . . . . . . . . . . . 14 10.1. Subverted RSVP Nodes . . . . . . . . . . . . . . . . . . . 15
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 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 . . . . . . . . 15
12.2. changes from behringer-01 to ietf-00 . . . . . . . . . . . 15 12.2. changes from behringer-01 to ietf-00 . . . . . . . . . . . 16
12.3. changes from ietf-00 to ietf-01 . . . . . . . . . . . . . 15 12.3. changes from ietf-00 to ietf-01 . . . . . . . . . . . . . 16
12.4. changes from ietf-01 to ietf-02 . . . . . . . . . . . . . 15 12.4. changes from ietf-01 to ietf-02 . . . . . . . . . . . . . 16
13. Informative References . . . . . . . . . . . . . . . . . . . . 16 12.5. changes from ietf-02 to ietf-03 . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 13. Informative References . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 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
skipping to change at page 11, line 12 skipping to change at page 11, line 12
encapsulated packet, and then act on the RSVP packet. This way an encapsulated packet, and then act on the RSVP packet. This way an
attacker cannot create new reservations or affect existing ones, but attacker cannot create new reservations or affect existing ones, but
he can "re-direct" reservations to parts of the network off the he can "re-direct" reservations to parts of the network off the
actual reservation path, thereby potentially denying resources to actual reservation path, thereby potentially denying resources to
other applications on that part of the network. other applications on that part of the network.
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 is an alternative method to provide integrity above. IPsec AH [RFC4302] is an alternative method to provide
protection for RSVP. Both methods provide comparable security. integrity protection for RSVP packets.
The RSVP INTEGRITY object protects the entire RSVP message, but does
not protect the IP header of the packet nor the IP options (in IPv4)
or extension headers (in IPv6). IPsec AH tunnel mode (transport mode
is not appliable, see section 6.5) protects the entire original IP
packet, including the IP header, IP options or extension headers,
plus the entire RSVP packet. The difference between the two schemes
in terms of covered fields is therefore whether the IP header and IP
options or extension headers are protected (as is the case with AH)
or not (as is the case with the INTEGRITY object).
As described in the next section, IPsec tunnel mode can not be
applied for RSVP traffic in the presence of non-RSVP nodes; therefore
the security associations in both cases, AH and INTEGRITY object, are
between the same RSVP neighbors. From a keying point of view both
approaches are therefore comparable. This document focuses on keying
approaches only; a general security comparison of these approaches is
outside the scope of this document.
6.4. Applicability of Tunnel Mode 6.4. Applicability of Tunnel Mode
IPsec tunnel mode encapsulates the original packet, prepending a new IPsec tunnel mode encapsulates the original packet, prepending a new
IP tunnel header plus an ESP or AH sub-header. The entire original IP tunnel header plus an ESP or AH sub-header. The entire original
packet plus the ESP/AH subheader is secured. In the case of ESP the packet plus the ESP/AH subheader is secured. In the case of ESP the
new, outer IP header however is not cryptographically secured in this new, outer IP header however is not cryptographically secured in this
process. This leads to the problem described in Section 6.2. AH process. This leads to the problem described in Section 6.2. AH
tunnel mode also secures the outer header, and is therefore not tunnel mode also secures the outer header, and is therefore not
subject to these man-in-the-middle attacks. subject to these man-in-the-middle attacks.
skipping to change at page 11, line 48 skipping to change at page 12, line 18
IPsec transport mode, as defined in [RFC4303] is not suitable for IPsec transport mode, as defined in [RFC4303] is not suitable for
securing RSVP Path messages, since those messages preserve the securing RSVP Path messages, since those messages preserve the
original source and destination. [RFC4303] states explicitly that original source and destination. [RFC4303] states explicitly that
"the use of transport mode by an intermediate system (e.g., a "the use of transport mode by an intermediate system (e.g., a
security gateway) is permitted only when applied to packets whose security gateway) is permitted only when applied to packets whose
source address (for outbound packets) or destination address (for source address (for outbound packets) or destination address (for
inbound packets) is an address belonging to the intermediate system inbound packets) is an address belonging to the intermediate system
itself." This would not be the case for RSVP Path messages. itself." This would not be the case for RSVP Path messages.
6.6. Applicability of Tunnel Mode with Address Preservation
The document "Multicast Extensions to the Security Architecture for
the Internet Protocol" [RFC5374] defines in section 3.1 a new tunnel
mode: Tunnel mode with address preservation. This mode copies the
destination and optionally the source address from the inner header
to the outer header. Therefore the encapsulated packet will have the
same destination address as the original packet, and be normally
subject to the same routing decisions. While [RFC5374] is focusing
on multicast environments, tunnel mode with address preservation can
be used also to protect unicast traffic in conjunction with group
keying.
Tunnel mode with address preservation, in conjunction with group
keying, allows the use of IPsec AH or ESP for protection of RSVP even
in cases where non-RSVP nodes have to be traversed. This is because
it allows routing of the IPsec protected packet through the non-RSVP
nodes in the same way as if it was not IPsec protected.
7. End Host Considerations 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
skipping to change at page 14, line 47 skipping to change at page 15, line 36
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,
independently whether per-interface, per-neighbor or group keys are independently whether per-interface, per-neighbor or group keys are
used. used.
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 and this document. Specific thanks to Bob Briscoe, Hannes Tschofenig,
Brian Weis. Brian Weis and Ran Atkinson .
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 4 skipping to change at page 16, line 40
o Changed reference ID.weis-gdoi-for-rsvp to the new draft ID.weis- o Changed reference ID.weis-gdoi-for-rsvp to the new draft ID.weis-
gdoi-mac-tek gdoi-mac-tek
o in several places, explicitly mentioned "encryption" for RSVP (in o in several places, explicitly mentioned "encryption" for RSVP (in
parallel to authentication). parallel to authentication).
o Various minor edits. o Various minor edits.
12.4. changes from ietf-01 to ietf-02 12.4. changes from ietf-01 to ietf-02
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
o Extension of section 6.3 (Using IPsec AH), to address comments
received from Ran Atkinson. Included a comparison of what AH
protects vs what the INTEGRITY object protects.
o Added section 6.5 on "tunnel mode with address preservation.
o Some minor edits.
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-08 (work in Architecture", draft-ietf-pcn-architecture-09 (work in
progress), October 2008. progress), January 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 A. Guillou, "RSVP
Proxy Approaches", Proxy Approaches",
draft-ietf-tsvwg-rsvp-proxy-approaches-06 (work in draft-ietf-tsvwg-rsvp-proxy-approaches-06 (work in
progress), October 2008. progress), October 2008.
[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
skipping to change at page 17, line 23 skipping to change at page 18, line 20
Hierarchy with Generalized Multi-Protocol Label Switching Hierarchy with Generalized Multi-Protocol Label Switching
(GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
[RFC4216] Zhang, R. and J. Vasseur, "MPLS Inter-Autonomous System [RFC4216] Zhang, R. and J. Vasseur, "MPLS Inter-Autonomous System
(AS) Traffic Engineering (TE) Requirements", RFC 4216, (AS) Traffic Engineering (TE) Requirements", RFC 4216,
November 2005. November 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.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
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", [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.
[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
Extensions to the Security Architecture for the Internet
Protocol", RFC 5374, November 2008.
Authors' Addresses Authors' Addresses
Michael H. Behringer Michael H. Behringer
Cisco Systems Inc Cisco Systems Inc
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
skipping to change at page 19, line 4 skipping to change at line 860
Francois Le Faucheur Francois Le Faucheur
Cisco Systems Inc Cisco Systems Inc
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: flefauch@cisco.com Email: flefauch@cisco.com
URI: http://www.cisco.com URI: http://www.cisco.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 16 change blocks. 
26 lines changed or deleted 87 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/