draft-ietf-rtgwg-rfc3682bis-10.txt		rfc5082.txt
	Routing WG V. Gill		Network Working Group V. Gill
	Internet-Draft J. Heasley		Request for Comments: 5082 J. Heasley
	Obsoletes: 3682 (if approved) D. Meyer		Obsoletes: 3682 D. Meyer
	Intended status: Standards Track P. Savola, Ed.		Category: Standards Track P. Savola, Ed.
	Expires: December 27, 2007 C. Pignataro		C. Pignataro
	June 25, 2007		October 2007
	The Generalized TTL Security Mechanism (GTSM)		The Generalized TTL Security Mechanism (GTSM)
	draft-ietf-rtgwg-rfc3682bis-10.txt
	Status of this Memo
	By submitting this Internet-Draft, each author represents that any
	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
	aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-
	Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Status of This Memo
	and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on December 27, 2007.
	Copyright Notice
	Copyright (C) The IETF Trust (2007).		This document specifies an Internet standards track protocol for the
			Internet community, and requests discussion and suggestions for
			improvements. Please refer to the current edition of the "Internet
			Official Protocol Standards" (STD 1) for the standardization state
			and status of this protocol. Distribution of this memo is unlimited.
	Abstract		Abstract
	The use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6)		The use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6)
	to verify whether the packet was originated by an adjacent node on a		to verify whether the packet was originated by an adjacent node on a
	connected link has been used in many recent protocols. This document		connected link has been used in many recent protocols. This document
	generalizes this technique. This document obsoletes Experimental RFC		generalizes this technique. This document obsoletes Experimental RFC
	3682.		3682.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Assumptions Underlying GTSM . . . . . . . . . . . . . . . . . 3		2. Assumptions Underlying GTSM . . . . . . . . . . . . . . . . . 3
	2.1. GTSM Negotiation . . . . . . . . . . . . . . . . . . . . . 4		2.1. GTSM Negotiation . . . . . . . . . . . . . . . . . . . . . 4
	2.2. Assumptions on Attack Sophistication . . . . . . . . . . . 4		2.2. Assumptions on Attack Sophistication . . . . . . . . . . . 4
	3. GTSM Procedure . . . . . . . . . . . . . . . . . . . . . . . . 5		3. GTSM Procedure . . . . . . . . . . . . . . . . . . . . . . . . 5
	4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7		4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 7		5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
	5.1. TTL (Hop Limit) Spoofing . . . . . . . . . . . . . . . . . 7		5.1. TTL (Hop Limit) Spoofing . . . . . . . . . . . . . . . . . 7
	5.2. Tunneled Packets . . . . . . . . . . . . . . . . . . . . . 7		5.2. Tunneled Packets . . . . . . . . . . . . . . . . . . . . . 7
	5.2.1. IP Tunneled over IP . . . . . . . . . . . . . . . . . 8		5.2.1. IP Tunneled over IP . . . . . . . . . . . . . . . . . 8
	5.2.2. IP Tunneled over MPLS . . . . . . . . . . . . . . . . 9		5.2.2. IP Tunneled over MPLS . . . . . . . . . . . . . . . . 9
	5.3. Onlink Attackers . . . . . . . . . . . . . . . . . . . . . 11		5.3. Onlink Attackers . . . . . . . . . . . . . . . . . . . . . 11
	5.4. Fragmentation Considerations . . . . . . . . . . . . . . . 11		5.4. Fragmentation Considerations . . . . . . . . . . . . . . . 11
	5.5. Multi-Hop Protocol Sessions . . . . . . . . . . . . . . . 12		5.5. Multi-Hop Protocol Sessions . . . . . . . . . . . . . . . 12
	6. Applicability Statement . . . . . . . . . . . . . . . . . . . 12		6. Applicability Statement . . . . . . . . . . . . . . . . . . . 12
	6.1. Backwards Compatibility . . . . . . . . . . . . . . . . . 13		6.1. Backwards Compatibility . . . . . . . . . . . . . . . . . 12
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13		7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13		7.1. Normative References . . . . . . . . . . . . . . . . . . . 13
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 13		7.2. Informative References . . . . . . . . . . . . . . . . . . 14
	8.2. Informative References . . . . . . . . . . . . . . . . . . 14		Appendix A. Multi-Hop GTSM . . . . . . . . . . . . . . . . . . . 15
	Appendix A. Multi-hop GTSM . . . . . . . . . . . . . . . . . . . 15
	Appendix B. Changes Since RFC3682 . . . . . . . . . . . . . . . 15		Appendix B. Changes Since RFC3682 . . . . . . . . . . . . . . . 15
	Appendix C. Draft Changelog . . . . . . . . . . . . . . . . . . 15
	Appendix C.1. Changes between -09 and -10 . . . . . . . . . . . . 15
	Appendix C.2. Changes between -08 and -09 . . . . . . . . . . . . 16
	Appendix C.3. Changes between -07 and -08 . . . . . . . . . . . . 16
	Appendix C.4. Changes between -06 and -07 . . . . . . . . . . . . 16
	Appendix C.5. Changes between -05 and -06 . . . . . . . . . . . . 17
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
	Intellectual Property and Copyright Statements . . . . . . . . . . 18
	1. Introduction		1. Introduction
	The Generalized TTL Security Mechanism (GTSM) is designed to protect		The Generalized TTL Security Mechanism (GTSM) is designed to protect
	a router's IP based control plane from CPU-utilization based attacks.		a router's IP-based control plane from CPU-utilization based attacks.
	In particular, while cryptographic techniques can protect the router-		In particular, while cryptographic techniques can protect the router-
	based infrastructure (e.g., BGP [RFC4271], [RFC4272]) from a wide		based infrastructure (e.g., BGP [RFC4271], [RFC4272]) from a wide
	variety of attacks, many attacks based on CPU overload can be		variety of attacks, many attacks based on CPU overload can be
	prevented by the simple mechanism described in this document. Note		prevented by the simple mechanism described in this document. Note
	that the same technique protects against other scarce-resource		that the same technique protects against other scarce-resource
	attacks involving a router's CPU, such as attacks against processor-		attacks involving a router's CPU, such as attacks against processor-
	line card bandwidth.		line card bandwidth.
	GTSM is based on the fact that the vast majority of protocol peerings		GTSM is based on the fact that the vast majority of protocol peerings
	are established between routers that are adjacent. Thus most		are established between routers that are adjacent. Thus, most
	protocol peerings are either directly between connected interfaces or		protocol peerings are either directly between connected interfaces
	at the worst case, are between loopback and loopback, with static		or, in the worst case, are between loopback and loopback, with static
	routes to loopbacks. Since TTL spoofing is considered nearly		routes to loopbacks. Since TTL spoofing is considered nearly
	impossible, a mechanism based on an expected TTL value can provide a		impossible, a mechanism based on an expected TTL value can provide a
	simple and reasonably robust defense from infrastructure attacks		simple and reasonably robust defense from infrastructure attacks
	based on forged protocol packets from outside the network. Note,		based on forged protocol packets from outside the network. Note,
	however, that GTSM is not a substitute for authentication mechanisms.		however, that GTSM is not a substitute for authentication mechanisms.
	In particular, it does not secure against insider on-the-wire		In particular, it does not secure against insider on-the-wire
	attacks, such as packet spoofing or replay.		attacks, such as packet spoofing or replay.
	Finally, the GTSM mechanism is equally applicable to both TTL (IPv4)		Finally, the GTSM mechanism is equally applicable to both TTL (IPv4)
	and Hop Limit (IPv6), and from the perspective of GTSM, TTL and Hop		and Hop Limit (IPv6), and from the perspective of GTSM, TTL and Hop
	skipping to change at page 4, line 15		skipping to change at page 3, line 37
	3. Use of GTSM is OPTIONAL, and can be configured on a per-peer		3. Use of GTSM is OPTIONAL, and can be configured on a per-peer
	(group) basis.		(group) basis.
	4. The peer routers both implement GTSM.		4. The peer routers both implement GTSM.
	5. The router supports a method to use separate resource pools		5. The router supports a method to use separate resource pools
	(e.g., queues, processing quotas) for differently classified		(e.g., queues, processing quotas) for differently classified
	traffic.		traffic.
	Note that this document does not prescribe further restrictions that		Note that this document does not prescribe further restrictions that
	a router may apply to the packets not matching the GTSM filtering		a router may apply to packets not matching the GTSM filtering rules,
	rules, such as dropping packets that do not match any configured		such as dropping packets that do not match any configured protocol
	protocol session and rate-limiting the rest. This document also does		session and rate-limiting the rest. This document also does not
	not suggest the actual means of resource separation, as those are		suggest the actual means of resource separation, as those are
	hardware and implementation-specific.		hardware and implementation-specific.
	The possibility of denial-of-service (DoS) attack prevention,		However, the possibility of denial-of-service (DoS) attack prevention
	however, is based on the assumption that classification of packets		is based on the assumption that classification of packets and
	and separation of their paths are done before they go through a		separation of their paths are done before the packets go through a
	scarce resource in the system. In practice, this means that, the		scarce resource in the system. In practice, the closer GTSM
	closer GTSM processing is done to the line-rate hardware, the more		processing is done to the line-rate hardware, the more resistant the
	resistant the system is to the DoS attacks.		system is to DoS attacks.
	2.1. GTSM Negotiation		2.1. GTSM Negotiation
	This document assumes that, when used with existing protocols, GTSM		This document assumes that, when used with existing protocols, GTSM
	will be manually configured between protocol peers. That is, no		will be manually configured between protocol peers. That is, no
	automatic GTSM capability negotiation, such as is provided by RFC		automatic GTSM capability negotiation, such as is provided by RFC
	3392 [RFC3392] is assumed or defined.		3392 [RFC3392], is assumed or defined.
	If a new protocol is designed with built-in GTSM support, then it is		If a new protocol is designed with built-in GTSM support, then it is
	recommended that procedures are always used for sending and		recommended that procedures are always used for sending and
	validating received protocol packets (GTSM is always on, see for		validating received protocol packets (GTSM is always on, see for
	example [RFC2461]). If, however, dynamic negotiation of GTSM support		example [RFC2461]). If, however, dynamic negotiation of GTSM support
	is necessary, protocol messages used for such negotiation MUST be		is necessary, protocol messages used for such negotiation MUST be
	authenticated using other security mechanisms to prevent DoS attacks.		authenticated using other security mechanisms to prevent DoS attacks.
	Also note that this specification does not offer a generic GTSM		Also note that this specification does not offer a generic GTSM
	capability negotiation mechanism, so messages of the protocol		capability negotiation mechanism, so messages of the protocol
	augmented with the GTSM behavior will need to be used if dynamic		augmented with the GTSM behavior will need to be used if dynamic
	negotiation is deemed necessary.		negotiation is deemed necessary.
	2.2. Assumptions on Attack Sophistication		2.2. Assumptions on Attack Sophistication
	Throughout this document, we assume that potential attackers have		Throughout this document, we assume that potential attackers have
	evolved in both sophistication and access to the point that they can		evolved in both sophistication and access to the point that they can
	send control traffic to a protocol session, and that this traffic		send control traffic to a protocol session, and that this traffic
	appears to be valid control traffic (i.e., has the source/destination		appears to be valid control traffic (i.e., it has the source/
	of configured peer routers).		destination of configured peer routers).
	We also assume that each router in the path between the attacker and		We also assume that each router in the path between the attacker and
	the victim protocol speaker decrements TTL properly (clearly, if		the victim protocol speaker decrements TTL properly (clearly, if
	either the path or the adjacent peer is compromised, then there are		either the path or the adjacent peer is compromised, then there are
	worse problems to worry about).		worse problems to worry about).
	For maximal protection, ingress filtering should be applied before		For maximal protection, ingress filtering should be applied before
	the packet goes through the scarce resource. Otherwise an attacker		the packet goes through the scarce resource. Otherwise an attacker
	directly connected to one interface could disturb a GTSM-protected		directly connected to one interface could disturb a GTSM-protected
	session on the same or another interface. Interfaces which aren't		session on the same or another interface. Interfaces that aren't
	configured with this filtering (e.g., backbone links) are assumed to		configured with this filtering (e.g., backbone links) are assumed to
	not have such attackers (i.e., are trusted).		not have such attackers (i.e., are trusted).
	As a specific instance of such interfaces, we assume that tunnels are		As a specific instance of such interfaces, we assume that tunnels are
	not a back-door for allowing TTL-spoofing on protocol packets for a		not a back-door for allowing TTL-spoofing on protocol packets to a
	GTSM-protected peering session with a directly connected neighbor.		GTSM-protected peering session with a directly connected neighbor.
	We assume that: 1) there are no tunneled packets terminating on the		We assume that: 1) there are no tunneled packets terminating on the
	router, 2) tunnels terminating on the router are assumed to be secure		router, 2) tunnels terminating on the router are assumed to be secure
	and endpoints are trusted, 3) tunnel decapsulation includes source		and endpoints are trusted, 3) tunnel decapsulation includes source
	address spoofing prevention [RFC3704], or 4) the GTSM-enabled session		address spoofing prevention [RFC3704], or 4) the GTSM-enabled session
	does not allow protocol packets coming from a tunnel.		does not allow protocol packets coming from a tunnel.
	Since the vast majority of peerings are between adjacent routers, we		Since the vast majority of peerings are between adjacent routers, we
	can set the TTL on the protocol packets to 255 (the maximum possible		can set the TTL on the protocol packets to 255 (the maximum possible
	for IP) and then reject any protocol packets that come in from		for IP) and then reject any protocol packets that come in from
	configured peers which do NOT have an inbound TTL of 255.		configured peers that do NOT have an inbound TTL of 255.
	GTSM can be disabled for applications such as route-servers and other		GTSM can be disabled for applications such as route-servers and other
	multi-hop peerings. In the event that an attack comes in from a		multi-hop peerings. In the event that an attack comes in from a
	compromised multi-hop peering, that peering can be shut down.		compromised multi-hop peering, that peering can be shut down.
	3. GTSM Procedure		3. GTSM Procedure
	If GTSM is not built into the protocol and is used as an additional		If GTSM is not built into the protocol and is used as an additional
	feature (e.g., for BGP, LDP, or MSDP), it SHOULD NOT be enabled by		feature (e.g., for BGP, LDP, or MSDP), it SHOULD NOT be enabled by
	default in order to be backward-compatible with the unmodified		default in order to remain backward-compatible with the unmodified
	protocol. However, if the protocol defines a built-in dynamic		protocol. However, if the protocol defines a built-in dynamic
	capability negotiation for GTSM, a protocol peer MAY suggest the use		capability negotiation for GTSM, a protocol peer MAY suggest the use
	of GTSM provided that GTSM would only be enabled if both peers agree		of GTSM provided that GTSM would only be enabled if both peers agree
	to use it.		to use it.
	If GTSM is enabled for a protocol session, the following steps are		If GTSM is enabled for a protocol session, the following steps are
	added to the IP packet sending and reception procedures:		added to the IP packet sending and reception procedures:
	Sending protocol packets:		Sending protocol packets:
	skipping to change at page 6, line 32		skipping to change at page 6, line 8
	any registered GTSM-enabled session, and hence GTSM cannot		any registered GTSM-enabled session, and hence GTSM cannot
	make any judgment on the level of risk associated with them.		make any judgment on the level of risk associated with them.
	+ Trusted: these are packets that have been identified as		+ Trusted: these are packets that have been identified as
	belonging to one of the GTSM-enabled sessions, and their TTL		belonging to one of the GTSM-enabled sessions, and their TTL
	values are within the expected range.		values are within the expected range.
	+ Dangerous: these are packets that have been identified as		+ Dangerous: these are packets that have been identified as
	belonging to one of the GTSM-enabled sessions, but their TTL		belonging to one of the GTSM-enabled sessions, but their TTL
	values are NOT within the expected range, and hence GTSM		values are NOT within the expected range, and hence GTSM
	believes there is a risk that the packets have been spoofed.		believes there is a risk that these packets have been
			spoofed.
	The exact policies applied to packets of different		The exact policies applied to packets of different
	classifications are not postulated in this document and are		classifications are not postulated in this document and are
	expected to be configurable. Configurability is likely		expected to be configurable. Configurability is likely
	necessary in particular with the treatment of related messages		necessary in particular with the treatment of related messages
	(ICMP errors). It should be noted that fragmentation may		(ICMP errors). It should be noted that fragmentation may
	restrict the amount of information available to the		restrict the amount of information available for
	classification.		classification.
	However, by default, the implementations:		However, by default, the implementations:
	+ SHOULD ensure that packets classified as Dangerous do not		+ SHOULD ensure that packets classified as Dangerous do not
	compete for resources with packets classified as Trusted or		compete for resources with packets classified as Trusted or
	Unknown.		Unknown.
	+ MUST NOT drop (as part of GTSM processing) packets		+ MUST NOT drop (as part of GTSM processing) packets
	classified as Trusted or Unknown.		classified as Trusted or Unknown.
	+ MAY drop packets classified as Dangerous.		+ MAY drop packets classified as Dangerous.
	4. Acknowledgments		4. Acknowledgments
	The use of the TTL field to protect BGP originated with many		The use of the TTL field to protect BGP originated with many
	different people, including Paul Traina and Jon Stewart. Ryan		different people, including Paul Traina and Jon Stewart. Ryan
	McDowell also suggested a similar idea. Steve Bellovin, Jay		McDowell also suggested a similar idea. Steve Bellovin, Jay
	Borkenhagen, Randy Bush, Alfred Hoenes, Vern Paxon, Robert Raszuk and		Borkenhagen, Randy Bush, Alfred Hoenes, Vern Paxon, Robert Raszuk,
	Alex Zinin also provided useful feedback on earlier versions of this		and Alex Zinin also provided useful feedback on earlier versions of
	document. David Ward provided insight on the generalization of the		this document. David Ward provided insight on the generalization of
	original BGP-specific idea. Alex Zinin, Alia Atlas, and John Scudder		the original BGP-specific idea. Alex Zinin, Alia Atlas, and John
	provided significant amount of feedback for the newer versions of the		Scudder provided a significant amount of feedback for the newer
	document. During and after the IETF Last Call, Francis Dupont, Sam		versions of the document. During and after the IETF Last Call,
	Hartman, Lars Eggert, and Ross Callon.		useful comments were provided by Francis Dupont, Sam Hartman, Lars
			Eggert, and Ross Callon.
	5. Security Considerations		5. Security Considerations
	GTSM is a simple procedure that protects single hop protocol		GTSM is a simple procedure that protects single-hop protocol
	sessions, except in those cases in which the peer has been		sessions, except in those cases in which the peer has been
	compromised. In particular, it does not protect against the wide		compromised. In particular, it does not protect against the wide
	range of on-the-wire attacks; protection from these attacks requires		range of on-the-wire attacks; protection from these attacks requires
	more rigorous security mechanisms.		more rigorous security mechanisms.
	5.1. TTL (Hop Limit) Spoofing		5.1. TTL (Hop Limit) Spoofing
	The approach described here is based on the observation that a TTL		The approach described here is based on the observation that a TTL
	(or Hop Limit) value of 255 is non-trivial to spoof, since as the		(or Hop Limit) value of 255 is non-trivial to spoof, since as the
	packet passes through routers towards the destination, the TTL is		packet passes through routers towards the destination, the TTL is
	skipping to change at page 8, line 11		skipping to change at page 7, line 37
	authentication at the tunnel endpoints, as well as how the tunneled		authentication at the tunnel endpoints, as well as how the tunneled
	packets are protected in flight. Such mechanisms are, however,		packets are protected in flight. Such mechanisms are, however,
	beyond the scope of this memo.		beyond the scope of this memo.
	An exception to the observation that a packet with TTL of 255 is		An exception to the observation that a packet with TTL of 255 is
	difficult to spoof may occur when a protocol packet is tunneled and		difficult to spoof may occur when a protocol packet is tunneled and
	the tunnel is not integrity-protected (i.e., the lower layer is		the tunnel is not integrity-protected (i.e., the lower layer is
	compromised).		compromised).
	When the protocol packet is tunneled directly to the protocol peer		When the protocol packet is tunneled directly to the protocol peer
	(the protocol peer is the decapsulator), the GTSM provides some		(i.e., the protocol peer is the decapsulator), the GTSM provides some
	limited added protection as the security depends entirely on the		limited added protection as the security depends entirely on the
	integrity of the tunnel.		integrity of the tunnel.
	For protocol adjacencies over a tunnel, if the tunnel itself is		For protocol adjacencies over a tunnel, if the tunnel itself is
	deemed secure (e.g., the underlying infrastructure is deemed secure,		deemed secure (i.e., the underlying infrastructure is deemed secure,
	and the tunnel offers degrees of protection against spoofing such as		and the tunnel offers degrees of protection against spoofing such as
	keys or cryptographic security), the GTSM can serve as a check that		keys or cryptographic security), the GTSM can serve as a check that
	the protocol packet did not originate beyond the head-end of the		the protocol packet did not originate beyond the head-end of the
	tunnel. In addition, if the protocol peer can receive packets for		tunnel. In addition, if the protocol peer can receive packets for
	the GTSM-protected protocol session from outside the tunnel, the GTSM		the GTSM-protected protocol session from outside the tunnel, the GTSM
	can help thwart attacks from beyond the adjacent router.		can help thwart attacks from beyond the adjacent router.
	When the tunnel tail-end decapsulates the protocol packet and then		When the tunnel tail-end decapsulates the protocol packet and then
	IP-forwards the packet to a directly connected protocol peer, TTL is		IP-forwards the packet to a directly connected protocol peer, the TTL
	decremented as described below. This means that the tunnel		is decremented as described below. This means that the tunnel
	decapsulator is the penultimate node from the GTSM-protected protocol		decapsulator is the penultimate node from the GTSM-protected protocol
	peer's perspective. As a result, the GTSM check protects from		peer's perspective. As a result, the GTSM check protects from
	attackers encapsulating packets to your peers. However, specific		attackers encapsulating packets to your peers. However, specific
	cases arise when the connection from the tunnel decapsulator node to		cases arise when the connection from the tunnel decapsulator node to
	the protocol peer is not an IP forwarding hop, where TTL-decrementing		the protocol peer is not an IP forwarding hop, where TTL-decrementing
	does not happen (e.g., layer-2 tunneling, bridging, etc). In the		does not happen (e.g., layer-2 tunneling, bridging, etc). In the
	IPsec architecture [RFC4301], another example is the use of Bump-in-		IPsec architecture [RFC4301], another example is the use of Bump-in-
	the-Wire (BITW) [BITW].		the-Wire (BITW) [BITW].
	5.2.1. IP Tunneled over IP		5.2.1. IP Tunneled over IP
	Protocol packets may be tunneled over IP directly to a protocol peer,		Protocol packets may be tunneled over IP directly to a protocol peer,
	or to a decapsulator (tunnel endpoint) that then forwards the packet		or to a decapsulator (tunnel endpoint) that then forwards the packet
	to a directly connected protocol peer. Examples of tunneling IP over		to a directly connected protocol peer. Examples of tunneling IP over
	IP include IP-in-IP [RFC2003], GRE [RFC2784], or various forms of		IP include IP-in-IP [RFC2003], GRE [RFC2784], and various forms of
	IPv6-in-IPv4 (e.g., [RFC4213]). These cases are depicted below.		IPv6-in-IPv4 (e.g., [RFC4213]). These cases are depicted below.
	Peer router ---------- Tunnel endpoint router and peer		Peer router ---------- Tunnel endpoint router and peer
	TTL=255 [tunnel] [TTL=255 at ingress]		TTL=255 [tunnel] [TTL=255 at ingress]
	[TTL=255 at processing]		[TTL=255 at processing]
	Peer router -------- Tunnel endpoint router ----- On-link peer		Peer router -------- Tunnel endpoint router ----- On-link peer
	TTL=255 [tunnel] [TTL=255 at ingress] [TTL=254 at ingress]		TTL=255 [tunnel] [TTL=255 at ingress] [TTL=254 at ingress]
	[TTL=254 at egress]		[TTL=254 at egress]
	skipping to change at page 9, line 18		skipping to change at page 8, line 44
	header is decremented by one if the tunneling is being		header is decremented by one if the tunneling is being
	done as part of forwarding the datagram; otherwise, the		done as part of forwarding the datagram; otherwise, the
	inner header TTL is not changed during encapsulation.		inner header TTL is not changed during encapsulation.
	In the first case, the encapsulated packet is tunneled directly to		In the first case, the encapsulated packet is tunneled directly to
	the protocol peer (also a tunnel endpoint), and therefore the		the protocol peer (also a tunnel endpoint), and therefore the
	encapsulated packet's TTL can be received by the protocol peer with		encapsulated packet's TTL can be received by the protocol peer with
	an arbitrary value, including 255.		an arbitrary value, including 255.
	In the second case, the encapsulated packet is tunneled to a		In the second case, the encapsulated packet is tunneled to a
	decapsulator (tunnel endpoint) which then forwards it to a directly		decapsulator (tunnel endpoint), which then forwards it to a directly
	connected protocol peer. For IP-in-IP tunnels, RFC 2003 specifies		connected protocol peer. For IP-in-IP tunnels, RFC 2003 specifies
	the following decapsulator behavior:		the following decapsulator behavior:
	The TTL in the inner IP header is not changed when decapsulating.		The TTL in the inner IP header is not changed when decapsulating.
	If, after decapsulation, the inner datagram has TTL = 0, the		If, after decapsulation, the inner datagram has TTL = 0, the
	decapsulator MUST discard the datagram. If, after decapsulation,		decapsulator MUST discard the datagram. If, after decapsulation,
	the decapsulator forwards the datagram to one of its network		the decapsulator forwards the datagram to one of its network
	interfaces, it will decrement the TTL as a result of doing normal		interfaces, it will decrement the TTL as a result of doing normal
	IP forwarding. See also Section 4.4.		IP forwarding. See also Section 4.4.
	skipping to change at page 10, line 28		skipping to change at page 10, line 10
	the iTTL: For Uniform Model LSPs, the iTTL is the value of the TTL		the iTTL: For Uniform Model LSPs, the iTTL is the value of the TTL
	field from the popped MPLS header (encapsulating header), whereas for		field from the popped MPLS header (encapsulating header), whereas for
	Pipe Model LSPs, the iTTL is the value of the TTL field from the		Pipe Model LSPs, the iTTL is the value of the TTL field from the
	exposed header (encapsulated header).		exposed header (encapsulated header).
	For Uniform Model LSPs, RFC 3443 states that at ingress:		For Uniform Model LSPs, RFC 3443 states that at ingress:
	For each pushed Uniform Model label, the TTL is copied from the		For each pushed Uniform Model label, the TTL is copied from the
	label/IP-packet immediately underneath it.		label/IP-packet immediately underneath it.
	From this point, the inner TTL (TTL of the tunneled IP datagram)		From this point, the inner TTL (i.e., the TTL of the tunneled IP
	represents non-meaningful information, and at the egress node or		datagram) represents non-meaningful information, and at the egress
	during PHP, the ingress TTL (iTTL) is equal to the TTL of the popped		node or during PHP, the ingress TTL (iTTL) is equal to the TTL of the
	MPLS header (see Section 3.1 of RFC 3443). In consequence, for		popped MPLS header (see Section 3.1 of RFC 3443). In consequence,
	Uniform Model LSPs of more than one hop, the TTL at ingress (iTTL)		for Uniform Model LSPs of more than one hop, the TTL at ingress
	will be less than 255 (x <= 254), and as a result the check described		(iTTL) will be less than 255 (x <= 254), and as a result the check
	in Section 3 of this document will fail.		described in Section 3 of this document will fail.
	The TTL treatment is identical between Short Pipe Model LSPs without		The TTL treatment is identical between Short Pipe Model LSPs without
	PHP and Pipe Model LSPs (without PHP only). For these cases, RFC		PHP and Pipe Model LSPs (without PHP only). For these cases, RFC
	3443 states that:		3443 states that:
	For each pushed Pipe Model or Short Pipe Model label, the TTL		For each pushed Pipe Model or Short Pipe Model label, the TTL
	field is set to a value configured by the network operator. In		field is set to a value configured by the network operator. In
	most implementations, this value is set to 255 by default.		most implementations, this value is set to 255 by default.
	In these models, the forwarding treatment at egress is based on the		In these models, the forwarding treatment at egress is based on the
	skipping to change at page 11, line 12		skipping to change at page 10, line 42
	also the protocol peer, it is possible to deliver the protocol packet		also the protocol peer, it is possible to deliver the protocol packet
	with a TTL of 255 (x = 255).		with a TTL of 255 (x = 255).
	Finally, for Short Pipe Model LSPs with PHP, the TTL of the tunneled		Finally, for Short Pipe Model LSPs with PHP, the TTL of the tunneled
	packet is unchanged after the PHP operation. Therefore, the same		packet is unchanged after the PHP operation. Therefore, the same
	conclusions drawn regarding the Short Pipe Model LSPs without PHP and		conclusions drawn regarding the Short Pipe Model LSPs without PHP and
	Pipe Model LSPs (without PHP only) apply to this case. For Short		Pipe Model LSPs (without PHP only) apply to this case. For Short
	Pipe Model LSPs, the TTL at egress has the same value with or without		Pipe Model LSPs, the TTL at egress has the same value with or without
	PHP.		PHP.
	In conclusion, GTSM-checks are possible for IP tunneled over Pipe		In conclusion, GTSM checks are possible for IP tunneled over Pipe
	model LSPs, but not for IP tunneled over Uniform model LSPs.		model LSPs, but not for IP tunneled over Uniform model LSPs.
	Additionally, for all tunneling modes, if the LSP termination router		Additionally, for all tunneling modes, if the LSP termination router
	needs to forward the protocol packet to a directly connected protocol		needs to forward the protocol packet to a directly connected protocol
	peer, it is not possible to deliver the protocol packet to the		peer, it is not possible to deliver the protocol packet to the
	protocol peer with a TTL of 255. If the packet is further forwarded,		protocol peer with a TTL of 255. If the packet is further forwarded,
	the outgoing TTL (oTTL) is calculated by decrementing iTTL by one.		the outgoing TTL (oTTL) is calculated by decrementing iTTL by one.
	5.3. Onlink Attackers		5.3. Onlink Attackers
	As described in Section 2, an attacker directly connected to one		As described in Section 2, an attacker directly connected to one
	interface can disturb a GTSM-protected session on the same or another		interface can disturb a GTSM-protected session on the same or another
	interface (by spoofing a GTSM peer's address) unless ingress		interface (by spoofing a GTSM peer's address) unless ingress
	filtering has been applied on the connecting interface. As a result,		filtering has been applied on the connecting interface. As a result,
	interfaces which do not include such protection need to be trusted		interfaces that do not include such protection need to be trusted not
	not to originate attacks on the router.		to originate attacks on the router.
	5.4. Fragmentation Considerations		5.4. Fragmentation Considerations
	As already mentioned, fragmentation may restrict the amount of		As mentioned, fragmentation may restrict the amount of information
	information available for classification. Since non-initial IP		available for classification. Since non-initial IP fragments do not
	fragments do not contain Layer 4 information, it is highly likely		contain Layer 4 information, it is highly likely that they cannot be
	that they cannot be associated with a registered GTSM-enabled		associated with a registered GTSM-enabled session. Following the
	session. Following the receiving protocol procedures described in		receiving protocol procedures described in Section 3, non-initial IP
	Section 3, non-initial IP fragments would likely be classified with		fragments would likely be classified with Unknown trustworthiness.
	Unknown trustworthiness. And since the IP packet would need to be		And since the IP packet would need to be reassembled in order to be
	reassembled in order to be processed, the end result is that the		processed, the end result is that the initial-fragment of a GTSM-
	initial-fragment of a GTSM-enabled session effectively receives the		enabled session effectively receives the treatment of an Unknown-
	treatment of an Unknown-trustworthiness packet, and the complete		trustworthiness packet, and the complete reassembled packet receives
	reassembled packet receives the aggregate of the Unknowns.		the aggregate of the Unknowns.
	In principle an implementation could remember the TTL of all received		In principle, an implementation could remember the TTL of all
	fragments, and then when reassembling the packet verify that the TTL		received fragments. Then when reassembling the packet, verify that
	of all fragments matches the required value for an associated GTSM-		the TTL of all fragments match the required value for an associated
	enabled session. In the likely common case that the implementation		GTSM-enabled session. In the likely common case that the
	does not do this check on all fragments, then it is possible for a		implementation does not do this check on all fragments, then it is
	legitimate first fragment (which passes the GTSM check) to be		possible for a legitimate first fragment (which passes the GTSM
	combined with spoofed non-initial fragments, implying that the		check) to be combined with spoofed non-initial fragments, implying
	integrity of the received packet is unknown and unprotected. If this		that the integrity of the received packet is unknown and unprotected.
	check is performed on all fragments at reassembly, and some fragment		If this check is performed on all fragments at reassembly, and some
	does not pass the GTSM check for a GTSM-enabled session, the		fragment does not pass the GTSM check for a GTSM-enabled session, the
	reassembled packet is categorized as a Dangerous-trustworthiness		reassembled packet is categorized as a Dangerous-trustworthiness
	packet and receives the corresponding treatment.		packet and receives the corresponding treatment.
	Further, reassembly requires to wait for all the fragments and		Further, reassembly requires to wait for all the fragments and
	therefore likely invalidates or weakens the fifth assumption		therefore likely invalidates or weakens the fifth assumption
	presented in Section 2: it may not be possible to classify non-		presented in Section 2: it may not be possible to classify non-
	initial fragments before going through a scarce resource in the		initial fragments before going through a scarce resource in the
	system, when fragments need to be buffered for reassembly and later		system, when fragments need to be buffered for reassembly and later
	processed by a CPU. That is, when classification cannot be done with		processed by a CPU. That is, when classification cannot be done with
	the required granularity, non-initial fragments of GTSM-enabled		the required granularity, non-initial fragments of GTSM-enabled
	session packets would not use different resource pools.		session packets would not use different resource pools.
	Consequently, to get practical protection from fragment attacks,		Consequently, to get practical protection from fragment attacks,
	operators may need to rate-limit or discard all received fragments.		operators may need to rate-limit or discard all received fragments.
	As such, it is highly RECOMMENDED for GTSM-protected protocols to		As such, it is highly RECOMMENDED for GTSM-protected protocols to
	avoid fragmentation and reassembly by manual MTU tuning, using		avoid fragmentation and reassembly by manual MTU tuning, using
	adaptive measures such as Path MTU Discovery (PMTUD) or any other		adaptive measures such as Path MTU Discovery (PMTUD), or any other
	available method [RFC1191], [RFC1981], [RFC4821].		available method [RFC1191], [RFC1981], or [RFC4821].
	5.5. Multi-Hop Protocol Sessions		5.5. Multi-Hop Protocol Sessions
	GTSM could possibly offer some small though difficult to quantify		GTSM could possibly offer some small, though difficult to quantify,
	degree of protection when used with multi-hop protocol sessions (see		degree of protection when used with multi-hop protocol sessions (see
	Appendix A). In order to avoid having to quantify the degree of		Appendix A). In order to avoid having to quantify the degree of
	protection and the resulting applicability of multi-hop, we only		protection and the resulting applicability of multi-hop, we only
	describe the single-hop case because its security properties are		describe the single-hop case because its security properties are
	clearer.		clearer.
	6. Applicability Statement		6. Applicability Statement
	GTSM is only applicable to environments with inherently limited		GTSM is only applicable to environments with inherently limited
	topologies (and is most effective in those cases where protocol peers		topologies (and is most effective in those cases where protocol peers
	skipping to change at page 12, line 49		skipping to change at page 12, line 34
	GTSM will not protect against attackers who are as close to the		GTSM will not protect against attackers who are as close to the
	protected station as its legitimate peer. For example, if the		protected station as its legitimate peer. For example, if the
	legitimate peer is one hop away, GTSM will not protect from attacks		legitimate peer is one hop away, GTSM will not protect from attacks
	from directly connected devices on the same interface (see		from directly connected devices on the same interface (see
	Section 2.2 for more).		Section 2.2 for more).
	Experimentation on GTSM's applicability and security properties is		Experimentation on GTSM's applicability and security properties is
	needed in multi-hop scenarios. The multi-hop scenarios where GTSM		needed in multi-hop scenarios. The multi-hop scenarios where GTSM
	might be applicable is expected to have the following		might be applicable is expected to have the following
	characteristics: the topology between peers is fairly static and well		characteristics: the topology between peers is fairly static and
	known, and in which the intervening network (between the peers) is		well-known, and in which the intervening network (between the peers)
	trusted.		is trusted.
	6.1. Backwards Compatibility		6.1. Backwards Compatibility
	RFC 3682 [RFC3682] did not specify how to handle "related messages"		RFC 3682 [RFC3682] did not specify how to handle "related messages"
	(ICMP errors). This specification mandates setting and verifying		(ICMP errors). This specification mandates setting and verifying
	TTL=255 of those as well as the main protocol packets.		TTL=255 of those as well as the main protocol packets.
	Setting TTL=255 in related messages does not cause issues for RFC		Setting TTL=255 in related messages does not cause issues for RFC
	3682 implementations.		3682 implementations.
	skipping to change at page 13, line 30		skipping to change at page 13, line 14
	as Dangerous and treated as described in Section 3. This is not		as Dangerous and treated as described in Section 3. This is not
	believed to be a significant problem because protocols do not depend		believed to be a significant problem because protocols do not depend
	on related messages (e.g., typically having a protocol exchange for		on related messages (e.g., typically having a protocol exchange for
	closing the session instead of doing a TCP-RST), and indeed the		closing the session instead of doing a TCP-RST), and indeed the
	delivery of related messages is not reliable. As such, related		delivery of related messages is not reliable. As such, related
	messages typically provide an optimization to shorten a protocol		messages typically provide an optimization to shorten a protocol
	keepalive timeout. Regardless of these issues, given that related		keepalive timeout. Regardless of these issues, given that related
	messages provide a significant attack vector to e.g., reset protocol		messages provide a significant attack vector to e.g., reset protocol
	sessions, making this further restriction seems sensible.		sessions, making this further restriction seems sensible.
	7. IANA Considerations		7. References
	This document requires no action from IANA.
	8. References
	8.1. Normative References		7.1. Normative References
	[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,		[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
	September 1981.		September 1981.
	[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,		[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
	October 1996.		October 1996.
	[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.
	skipping to change at page 14, line 25		skipping to change at page 14, line 5
	[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms		[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
	for IPv6 Hosts and Routers", RFC 4213, October 2005.		for IPv6 Hosts and Routers", RFC 4213, October 2005.
	[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway		[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
	Protocol 4 (BGP-4)", RFC 4271, January 2006.		Protocol 4 (BGP-4)", RFC 4271, January 2006.
	[RFC4301] Kent, S. and K. Seo, "Security Architecture for the		[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
	Internet Protocol", RFC 4301, December 2005.		Internet Protocol", RFC 4301, December 2005.
	8.2. Informative References		7.2. Informative References
	[BITW] "Thread: 'IP-in-IP, TTL decrementing when forwarding and		[BITW] "Thread: 'IP-in-IP, TTL decrementing when forwarding and
	BITW' on int-area list, Message-ID:		BITW' on int-area list, Message-ID:
	<Pine.LNX.4.64.0606020830220.12705@netcore.fi>",		<Pine.LNX.4.64.0606020830220.12705@netcore.fi>",
	June 2006, <http://www1.ietf.org/mail-archive/web/		June 2006, <http://www1.ietf.org/mail-archive/web/
	int-area/current/msg00267.html>.		int-area/current/msg00267.html>.
	[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,		[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
	November 1990.		November 1990.
	skipping to change at page 15, line 6		skipping to change at page 15, line 5
	[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed		[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
	Networks", BCP 84, RFC 3704, March 2004.		Networks", BCP 84, RFC 3704, March 2004.
	[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis",		[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis",
	RFC 4272, January 2006.		RFC 4272, January 2006.
	[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU		[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
	Discovery", RFC 4821, March 2007.		Discovery", RFC 4821, March 2007.
	Appendix A. Multi-hop GTSM		Appendix A. Multi-Hop GTSM
	NOTE: This is a non-normative part of the specification.		NOTE: This is a non-normative part of the specification.
	The main applicability of GTSM is for directly connected peers. GTSM		The main applicability of GTSM is for directly connected peers. GTSM
	could be used for non-directly connected sessions as well, where the		could be used for non-directly connected sessions as well, where the
	recipient would check that the TTL is within a configured number of		recipient would check that the TTL is within a configured number of
	hops from 255 (e.g., check that packets have 254 or 255). As such		hops from 255 (e.g., check that packets have 254 or 255). As such
	deployment is expected to have a more limited applicability and		deployment is expected to have a more limited applicability and
	different security implications, it is not specified in this		different security implications, it is not specified in this
	document.		document.
	skipping to change at page 15, line 36		skipping to change at page 15, line 35
	o Explicitly require that related messages (ICMP errors) must also		o Explicitly require that related messages (ICMP errors) must also
	be sent and checked to have TTL=255. See Section 6.1 for		be sent and checked to have TTL=255. See Section 6.1 for
	discussion on backwards compatibility.		discussion on backwards compatibility.
	o Clarifications relating to fragmentation, security with tunneling,		o Clarifications relating to fragmentation, security with tunneling,
	and implications of ingress filtering.		and implications of ingress filtering.
	o A significant number of editorial improvements and clarifications.		o A significant number of editorial improvements and clarifications.
	Appendix C. Draft Changelog
	NOTE to the RFC-editor: please remove this section before
	publication.
	Appendix C.1. Changes between -09 and -10
	o Editorial updates from IETF LC and IESG review.
	o Clarify fragmentation and integrity issues, from Sam Hartman.
	o Repeat the hop limit's protection implication in Applicability
	Statement (Ron Bonica).
	o Remove "TCP RSTs" from "related messages" examples (Lars Eggert).
	o Only define ICMP errors as related messages (Ross Callon).
	Appendix C.2. Changes between -08 and -09
	o Clarify that GTSM may be enabled on existing protocols if the
	protocols include a capability negotiation feature and both
	parties support GTSM.
	o Editorial updates.
	Appendix C.3. Changes between -07 and -08
	o Describe the assumption of ingress filtering to protect against
	on-link attacks.
	o Rewrite the IP over MPLS section based on the new MPLS TTL
	handling procedure (from Carlos Pignataro) to get the details of
	new MPLS architecture right.
	o Rephrase IP over IP tunneling section a bit, to make distinction
	between encapsulation and decapsulation behavior clearer.
	o Make it clearer in the tunneling section that unless the tunnel
	peer is also the protocol peer, GTSM should be able to offer
	protection.
	o Describe better the applicability of GTSM when tunneling.
	o Rephrase Multi-hop GTSM section to mainly refer to the difficult-
	to-quantify security properties as a reason for exclusion at this
	point.
	o Some editorial updates.
	Appendix C.4. Changes between -06 and -07
	o Be more reserved about multi-hop security properties in section
	'Multi-Hop Protocol Sessions'.
	o Clarify IP-in-IP tunnel decapsulation/forwarding as decrementing
	TTL.
	o Add text on related messages backwards compatibility.
	o Editorial updates.
	Appendix C.5. Changes between -05 and -06
	o Clarify the assumptions wrt. resource separation and protection
	based on comments from Alex Zinin.
	o Rewrite the GTSM procedure based on text from Alex Zinin.
	o Reduce TrustRadius and multi-hop scenarios to a mention in an
	Appendix.
	o Describe TCP-RST, ICMP error and "related messages" handling.
	o Update the tunneling security considerations text.
	o Editorial updates (e.g., shortening the abstract).
	Authors' Addresses		Authors' Addresses
	Vijay Gill		Vijay Gill
			EMail: vijay@umbc.edu
	Email: vijay@umbc.edu
	John Heasley		John Heasley
			EMail: heas@shrubbery.net
	Email: heas@shrubbery.net
	David Meyer		David Meyer
			EMail: dmm@1-4-5.net
	Email: dmm@1-4-5.net
	Pekka Savola (editor)		Pekka Savola (editor)
	Espoo		Espoo
	Finland		Finland
			EMail: psavola@funet.fi
	Email: psavola@funet.fi
	Carlos Pignataro		Carlos Pignataro
			EMail: cpignata@cisco.com
	Email: cpignata@cisco.com
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	skipping to change at page 18, line 44		skipping to change at line 710
	attempt made to obtain a general license or permission for the use of		attempt made to obtain a general license or permission for the use of
	such proprietary rights by implementers or users of this		such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at		specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.		http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at		this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.		ietf-ipr@ietf.org.
	Acknowledgment
	Funding for the RFC Editor function is provided by the IETF
	Administrative Support Activity (IASA).
End of changes. 46 change blocks.
	221 lines changed or deleted		105 lines changed or added
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/