draft-ietf-tsvwg-rsvp-security-groupkeying-07.txt   draft-ietf-tsvwg-rsvp-security-groupkeying-08.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: March 27, 2011 Cisco Systems Expires: April 25, 2011 Cisco Systems
September 23, 2010 October 22, 2010
Applicability of Keying Methods for RSVP Security Applicability of Keying Methods for RSVP Security
draft-ietf-tsvwg-rsvp-security-groupkeying-07.txt draft-ietf-tsvwg-rsvp-security-groupkeying-08.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 March 27, 2011. This Internet-Draft will expire on April 25, 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 2, line 36 skipping to change at page 2, line 36
6.2. Comparing AH and the INTEGRITY Object . . . . . . . . . . 11 6.2. Comparing AH and the INTEGRITY Object . . . . . . . . . . 11
6.3. Applicability of Tunnel Mode . . . . . . . . . . . . . . . 12 6.3. Applicability of Tunnel Mode . . . . . . . . . . . . . . . 12
6.4. Non-Applicability of Transport Mode . . . . . . . . . . . 12 6.4. Non-Applicability of Transport Mode . . . . . . . . . . . 12
6.5. Applicability of Tunnel Mode with Address Preservation . . 13 6.5. Applicability of Tunnel Mode with Address Preservation . . 13
7. End Host Considerations . . . . . . . . . . . . . . . . . . . 13 7. End Host Considerations . . . . . . . . . . . . . . . . . . . 13
8. Applicability to Other Architectures and Protocols . . . . . . 14 8. Applicability to Other Architectures and Protocols . . . . . . 14
9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16
10.1. Subverted Nodes . . . . . . . . . . . . . . . . . . . . . 16 10.1. Subverted Nodes . . . . . . . . . . . . . . . . . . . . . 16
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
12. Changes to Previous Version . . . . . . . . . . . . . . . . . 16 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
12.1. changes from behringer-00 to behringer-01 . . . . . . . . 17 13. Informative References . . . . . . . . . . . . . . . . . . . . 17
12.2. changes from behringer-01 to ietf-00 . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
12.3. changes from ietf-00 to ietf-01 . . . . . . . . . . . . . 17
12.4. changes from ietf-01 to ietf-02 . . . . . . . . . . . . . 17
12.5. changes from ietf-02 to ietf-03 . . . . . . . . . . . . . 17
12.6. changes from ietf-03 to ietf-04 . . . . . . . . . . . . . 18
12.7. changes from ietf-04 to ietf-05 . . . . . . . . . . . . . 18
12.8. changes from ietf-05 to ietf-06 . . . . . . . . . . . . . 18
12.9. changes from ietf-06 to ietf-07 . . . . . . . . . . . . . 18
13. Informative References . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
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 identity of the RSVP node that sent the recipient to verify the identity 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 16, line 42 skipping to change at page 16, line 42
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 for Therefore the impact of subverted nodes on the path is comparable for
all keying schemes discussed here (per interface, per neighbor, group all keying schemes discussed here (per interface, per neighbor, group
keys). 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, Ran Atkinson, Stephen Kent, and Kenneth G. Carlberg. Ran Atkinson, Stephen Kent, and Kenneth G. Carlberg.
12. Changes to Previous Version
This section provides a change log. It will be removed in the final
document:
12.1. changes from behringer-00 to behringer-01
o New section "Applicability to Other Architectures and Protocols":
Goal is to clarify the scope of this document: The idea presented
here is also applicable to other architectures
(PCN[I-D.ietf-pcn-architecture], RFC3175 and RFC4860, etc.
o Clarified the scope of this document versus RFC4230 (in the
introduction, last paragraph).
o Added a section on "End Host Considerations".
o Expanded section 5.5 (RSVP Encryption) to clarify that GDOI
contains all necessary mechanisms to do RSVP encrpytion.
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.
o Lots of small editorial changes (references, typos, figures, etc).
o Added an Acknowledgements section.
12.2. changes from behringer-01 to ietf-00
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
and not necessarily the recommended solution
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, explicitly mentioned "encryption" for RSVP (in
parallel to authentication).
o Various minor edits.
12.4. changes from ietf-01 to ietf-02
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 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.
12.6. changes from ietf-03 to ietf-04
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
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
response to Kenneth Carlberg's email from 2 June 2009
12.8. changes from ietf-05 to ietf-06
This version addresses extensive comments from Stephen Kent in the
SecDir review (see email from Gorry on 15 Jan 2010). Specifically:
o Many editorial changes, and small corrections.
o Deleted reference to RFC3562, since it is not applicable in this
context.
o Clarification in section 2 that the handshake specified in RFC2747
allows to determine the identity of the next RSVP hop in the
presence of non-RSVP hops.
o Cleared up inconsistent wording on "trust group" and "security
domain", and defined the latter. (Section 3)
o Added a paragraph on the applicability of sequence numbers in
section 3.1 and 3.2.
o Defined static key provisioning. (Section 4.1)
o Clarified wording in 6.1 on the use of GDOI.
o Added in section 6.6 some clarification to the use of tunnel mode
with address preservation.
12.9. changes from ietf-06 to ietf-07 12. IANA Considerations
This version addressed the last WGLC, and incorporates a few comments There are no IANA considerations within this document. This section
from Bob Briscoe, mostly editorial. The main change is the re- can be removed if this document is published as an RFC.
insertion of a potential man-in-the-middle attack with group keying,
which was accidentally deleted. Affected sections are 6.3 and 6.5.
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-11 (work in Architecture", draft-ietf-pcn-architecture-11 (work in
progress), April 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 L. Faucheur, "RSVP Faucheur, F., Manner, J., Wing, D., and L. Faucheur, "RSVP
 End of changes. 7 change blocks. 
114 lines changed or deleted 11 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/