< draft-ietf-mpls-ldp-gtsm-05.txt		draft-ietf-mpls-ldp-gtsm-06.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 April 11, 2012		Intended status: Standards Track May 14, 2012
	Expires: October 13, 2012		Expires: November 15, 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-05		draft-ietf-mpls-ldp-gtsm-06
	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 the Label
	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
	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 October 13, 2012.		This Internet-Draft will expire on November 15, 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 11 ¶		skipping to change at page 3, line 11 ¶
	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 . . . . . . . . . . . . . . . . . . . . . . . . 8
	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 LSR neighbors that are not directly connected at the link		to locate Label Switching Router (LSR) neighbors that are not
	level. Once discovered, the LSR neighbors can establish the LDP		directly connected at the link level. Once discovered, the LSR
	peering session, using the TCP transport connection.		neighbors can establish the LDP peering session, using the TCP
			transport connection.
	The Generalized TTL Security Mechanism (GTSM) [RFC5082] is a		The Generalized TTL Security Mechanism (GTSM) [RFC5082] is a
	mechanism based on IPv4 Time To Live (TTL) or (IPv6) Hop Limit value		mechanism based on IPv4 Time To Live (TTL) or (IPv6) Hop Limit value
	verification so as to provide a simple and reasonably robust defense		verification so as to provide a simple and reasonably robust defense
	from infrastructure attacks using forged protocol packets from		from infrastructure attacks using forged protocol packets from
	outside the network. GTSM can be applied to any protocol peering		outside the network. GTSM can be applied to any protocol peering
	session that is established between routers that are adjacent.		session that is established between routers that are adjacent.
	Therefore, GTSM can fully benefit LDP protocol peering session		Therefore, GTSM can fully benefit LDP protocol peering session
	established using Basic Discovery.		established using Basic Discovery.
	This document specifies LDP enhancements to accommodate GTSM. In		This document specifies LDP enhancements to accommodate GTSM. In
	particular, this document specifies the enhancements in the following		particular, this document specifies the enhancements in the following
	areas:		areas:
	1. Common Hello Parameter TLV of LDP Link Hello message		1. Common Hello Parameter TLV of LDP Link Hello message
	2. Sending and Receiving procedures for LDP Link Hello message		2. Sending and Receiving procedures for LDP Link Hello message
	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" (see Section
	document specifies having a built-in dynamic GTSM capability		3 of [RFC5082]). This document specifies a "built-in dynamic GTSM
	negotiation for LDP to suggest the use of GTSM, provided GTSM is not		capability negotiation" for LDP to suggest the use of GTSM. GTSM
	enabled unless both peers can detect each others' support for GTSM		will be used as specified in this document provided both peers on an
	procedures and agree on its usage as described in this document.		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
			negotiation mechanics) is enabled by default.
	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 4, line 17 ¶		skipping to change at page 4, line 17 ¶
	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
	protocol definition [I-D.ietf-mpls-ldp-ipv6].		protocol definition [I-D.ietf-mpls-ldp-ipv6].
	Additionally, the GTSM for LDP specified in this document applies		Additionally, the GTSM for LDP specified in this document applies
	only to single-hop LDP peering sessions, and not to multi-hop LDP		only to single-hop LDP peering sessions, and not to multi-hop LDP
	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 (such as LDP IGP		Consequently, any LDP method or feature (such as LDP IGP
	Synchronization [RFC5443], or LDP Session Protection [LDP-SPROT])		Synchronization [RFC5443], or LDP Session Protection [LDP-SPROT])
	that relies on multi-hop LDP peering sessions would not work with		that relies on multi-hop LDP peering sessions would not work with
	GTSM and will require (statically or dynamically) disabling GTSM.		GTSM and will require (statically or dynamically) disabling the GTSM
	See Section 3.		capability. 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 in a previously reserved bit. An LSR		defined by this document in a previously reserved bit. An LSR
	indicates that it is capable of applying GTSM procedures, as defined		indicates that it is capable of applying GTSM procedures, as defined
	in this document, to the subsequent LDP peering session, by setting		in this document, to the subsequent LDP peering session, by setting
	the GTSM flag to 1. The Common Hello Parameters TLV, defined in		the GTSM flag to 1. The Common Hello Parameters TLV, defined in
	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 T and R flags are set to 0 (which		The G flag is meaingful only if the T flag is set to 0 (which must be
	must be the case for Basic Discovery), otherwise, the value of G flag		the case for Basic Discovery), otherwise, the value of G flag SHOULD
	SHOULD be ignored on receipt.		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
	would continue to ignore the G flag, independent of T and R flags'		(i.e., an LSR that does not recognize the G flag), would continue to
	value, as per Section 3.5.2 of [RFC5036].		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
			the G flag but that it does not support GTSM (either because it is
			not implemented, or because it is so configured), would clear the G
			flag (i.e.,g G=0) on send and would effectively ignore the G flag on
			receipt.
	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
	assumed to have their IP TTL or Hop Count = 1.		RECOMMENDED to have their IP TTL or Hop Count = 1.
	An LSR that is capable of applying GTSM procedures to the subsequent		Unless configured otherwise, an LSR that supports GTSM procedures
	TCP/LDP peering session MUST set the G flag (for GTSM) to 1 in Common		MUST set the G flag (for GTSM) to 1 in Common Hello Parameter TLV in
	Hello Parameter TLV in the LDP Link Hello message [RFC5036].		the LDP Link Hello message [RFC5036].
	An LSR, upon receiving an LDP Link Hello message, would recognize the		If an LSR that supports GTSM and is configured to use it recognizes
	presence of G flag (in Common Hello Parameter TLV) only if it		the presence of G flag (in Common Hello Parameter TLV) with the value
	supports GTSM for LDP, as specified in this document. If an LSR		=1 in the received LDP Link Hello message, then it MUST enforce GTSM
	recognizes the presence of G flag with the value =1 in the received		for LDP in the subsequent TCP/LDP peering session with the neighbor
	LDP Link Hello message, then it MUST enforce GTSM for LDP in the		that sent the Hello message, as specified in Section 2.3 of this
	subsequent TCP/LDP peering session with the neighbor that sent the		document.
	Hello message, as specified in Section 2.3 of this document.
	If an LSR does not recognize the presence of G flag (in Common Hello		If an LSR does not recognize the presence of G flag (in Common Hello
	Parameter TLV of Link Hello message), or recognizes the presence of G		Parameter TLV of Link Hello message), or recognizes the presence of G
	flag with the value = 0, then the LSR MUST NOT enforce GTSM for LDP		flag with the value = 0, then the LSR MUST NOT enforce GTSM for LDP
	in the subsequent TCP/LDP peering session with the neighbor that sent		in the subsequent TCP/LDP peering session with the neighbor that sent
	the Hello message. This ensures backward compatibility as well as		the Hello message. This ensures backward compatibility as well as
	automatic GTSM de-activation.		automatic GTSM de-activation.
	If an LSR that has sent the LDP Link Hello with G flag = 1, then the
	LSR MUST set IP TTL or Hop Count = 255 in the forthcoming TCP
	Transport Connection(s) with that neighbor (e.g., LSR2). Please see
	Section 2.3 for more details about the TCP transport connection
	specifics.
	2.3. GTSM Sending and Receiving Procedures for LDP Initialization		2.3. GTSM Sending and Receiving Procedures for LDP Initialization
	If an LSR that has sent and received LDP Link Hello with G flag = 1		If an LSR that has sent and received LDP Link Hello with G flag = 1
	from the directly-connected neighbor (LSR2), then the LSR MUST		from the directly-connected neighbor, then the LSR MUST enforce GTSM
	enforce GTSM procedures, as defined in Section 3 of [RFC5082], in the		procedures, as defined in Section 3 of [RFC5082], in the forthcoming
	forthcoming TCP Transport Connection with that neighbor (LSR2). This		TCP Transport Connection with that neighbor. This means that the LSR
	means that the LSR MUST check for the incoming unicast packets' TTL		MUST check for the incoming unicast packets' TTL or Hop Count to be
	or Hop Count to be 255 for the particular LDP/TCP peering session and		255 for the particular LDP/TCP peering session and decide the further
	decide the further processing as per the [RFC5082].		processing as per the [RFC5082].
	If an LSR that has sent LDP Link Hello with G flag = 1, but received		If an LSR that has sent LDP Link Hello with G flag = 1, but received
	LDP Link Hello with G flag = 0 from the directly-connected neighbor		LDP Link Hello with G flag = 0 from the directly-connected neighbor,
	(LSR2), then the LSR MUST NOT enforce GTSM procedures, as defined in		then the LSR MUST NOT enforce GTSM procedures, as defined in Section
	Section 3 of [RFC5082], in the forthcoming TCP Transport Connection		3 of [RFC5082], in the forthcoming TCP Transport Connection with that
	with that neighbor (LSR2).		neighbor.
	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 GTSM is enabled for Basic Discovery by default, but not		The reason that the GTSM capability negotiation is enabled for Basic
	for Extended Discovery is that the usage of Basic Discovery typically		Discovery by default (i.e.,g G=1), but not for Extended Discovery is
	results in a single-hop LDP peering session, whereas the usage of		that the usage of Basic Discovery typically results in a single-hop
	Extended Discovery typically results in a multi-hop LDP peering		LDP peering session, whereas the usage of Extended Discovery
	session. GTSM protection for multi-hop LDP sessions is outside the		typically results in a multi-hop LDP peering session. GTSM
	scope of this specification (see Section 1.2). However, it is worth		protection for multi-hop LDP sessions is outside the scope of this
	clarifying the following exceptions that may occur with Basic or		specification (see Section 1.2). However, it is worth clarifying the
	Extended Discovery usage:		following exceptions that may occur with Basic or Extended Discovery
			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
	doing a Basic Discovery, due to the way IP routing is setup		doing a Basic Discovery, due to the way IP routing is setup
	between them (either temporarily or permanently)		between them (either temporarily or permanently)
	c. Two adjacent LSRs (i.e. back-to-back PE routers) forming a		c. Two adjacent LSRs (i.e. back-to-back PE routers) forming a
	single-hop LDP peering session after doing both Basic and		single-hop LDP peering session after doing both Basic and
	Extended Discovery.		Extended Discovery.
	In the first case (a), GTSM is not enabled for the LDP peering		In the first case (a), GTSM is not enabled for the LDP peering
	session by default. In the second case (b), GTSM is actually enabled		session by default. In the second case (b), GTSM is actually enabled
	by default and enforced for the LDP peering session, and hence, it		by default and enforced for the LDP peering session, and hence, it
	would prohibit the LDP peering session from getting established (note		would prohibit the LDP peering session from getting established (note
	that this may impact features such as LDP IGP Synchronization		that this may impact features such as LDP IGP Synchronization
	[RFC5443], or LDP Session Protection [LDP-SPROT]). en the third case		[RFC5443], or LDP Session Protection [LDP-SPROT]). In the third case
	(c), GTSM is enabled by default for Basic Discovery and enforced on		(c), GTSM is enabled by default for Basic Discovery and enforced on
	the subsequent LDP peering, and not for Extended Discovery. However,		the subsequent LDP peering, and not for Extended Discovery. However,
	if each LSR uses the same IPv4 transport address object value in both		if each LSR uses the same IPv4 transport address object value in both
	Basic and Extended discoveries, then it would result in a single LDP		Basic and Extended discoveries, then it would result in a single LDP
	peering session and that would be enabled with GTSM. Otherwise, GTSM		peering session and that would be enabled with GTSM. Otherwise, GTSM
	would not be enforced on the second LDP peering session corresponding		would not be enforced on the second LDP peering session corresponding
	to the Extended Discovery.		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
	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.		resilient to off-link attacks. Security considerations for GTSM are
			detailed in Section 5 of [RFC5082].
	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".
End of changes. 18 change blocks.
	60 lines changed or deleted		63 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/