< draft-ietf-mpls-ldp-gtsm-03.txt		draft-ietf-mpls-ldp-gtsm-04.txt >
	MPLS Working Group C. Pignataro		MPLS Working Group C. Pignataro
	Internet-Draft R. Asati		Internet-Draft R. Asati
	Intended status: Standards Track Cisco Systems		Updates: 5036 (if approved) Cisco Systems
	Expires: February 27, 2012 August 26, 2011		Intended status: Standards Track November 13, 2011
			Expires: May 16, 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-03		draft-ietf-mpls-ldp-gtsm-04
	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 packets 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 Label Distribution		protocols. This document defines the GTSM use for Label Distribution
	Protocol (LDP).		Protocol (LDP).
			This specification uses a bit reserved in RFC 5036 and therefore
			updates RFC 5036.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 February 27, 2012.		This Internet-Draft will expire on May 16, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2011 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Specification of Requirements . . . . . . . . . . . . . . . 3		1.1. Specification of Requirements . . . . . . . . . . . . . . . 3
	1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . 3		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 . . . . . . . . . . . . . . . . . . . . . . 5		Initialization . . . . . . . . . . . . . . . . . . . . . . 5
	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 . . . . . . . . . . . . . . . . . . . . . . . . 7
	skipping to change at page 3, line 41 ¶		skipping to change at page 3, line 41 ¶
	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; this		remain backward-compatible with the unmodified protocol; this
	document specifies having a built-in dynamic GTSM capability		document specifies having a built-in dynamic GTSM capability
	negotiation for LDP to suggest the use of GTSM, provided GTSM is not		negotiation for LDP to suggest the use of GTSM, provided GTSM is not
	enabled unless both peers can detect each others' support for GTSM		enabled unless both peers can detect each others' support for GTSM
	procedures and agree on its usage as described in this document.		procedures and agree on its usage as described in this document.
			This specification uses a bit reserved in Section 3.5.2 of [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].
	1.2. Scope		1.2. Scope
	This document defines procedures for LDP using IPv4 routing, but not		This document defines procedures for LDP using IPv4 routing, but not
	for LDP using IPv6 routing, since the latter has GTSM built into the		for LDP using IPv6 routing, since the latter has GTSM built into the
	skipping to change at page 4, line 17 ¶		skipping to change at page 4, line 23 ¶
	peering sessions, in line with Section 5.5 of [RFC5082].		peering sessions, in line with Section 5.5 of [RFC5082].
	Consequently, any LDP method or feature that relies on multi-hop LDP		Consequently, any LDP method or feature that relies on multi-hop LDP
	peering sessions would not work with GTSM and will require		peering sessions would not work with GTSM and will require
	(statically or dynamically) disabling GTSM. See Section 3.		(statically or dynamically) disabling GTSM. See Section 3.
	2. GTSM Procedures for LDP		2. GTSM Procedures for LDP
	2.1. GTSM Flag in Common Hello Parameter TLV		2.1. GTSM Flag in Common Hello Parameter TLV
	A new flag in Common Hello Parameter TLV, named G flag (for GTSM), is		A new flag in Common Hello Parameter TLV, named G flag (for GTSM), is
	defined by this document. An LSR indicates that it is capable of		defined by this document in a previously reserved bit. An LSR
	applying GTSM procedures, as defined in this document, to the		indicates that it is capable of applying GTSM procedures, as defined
	subsequent LDP peering session, by setting the GTSM flag to 1. The		in this document, to the subsequent LDP peering session, by setting
	Common Hello Parameters TLV, defined in Section 3.5.2 of [RFC5036],		the GTSM flag to 1. The Common Hello Parameters TLV, defined in
	is updated as shown in Figure 1.		Section 3.5.2 of [RFC5036], is updated as shown in Figure 1.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|0|0| Common Hello Parms(0x0400)| Length |		|0|0| Common Hello Parms(0x0400)| Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Hold Time |T|R|G| Reserved |		| Hold Time |T|R|G| Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	T, Targeted Hello		T, Targeted Hello
	skipping to change at page 7, line 7 ¶		skipping to change at page 7, line 12 ¶
	GTSM. Otherwise, GTSM would not be enforced on the second LDP		GTSM. Otherwise, GTSM would not be enforced on the second LDP
	peering session corresponding to the Extended Discovery.		peering session corresponding to the Extended Discovery.
	This document allows for the implementation to provide an option to		This document allows for the implementation to provide an option to
	statically (e.g., via configuration) and/or dynamically override the		statically (e.g., via configuration) and/or dynamically override the
	default behavior and enable/disable GTSM on a per-peer basis. This		default behavior and enable/disable GTSM on a per-peer basis. This
	would address all the exceptions listed above.		would address all the exceptions listed above.
	4. IANA Considerations		4. IANA Considerations
	IANA is requested to assign the G, GTSM bit in the Common Hello		This document has no IANA actions.
	Parameters TLV (see Figure 1 in Section 2.1), as per allocation
	policy defined at [I-D.ietf-mpls-ldp-iana].
	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.		resilient to off-link attacks.
	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, and		The authors would like to thank Loa Andersson, Bin Mo, Mach Chen,
	Vero Zheng for a thorough review and most useful comments and		Vero Zheng, Adrian Farrel, and Eric Rosen for a thorough review and
	suggestions.		most useful comments and suggestions.
	7. References		7. References
	7.1. Normative References		7.1. Normative References
	[I-D.ietf-mpls-ldp-iana]
	Pignataro, C. and R. Asati, "Label Distribution Protocol
	(LDP) Internet Assigned Numbers Authority (IANA)
	Considerations Update", draft-ietf-mpls-ldp-iana-01 (work
	in progress), May 2011.
	[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.
	[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C.		[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C.
	Pignataro, "The Generalized TTL Security Mechanism		Pignataro, "The Generalized TTL Security Mechanism
	(GTSM)", RFC 5082, October 2007.		(GTSM)", RFC 5082, October 2007.
End of changes. 10 change blocks.
	22 lines changed or deleted		21 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/