< draft-ietf-mpls-ldp-gtsm-06.txt		draft-ietf-mpls-ldp-gtsm-07.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 14, 2012		Intended status: Standards Track May 29, 2012
	Expires: November 15, 2012		Expires: November 30, 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-06		draft-ietf-mpls-ldp-gtsm-07
	Abstract		Abstract
	The Generalized TTL Security Mechanism (GTSM) describes a generalized		The Generalized TTL Security Mechanism (GTSM) describes a generalized
	use of a packets 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).
	This specification uses a bit reserved in RFC 5036 and therefore		This specification uses a bit reserved in RFC 5036 and therefore
	updates RFC 5036.		updates RFC 5036.
	Status of this Memo		Status of this Memo
	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 15, 2012.		This Internet-Draft will expire on November 30, 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 3, line 42 ¶		skipping to change at page 3, line 42 ¶
	3. Sending and Receiving procedures for LDP Initilization message		3. Sending and Receiving procedures for LDP Initilization message
	GTSM specifies that "it SHOULD NOT be enabled by default in order to		GTSM specifies that "it SHOULD NOT be enabled by default in order to
	remain backward-compatible with the unmodified protocol" (see Section		remain backward-compatible with the unmodified protocol" (see Section
	3 of [RFC5082]). This document specifies a "built-in dynamic GTSM		3 of [RFC5082]). This document specifies a "built-in dynamic GTSM
	capability negotiation" for LDP to suggest the use of GTSM. GTSM		capability negotiation" for LDP to suggest the use of GTSM. GTSM
	will be used as specified in this document provided both peers on an		will be used as specified in this document provided both peers on an
	LDP session can detect each others' support for GTSM procedures and		LDP session can detect each others' support for GTSM procedures and
	agree to use it. That is, the desire to use GTSM (i.e., its		agree to use it. That is, the desire to use GTSM (i.e., its
	negotiation mechanics) is enabled by default.		negotiation mechanics) is enabled by default without any
			configuration.
	This specification uses a bit reserved in Section 3.5.2 of [RFC5036]		This specification uses a bit reserved in Section 3.5.2 of [RFC5036]
	and therefore updates [RFC5036].		and therefore updates [RFC5036].
	1.1. Specification of Requirements		1.1. Specification of Requirements
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	skipping to change at page 5, line 29 ¶		skipping to change at page 5, line 29 ¶
	G, GTSM		G, GTSM
	A value of 1 specifies that this LSR supports GTSM procedures,		A value of 1 specifies that this LSR supports GTSM procedures,
	where a value of 0 specifies that this LSR does not support GTSM.		where a value of 0 specifies that this LSR does not support GTSM.
	Reserved		Reserved
	This field is reserved. It MUST be set to zero on transmission		This field is reserved. It MUST be set to zero on transmission
	and ignored on receipt.		and ignored on receipt.
	Figure 1: GTSM Flag in Common Hello Parameter TLV		Figure 1: GTSM Flag in Common Hello Parameter TLV
	The G flag is meaingful only if the T flag is set to 0 (which must be		The G flag is meaningful only if the T flag is set to 0 (which must
	the case for Basic Discovery), otherwise, the value of G flag SHOULD		be the case for Basic Discovery), otherwise, the value of G flag
	be ignored on receipt.		SHOULD be ignored on receipt.
	Any LSR not supporting GTSM for LDP as defined in this document		Any LSR not supporting GTSM for LDP as defined in this document
	(i.e., an LSR that does not recognize the G flag), would continue to		(i.e., an LSR that does not recognize the G flag), would continue to
	ignore the G flag, independent of T and R flags' value, as per		ignore the G flag, independent of T and R flags' value, as per
	Section 3.5.2 of [RFC5036]. Similarly, an LSR that does recognize		Section 3.5.2 of [RFC5036]. Similarly, an LSR that does recognize
	the G flag but that it does not support GTSM (either because it is		the G flag but that does not support GTSM (either because it is not
	not implemented, or because it is so configured), would clear the G		implemented, or because it is so configured), would not set the G
	flag (i.e.,g G=0) on send and would effectively ignore the G flag on		flag (i.e.,g G=0) when sending LDP Link hellos and would effectively
	receipt.		ignore the G flag when receiving LDP Link hello messages.
	2.2. GTSM Sending and Receiving Procedures for LDP Link Hello		2.2. GTSM Sending and Receiving Procedures for LDP Link Hello
	Firstly, LSRs using LDP Basic Discovery [RFC5036] send LDP Hello		Firstly, LSRs using LDP Basic Discovery [RFC5036] send LDP Hello
	messages to link-level multicast address (224.0.0.2 or "all		messages to link-level multicast address (224.0.0.2 or "all
	routers"). Such messages are never forwarded beyond one hop and		routers"). Such messages are never forwarded beyond one hop and
	RECOMMENDED to have their IP TTL or Hop Count = 1.		RECOMMENDED to have their IP TTL or Hop Count = 1.
	Unless configured otherwise, an LSR that supports GTSM procedures		Unless configured otherwise, an LSR that supports GTSM procedures
	MUST set the G flag (for GTSM) to 1 in Common Hello Parameter TLV in		MUST set the G flag (for GTSM) to 1 in Common Hello Parameter TLV in
	skipping to change at page 8, line 10 ¶		skipping to change at page 8, line 10 ¶
	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, and Eric Rosen for a thorough review and		Vero Zheng, Adrian Farrel, Eric Rosen, and Eric Gray for a thorough
	most useful comments and suggestions.		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.
End of changes. 8 change blocks.
	15 lines changed or deleted		16 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/