< draft-ietf-mpls-ldp-gtsm-07.txt		draft-ietf-mpls-ldp-gtsm-08.txt >
	MPLS Working Group C. Pignataro		MPLS Working Group C. Pignataro
	Internet-Draft R. Asati		Internet-Draft R. Asati
	Updates: 5036 (if approved) Cisco Systems		Updates: 5036 (if approved) Cisco Systems
	Intended status: Standards Track May 29, 2012		Intended status: Standards Track June 2, 2012
	Expires: November 30, 2012		Expires: December 4, 2012
	The Generalized TTL Security Mechanism (GTSM) for Label Distribution		The Generalized TTL Security Mechanism (GTSM) for Label Distribution
	Protocol (LDP)		Protocol (LDP)
	draft-ietf-mpls-ldp-gtsm-07		draft-ietf-mpls-ldp-gtsm-08
	Abstract		Abstract
	The Generalized TTL Security Mechanism (GTSM) describes a generalized		The Generalized TTL Security Mechanism (GTSM) describes a generalized
	use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to		use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to
	verify that the packet was sourced by a node on a connected link,		verify that the packet was sourced by a node on a connected link,
	thereby protecting the router's IP control-plane from CPU utilization		thereby protecting the router's IP control-plane from CPU utilization
	based attacks. This technique improves security and is used by many		based attacks. This technique improves security and is used by many
	protocols. This document defines the GTSM use for the Label		protocols. This document defines the GTSM use for the Label
	Distribution Protocol (LDP).		Distribution Protocol (LDP).
	skipping to change at page 1, line 41 ¶		skipping to change at page 1, line 41 ¶
	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 November 30, 2012.		This Internet-Draft will expire on December 4, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2012 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 26 ¶		skipping to change at page 2, line 26 ¶
	1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . 4		1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. GTSM Procedures for LDP . . . . . . . . . . . . . . . . . . . . 4		2. GTSM Procedures for LDP . . . . . . . . . . . . . . . . . . . . 4
	2.1. GTSM Flag in Common Hello Parameter TLV . . . . . . . . . . 4		2.1. GTSM Flag in Common Hello Parameter TLV . . . . . . . . . . 4
	2.2. GTSM Sending and Receiving Procedures for LDP Link		2.2. GTSM Sending and Receiving Procedures for LDP Link
	Hello . . . . . . . . . . . . . . . . . . . . . . . . . . . 5		Hello . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	2.3. GTSM Sending and Receiving Procedures for LDP		2.3. GTSM Sending and Receiving Procedures for LDP
	Initialization . . . . . . . . . . . . . . . . . . . . . . 6		Initialization . . . . . . . . . . . . . . . . . . . . . . 6
	3. LDP Peering Scenarios and GTSM Considerations . . . . . . . . . 6		3. LDP Peering Scenarios and GTSM Considerations . . . . . . . . . 6
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
	5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7		5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
	6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7		6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8		7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	7.1. Normative References . . . . . . . . . . . . . . . . . . . 8		7.1. Normative References . . . . . . . . . . . . . . . . . . . 8
	7.2. Informative References . . . . . . . . . . . . . . . . . . 8		7.2. Informative References . . . . . . . . . . . . . . . . . . 8
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
	1. Introduction		1. Introduction
	LDP [RFC5036] specifies two peer discovery mechanisms, a Basic one		LDP [RFC5036] specifies two peer discovery mechanisms, a Basic one
	and an Extended one, both using UDP transport. The Basic Discovery		and an Extended one, both using UDP transport. The Basic Discovery
	mechanism is used to discover LDP peers that are directly connected		mechanism is used to discover LDP peers that are directly connected
	at the link level, whereas the Extended Discovery mechanism is used		at the link level, whereas the Extended Discovery mechanism is used
	to locate Label Switching Router (LSR) neighbors that are not		to locate Label Switching Router (LSR) neighbors that are not
	directly connected at the link level. Once discovered, the LSR		directly connected at the link level. Once discovered, the LSR
	neighbors can establish the LDP peering session, using the TCP		neighbors can establish the LDP peering session, using the TCP
	skipping to change at page 6, line 44 ¶		skipping to change at page 6, line 44 ¶
	3. LDP Peering Scenarios and GTSM Considerations		3. LDP Peering Scenarios and GTSM Considerations
	This section discusses GTSM considerations arising from the LDP		This section discusses GTSM considerations arising from the LDP
	peering scenarios used, including single-hop versus multi-hop LDP		peering scenarios used, including single-hop versus multi-hop LDP
	neighbors, as well as the use of LDP basic discovery versus extended		neighbors, as well as the use of LDP basic discovery versus extended
	discovery.		discovery.
	The reason that the GTSM capability negotiation is enabled for Basic		The reason that the GTSM capability negotiation is enabled for Basic
	Discovery by default (i.e.,g G=1), but not for Extended Discovery is		Discovery by default (i.e.,g G=1), but not for Extended Discovery is
	that the usage of Basic Discovery typically results in a single-hop		that the usage of Basic Discovery typically relates to a single-hop
	LDP peering session, whereas the usage of Extended Discovery		LDP peering session, whereas the usage of Extended Discovery
	typically results in a multi-hop LDP peering session. GTSM		typically relates to a multi-hop LDP peering session. GTSM
	protection for multi-hop LDP sessions is outside the scope of this		protection for multi-hop LDP sessions is outside the scope of this
	specification (see Section 1.2). However, it is worth clarifying the		specification (see Section 1.2). However, it is worth clarifying the
	following exceptions that may occur with Basic or Extended Discovery		following exceptions that may occur with Basic or Extended Discovery
	usage:		usage:
	a. Two adjacent LSRs (i.e., back-to-back PE routers) forming a		a. Two adjacent LSRs (i.e., back-to-back PE routers) forming a
	single-hop LDP peering session after doing an Extended Discovery		single-hop LDP peering session after doing an Extended Discovery
	(e.g., for Pseudowire signaling)		(e.g., for Pseudowire signaling)
	b. Two adjacent LSRs forming a multi-hop LDP peering session after		b. Two adjacent LSRs forming a multi-hop LDP peering session after
	skipping to change at page 7, line 46 ¶		skipping to change at page 7, line 46 ¶
	4. IANA Considerations		4. IANA Considerations
	This document has no IANA actions.		This document has no IANA actions.
	5. Security Considerations		5. Security Considerations
	This document increases the security for LDP, making it more		This document increases the security for LDP, making it more
	resilient to off-link attacks. Security considerations for GTSM are		resilient to off-link attacks. Security considerations for GTSM are
	detailed in Section 5 of [RFC5082].		detailed in Section 5 of [RFC5082].
			As discussed in Section 3, it is possible that
			o GTSM for LDP may not always be enforced on a single-hop LDP
			peering session and LDP may still be susceptible to forged/spoofed
			protocol packets, if a single-hop LDP peering session is set up
			using Extended Discovery.
			o GTSM for LDP may cause LDP peering session to not get established
			(or may be torn down), if IP routing ever declares that the
			directly connected peer is more than one IP hop away. Suffice to
			say, use of cryptographic integrity (e.g., [RFC5925]) is
			recommended as an alternate solution for detecting forged protocol
			packets (especially for the multi-hop case).
	6. Acknowledgments		6. Acknowledgments
	The authors of this document do not make any claims on the		The authors of this document do not make any claims on the
	originality of the ideas described. The concept of GTSM for LDP has		originality of the ideas described. The concept of GTSM for LDP has
	been proposed a number of times, and is documented in both the		been proposed a number of times, and is documented in both the
	Experimental and Standards Track specifications of GTSM. Among other		Experimental and Standards Track specifications of GTSM. Among other
	people, we would like to acknowledge Enke Chen and Albert Tian for		people, we would like to acknowledge Enke Chen and Albert Tian for
	their document "TTL-Based Security Option for the LDP Hello Message".		their document "TTL-Based Security Option for the LDP Hello Message".
	The authors would like to thank Loa Andersson, Bin Mo, Mach Chen,		The authors would like to thank Loa Andersson, Bin Mo, Mach Chen,
	Vero Zheng, Adrian Farrel, Eric Rosen, and Eric Gray for a thorough		Vero Zheng, Adrian Farrel, Eric Rosen, Eric Gray, and Brian Weis for
	review and most useful comments and suggestions.		a thorough review and most useful comments and suggestions.
	7. References		7. References
	7.1. Normative References		7.1. Normative References
	[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.
	[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP		[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
	Specification", RFC 5036, October 2007.		Specification", RFC 5036, October 2007.
	skipping to change at page 9, line 5 ¶		skipping to change at page 9, line 9 ¶
	(work in progress), January 2012.		(work in progress), January 2012.
	[LDP-SPROT]		[LDP-SPROT]
	Cisco Systems, Inc., "MPLS LDP Session Protection", <http:		Cisco Systems, Inc., "MPLS LDP Session Protection", <http:
	//www.cisco.com/en/US/docs/ios-xml/ios/mp_ldp/		//www.cisco.com/en/US/docs/ios-xml/ios/mp_ldp/
	configuration/12-4m/mp-ldp-sessn-prot.html>.		configuration/12-4m/mp-ldp-sessn-prot.html>.
	[RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP		[RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP
	Synchronization", RFC 5443, March 2009.		Synchronization", RFC 5443, March 2009.
			[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
			Authentication Option", RFC 5925, June 2010.
	Authors' Addresses		Authors' Addresses
	Carlos Pignataro		Carlos Pignataro
	Cisco Systems		Cisco Systems
	7200-12 Kit Creek Road		7200-12 Kit Creek Road
	Research Triangle Park, NC 27709		Research Triangle Park, NC 27709
	US		US
	Email: cpignata@cisco.com		Email: cpignata@cisco.com
End of changes. 10 change blocks.
	10 lines changed or deleted		27 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/