draft-ietf-tsvwg-rsvp-proxy-proto-06.txt   draft-ietf-tsvwg-rsvp-proxy-proto-07.txt 
TSVWG F. Le Faucheur TSVWG F. Le Faucheur
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Standards Track J. Manner Intended status: Standards Track J. Manner
Expires: December 1, 2008 University of Helsinki Expires: January 2, 2009 University of Helsinki
A. Narayanan A. Narayanan
Cisco Cisco
A. Guillou A. Guillou
H. Malik H. Malik
Neuf Neuf
May 30, 2008 July 1, 2008
RSVP Extensions for Path-Triggered RSVP Receiver Proxy RSVP Extensions for Path-Triggered RSVP Receiver Proxy
draft-ietf-tsvwg-rsvp-proxy-proto-06.txt draft-ietf-tsvwg-rsvp-proxy-proto-07.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 40 skipping to change at page 1, line 40
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 December 1, 2008. This Internet-Draft will expire on January 2, 2009.
Abstract Abstract
RSVP signaling can be used to make end-to-end resource reservations RSVP signaling can be used to make end-to-end resource reservations
in an IP network in order to guarantee the QoS required by certain in an IP network in order to guarantee the QoS required by certain
flows. With conventional RSVP, both the data sender and receiver of flows. With conventional RSVP, both the data sender and receiver of
a given flow take part in RSVP signaling. Yet, there are many use a given flow take part in RSVP signaling. Yet, there are many use
cases where resource reservation is required, but the receiver, the cases where resource reservation is required, but the receiver, the
sender, or both, is not RSVP-capable. Where the receiver is not sender, or both, is not RSVP-capable. Where the receiver is not
RSVP-capable, an RSVP router may behave as an RSVP Receiver Proxy RSVP-capable, an RSVP router may behave as an RSVP Receiver Proxy
skipping to change at page 20, line 46 skipping to change at page 20, line 46
shared key across all the RSVP routers of a part of the network where shared key across all the RSVP routers of a part of the network where
there may be RSVP neighbors with IP hops in between. For example, there may be RSVP neighbors with IP hops in between. For example,
all the RSVP routers of an administrative domain (including the all the RSVP routers of an administrative domain (including the
receiver proxys) could share the same RSVP Authentication key, while receiver proxys) could share the same RSVP Authentication key, while
different per-neighbor keys could be used between any RSVP router different per-neighbor keys could be used between any RSVP router
pair straddling the boundary between two administrative domains that pair straddling the boundary between two administrative domains that
have agreed to use RSVP signaling. have agreed to use RSVP signaling.
When the same RSVP Authentication shared key is to be shared among When the same RSVP Authentication shared key is to be shared among
multiple RSVP neighbors, manual key distribution may be used. multiple RSVP neighbors, manual key distribution may be used.
[I-D.behringer-tsvwg-rsvp-security-groupkeying] also discusses [I-D.ietf-tsvwg-rsvp-security-groupkeying] also discusses
applicability of dynamic group key distribution method for dynamic applicability of dynamic group key distribution method for dynamic
update of such shared keys among RSVP routers. update of such shared keys among RSVP routers.
The RSVP Authentication mechanisms do not provide confidentiality. The RSVP Authentication mechanisms do not provide confidentiality.
If confidentiality is required, IPsec ESP ([RFC4303]) may be used, If confidentiality is required, IPsec ESP ([RFC4303]) may be used,
although it imposes the burden of key distribution. It also faces although it imposes the burden of key distribution. It also faces
the additional issue discussed for key management above in the case the additional issue discussed for key management above in the case
where there can be IP hops in between RSVP hops. where there can be IP hops in between RSVP hops.
[I-D.behringer-tsvwg-rsvp-security-groupkeying] discusses [I-D.ietf-tsvwg-rsvp-security-groupkeying] discusses applicability of
applicability of various keying methods for applying IPsec encryption various keying methods for applying IPsec encryption and
and authentication to RSVP, including use of group keys and dynamic authentication to RSVP, including use of group keys and dynamic group
group key distribution. key distribution.
When an RSVP receiver proxy is used, the RSVP reservation is no When an RSVP receiver proxy is used, the RSVP reservation is no
longer controlled by the receiver, but rather is controlled by the longer controlled by the receiver, but rather is controlled by the
receiver proxy (using hints received from the sender in the Path receiver proxy (using hints received from the sender in the Path
message) on behalf of the sender. Thus, the receiver proxy ought to message) on behalf of the sender. Thus, the receiver proxy ought to
be trusted by the end-systems to control the RSVP reservation be trusted by the end-systems to control the RSVP reservation
appropriately. However, basic RSVP operation already assumes a trust appropriately. However, basic RSVP operation already assumes a trust
model where end-systems trust RSVP nodes to appropriately perform model where end-systems trust RSVP nodes to appropriately perform
RSVP reservations. So the use of RSVP receiver proxy is not seen as RSVP reservations. So the use of RSVP receiver proxy is not seen as
introducing any significant additional security threat or as introducing any significant additional security threat or as
skipping to change at page 22, line 4 skipping to change at page 22, line 4
This document defines in Section 3.2 an optional method relying on This document defines in Section 3.2 an optional method relying on
the use of the Notify message specified in [RFC3473]. The Notify the use of the Notify message specified in [RFC3473]. The Notify
message can be sent in a non-hop-by-hop fashion that precludes RSVP's message can be sent in a non-hop-by-hop fashion that precludes RSVP's
hop-by-hop integrity and authentication model. The approaches and hop-by-hop integrity and authentication model. The approaches and
considerations for addressing this issue presented in the Security considerations for addressing this issue presented in the Security
Considerations section of [RFC3473] apply. In particular, where the Considerations section of [RFC3473] apply. In particular, where the
Notify messages are transmitted non-hop-by-hop and the same level of Notify messages are transmitted non-hop-by-hop and the same level of
security provided by [RFC2747] is desired, the standard IPsec based security provided by [RFC2747] is desired, the standard IPsec based
integrity and authentication can be used. Alternatively, the sending integrity and authentication can be used. Alternatively, the sending
of non-hop-by-hop Notify messages can be disabled. Finally, of non-hop-by-hop Notify messages can be disabled. Finally,
[I-D.behringer-tsvwg-rsvp-security-groupkeying] discusses [I-D.ietf-tsvwg-rsvp-security-groupkeying] discusses applicability of
applicability of group keying for non-hop-by-hop Notify messages. group keying for non-hop-by-hop Notify messages.
5. IANA Considerations 5. IANA Considerations
Since, as discussed in Section 3.1.2, this document allows two Error Since, as discussed in Section 3.1.2, this document allows two Error
Codes to be used in PathErr messages while [RFC2205] only specified Codes to be used in PathErr messages while [RFC2205] only specified
their use in ResvErr messages, this document requires that IANA their use in ResvErr messages, this document requires that IANA
updates the existing entries for these two Error Codes under the updates the existing entries for these two Error Codes under the
"Error Codes and Globally-Defined Error Value Sub-Codes" registry. "Error Codes and Globally-Defined Error Value Sub-Codes" registry.
Each entry should refer to this document, in addition to referring to Each entry should refer to this document, in addition to referring to
[RFC2205]. Specifically, the entry for Error Code 1 and Error Code 2 [RFC2205]. Specifically, the entry for Error Code 1 and Error Code 2
skipping to change at page 25, line 9 skipping to change at page 25, line 9
This document benefited from discussions with Carol Iturralde and This document benefited from discussions with Carol Iturralde and
Anca Zamfir. Lou Berger, Adrian Farrel and John Drake provided Anca Zamfir. Lou Berger, Adrian Farrel and John Drake provided
review and guidance, in particular on the usage of the review and guidance, in particular on the usage of the
Path_State_Removed flag and of the Notify message, both borrowed from Path_State_Removed flag and of the Notify message, both borrowed from
[RFC3473]. We also thank Ken Carlberg for his valuable input. [RFC3473]. We also thank Ken Carlberg for his valuable input.
7. References 7. References
7.1. Normative References 7.1. Normative References
[I-D.ietf-tsvwg-rsvp-proxy-approaches]
Le Faucheur, F., Manner, J., Wing, D., and A. Guillou,
"RSVP Proxy Approaches", December 2007.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[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.
skipping to change at page 25, line 40 skipping to change at page 25, line 36
[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.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005. RFC 4303, December 2005.
7.2. Informative References 7.2. Informative References
[I-D.behringer-tsvwg-rsvp-security-groupkeying] [I-D.ietf-tsvwg-rsvp-proxy-approaches]
Behringer, M. and F. Le Faucheur, "Applicability of Keying Faucheur, F., Manner, J., Wing, D., and A. Guillou, "RSVP
Methods for RSVP Security", November 2007. Proxy Approaches",
draft-ietf-tsvwg-rsvp-proxy-approaches-04 (work in
progress), April 2008.
[I-D.ietf-tsvwg-rsvp-security-groupkeying]
Behringer, M. and F. Faucheur, "Applicability of Keying
Methods for RSVP Security",
draft-ietf-tsvwg-rsvp-security-groupkeying-00 (work in
progress), February 2008.
Authors' Addresses Authors' Addresses
Francois Le Faucheur Francois Le Faucheur
Cisco Systems Cisco Systems
Greenside, 400 Avenue de Roumanille Greenside, 400 Avenue de Roumanille
Sophia Antipolis 06410 Sophia Antipolis 06410
France France
Phone: +33 4 97 23 26 19 Phone: +33 4 97 23 26 19
 End of changes. 9 change blocks. 
18 lines changed or deleted 22 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/