draft-ietf-rtgwg-rfc3682bis-09.txt   draft-ietf-rtgwg-rfc3682bis-10.txt 
Routing WG V. Gill Routing WG V. Gill
Internet-Draft J. Heasley Internet-Draft J. Heasley
Obsoletes: 3682 (if approved) D. Meyer Obsoletes: 3682 (if approved) D. Meyer
Intended status: Standards Track P. Savola, Ed. Intended status: Standards Track P. Savola, Ed.
Expires: August 4, 2007 C. Pignataro Expires: December 27, 2007 C. Pignataro
January 31, 2007 June 25, 2007
The Generalized TTL Security Mechanism (GTSM) The Generalized TTL Security Mechanism (GTSM)
draft-ietf-rtgwg-rfc3682bis-09.txt draft-ietf-rtgwg-rfc3682bis-10.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 4, 2007. This Internet-Draft will expire on December 27, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
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 RFC 3682. generalizes this technique. This document obsoletes Experimental RFC
3682.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
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 . . . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
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 . . . . . . . . . . . . . . . . . 12 6.1. Backwards Compatibility . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. Multi-hop GTSM . . . . . . . . . . . . . . . . . . . 14 Appendix A. Multi-hop GTSM . . . . . . . . . . . . . . . . . . . 15
Appendix B. Changes Since RFC3682 . . . . . . . . . . . . . . . 14 Appendix B. Changes Since RFC3682 . . . . . . . . . . . . . . . 15
Appendix C. Draft Changelog . . . . . . . . . . . . . . . . . . 15 Appendix C. Draft Changelog . . . . . . . . . . . . . . . . . . 15
Appendix C.1. Changes between -08 and -09 . . . . . . . . . . . . 15 Appendix C.1. Changes between -09 and -10 . . . . . . . . . . . . 15
Appendix C.2. Changes between -07 and -08 . . . . . . . . . . . . 15 Appendix C.2. Changes between -08 and -09 . . . . . . . . . . . . 16
Appendix C.3. Changes between -06 and -07 . . . . . . . . . . . . 15 Appendix C.3. Changes between -07 and -08 . . . . . . . . . . . . 16
Appendix C.4. Changes between -05 and -06 . . . . . . . . . . . . 16 Appendix C.4. Changes between -06 and -07 . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Appendix C.5. Changes between -05 and -06 . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 18 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
skipping to change at page 4, line 22 skipping to change at page 4, line 22
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 the packets not matching the GTSM filtering
rules, such as dropping packets that do not match any configured rules, such as dropping packets that do not match any configured
protocol session and rate-limiting the rest. This document also does protocol session and rate-limiting the rest. This document also does
not suggest the actual means of resource separation, as those are not 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, The possibility of denial-of-service (DoS) attack prevention,
however, is based on the assumption that packet classification and however, is based on the assumption that classification of packets
separation of their paths is done before they go through a scarce and separation of their paths are done before they go through a
resource in the system. In practice, this means that, the closer scarce resource in the system. In practice, this means that, the
GTSM processing is done to the line-rate hardware, the more resistant closer GTSM processing is done to the line-rate hardware, the more
the system is to the DoS attacks. resistant the system is to the 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
skipping to change at page 5, line 16 skipping to change at page 5, line 16
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 which 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., 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 for 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.
skipping to change at page 6, line 7 skipping to change at page 6, line 7
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:
The TTL field in all IP packets used for transmission of The TTL field in all IP packets used for transmission of
messages associated with GTSM-enabled protocol sessions MUST be messages associated with GTSM-enabled protocol sessions MUST be
set to 255. This also applies to related error handling set to 255. This also applies to the related ICMP error
messages associated with said session, such as TCP RSTs or ICMP handling messages.
errors.
On some architectures, the TTL of control plane originated On some architectures, the TTL of control plane originated
traffic is under some configurations decremented in the traffic is under some configurations decremented in the
forwarding plane. The TTL of GTSM-enabled sessions MUST NOT be forwarding plane. The TTL of GTSM-enabled sessions MUST NOT be
decremented. decremented.
Receiving protocol packets: Receiving protocol packets:
The GTSM packet identification step associates each received The GTSM packet identification step associates each received
packet addressed to the router's control plane with one of the packet addressed to the router's control plane with one of the
skipping to change at page 6, line 39 skipping to change at page 6, line 38
+ 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 the 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
such as ICMP errors and TCP RSTs. It should be noted that (ICMP errors). It should be noted that fragmentation may
fragmentation may restrict the amount of information available restrict the amount of information available to the
to the 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.
skipping to change at page 7, line 17 skipping to change at page 7, line 15
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 and
Alex Zinin also provided useful feedback on earlier versions of this Alex Zinin also provided useful feedback on earlier versions of this
document. David Ward provided insight on the generalization of the document. David Ward provided insight on the generalization of the
original BGP-specific idea. Alex Zinin, Alia Atlas, and John Scudder original BGP-specific idea. Alex Zinin, Alia Atlas, and John Scudder
provided significant amount of feedback for the newer versions of the provided significant amount of feedback for the newer versions of the
document. document. During and after the IETF Last Call, 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
skipping to change at page 7, line 43 skipping to change at page 7, line 42
packet, it may not be able to determine if the packet's IP address is packet, it may not be able to determine if the packet's IP address is
valid, but it can determine how many router hops away it is (again, valid, but it can determine how many router hops away it is (again,
assuming none of the routers in the path are compromised in such a assuming none of the routers in the path are compromised in such a
way that they would reset the packet's TTL). way that they would reset the packet's TTL).
Note, however, that while engineering a packet's TTL such that it has Note, however, that while engineering a packet's TTL such that it has
a particular value when sourced from an arbitrary location is a particular value when sourced from an arbitrary location is
difficult (but not impossible), engineering a TTL value of 255 from difficult (but not impossible), engineering a TTL value of 255 from
non-directly connected locations is not possible (again, assuming non-directly connected locations is not possible (again, assuming
none of the directly connected neighbors are compromised, the packet none of the directly connected neighbors are compromised, the packet
hasn't been tunneled to the decapsulator, and the intervening routers has not been tunneled to the decapsulator, and the intervening
are operating in accordance with RFC 791 [RFC0791]). routers are operating in accordance with RFC 791 [RFC0791]).
5.2. Tunneled Packets 5.2. Tunneled Packets
The security of any tunneling technique depends heavily on The security of any tunneling technique depends heavily on
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
skipping to change at page 11, line 44 skipping to change at page 11, line 43
fragments do not contain Layer 4 information, it is highly likely fragments do not contain Layer 4 information, it is highly likely
that they cannot be associated with a registered GTSM-enabled that they cannot be associated with a registered GTSM-enabled
session. Following the receiving protocol procedures described in session. Following the receiving protocol procedures described in
Section 3, non-initial IP fragments would likely be classified with Section 3, non-initial IP fragments would likely be classified with
Unknown trustworthiness. And since the IP packet would need to be Unknown trustworthiness. And since the IP packet would need to be
reassembled in order to be processed, the end result is that the reassembled in order to be processed, the end result is that the
initial-fragment of a GTSM-enabled session effectively receives the initial-fragment of a GTSM-enabled session effectively receives the
treatment of an Unknown-trustworthiness packet, and the complete treatment of an Unknown-trustworthiness packet, and the complete
reassembled packet receives the aggregate of the Unknowns. reassembled packet receives the aggregate of the Unknowns.
In principle an implementation could remember the TTL of all received
fragments, and then when reassembling the packet verify that the TTL
of all fragments matches the required value for an associated GTSM-
enabled session. In the likely common case that the implementation
does not do this check on all fragments, then it is possible for a
legitimate first fragment (which passes the GTSM check) to be
combined with spoofed non-initial fragments, implying that the
integrity of the received packet is unknown and unprotected. If this
check is performed on all fragments at reassembly, and some fragment
does not pass the GTSM check for a GTSM-enabled session, the
reassembled packet is categorized as a Dangerous-trustworthiness
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. available method [RFC1191], [RFC1981], [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 because its security properties are clearer. describe the single-hop case because its security properties are
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
are directly connected). In particular, its application should be are directly connected). In particular, its application should be
limited to those cases in which protocol peers are directly limited to those cases in which protocol peers are directly
connected. connected.
GTSM will not protect against attackers who are as close to the
protected station as its legitimate peer. For example, if the
legitimate peer is one hop away, GTSM will not protect from attacks
from directly connected devices on the same interface (see
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 well
known, and in which the intervening network (between the peers) is known, and in which the intervening network (between the peers) is
trusted. trusted.
6.1. Backwards Compatibility 6.1. Backwards Compatibility
RFC 3682 did not specify how to handle "related messages" such as TCP RFC 3682 [RFC3682] did not specify how to handle "related messages"
RSTs or ICMP errors. This specification mandates setting and (ICMP errors). This specification mandates setting and verifying
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.
Requiring TTL=255 in related messages may have impact with RFC 3682 Requiring TTL=255 in related messages may have impact with RFC 3682
implementations, depending on which default TTL the implementation implementations, depending on which default TTL the implementation
uses for originated packets; some implementations are known to use uses for originated packets; some implementations are known to use
255, while 64 or other values are also used. Related messages from 255, while 64 or other values are also used. Related messages from
the latter category of RFC 3682 implementations would be classified the latter category of RFC 3682 implementations would be classified
as Dangerous and treated as described in Section 3. This is not as Dangerous and treated as described in Section 3. This is not
skipping to change at page 14, line 14 skipping to change at page 14, line 33
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
8.2. Informative References 8.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,
November 1990.
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
for IP version 6", RFC 1981, August 1996.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, January 2001. Encoding", RFC 3032, January 2001.
[RFC3682] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL
Security Mechanism (GTSM)", RFC 3682, February 2004.
[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
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 "TrustRadius" (e.g., 1) recipient would check that the TTL is within a configured number of
of 255 instead of 255. As such deployment is expected to have a more hops from 255 (e.g., check that packets have 254 or 255). As such
limited applicability and different security implications, it is not deployment is expected to have a more limited applicability and
specified in this document. different security implications, it is not specified in this
document.
Appendix B. Changes Since RFC3682 Appendix B. Changes Since RFC3682
o Bring the work on the Standards Track (RFC 3682 was Experimental).
o New text on GTSM applicability and use in new and existing o New text on GTSM applicability and use in new and existing
protocols. protocols.
o Restrict the scope to not specify multi-hop scenarios. o Restrict the scope to not specify multi-hop scenarios.
o Explicitly require that related messages (e.g., TCP RSTs, ICMP o Explicitly require that related messages (ICMP errors) must also
errors) must also be sent and checked to have TTL=255. See be sent and checked to have TTL=255. See Section 6.1 for
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 Appendix C. Draft Changelog
NOTE to the RFC-editor: please remove this section before NOTE to the RFC-editor: please remove this section before
publication. publication.
Appendix C.1. Changes between -08 and -09 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 o Clarify that GTSM may be enabled on existing protocols if the
protocols include a capability negotiation feature and both protocols include a capability negotiation feature and both
parties support GTSM. parties support GTSM.
o Editorial updates. o Editorial updates.
Appendix C.2. Changes between -07 and -08 Appendix C.3. Changes between -07 and -08
o Describe the assumption of ingress filtering to protect against o Describe the assumption of ingress filtering to protect against
on-link attacks. on-link attacks.
o Rewrite the IP over MPLS section based on the new MPLS TTL o Rewrite the IP over MPLS section based on the new MPLS TTL
handling procedure (from Carlos Pignataro) to get the details of handling procedure (from Carlos Pignataro) to get the details of
new MPLS architecture right. new MPLS architecture right.
o Rephrase IP over IP tunneling section a bit, to make distinction o Rephrase IP over IP tunneling section a bit, to make distinction
between encapsulation and decapsulation behavior clearer. between encapsulation and decapsulation behavior clearer.
skipping to change at page 15, line 44 skipping to change at page 16, line 41
protection. protection.
o Describe better the applicability of GTSM when tunneling. o Describe better the applicability of GTSM when tunneling.
o Rephrase Multi-hop GTSM section to mainly refer to the difficult- o Rephrase Multi-hop GTSM section to mainly refer to the difficult-
to-quantify security properties as a reason for exclusion at this to-quantify security properties as a reason for exclusion at this
point. point.
o Some editorial updates. o Some editorial updates.
Appendix C.3. Changes between -06 and -07 Appendix C.4. Changes between -06 and -07
o Be more reserved about multi-hop security properties in section o Be more reserved about multi-hop security properties in section
'Multi-Hop Protocol Sessions'. 'Multi-Hop Protocol Sessions'.
o Clarify IP-in-IP tunnel decapsulation/forwarding as decrementing o Clarify IP-in-IP tunnel decapsulation/forwarding as decrementing
TTL. TTL.
o Add text on related messages backwards compatibility. o Add text on related messages backwards compatibility.
o Editorial updates. o Editorial updates.
Appendix C.4. Changes between -05 and -06 Appendix C.5. Changes between -05 and -06
o Clarify the assumptions wrt. resource separation and protection o Clarify the assumptions wrt. resource separation and protection
based on comments from Alex Zinin. based on comments from Alex Zinin.
o Rewrite the GTSM procedure based on text 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 o Reduce TrustRadius and multi-hop scenarios to a mention in an
Appendix. Appendix.
o Describe TCP-RST, ICMP error and "related messages" handling. o Describe TCP-RST, ICMP error and "related messages" handling.
 End of changes. 29 change blocks. 
46 lines changed or deleted 96 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/