draft-ietf-rtgwg-rfc3682bis-05.txt   draft-ietf-rtgwg-rfc3682bis-06.txt 
INTERNET-DRAFT V. Gill Routing WG V. Gill
draft-ietf-rtgwg-rfc3682bis-05.txt J. Heasley Internet-Draft J. Heasley
D. Meyer Obsoletes: 3682 (if approved) D. Meyer
Category Proposed Standard Intended status: Standards Track P. Savola
Obsoletes: RFC 3682 Expires: March 1, 2007 August 28, 2006
The Generalized TTL Security Mechanism (GTSM)
<draft-ietf-rtgwg-rfc3682bis-05.txt>
Status of this Memo The Generalized TTL Security Mechanism (GTSM)
draft-ietf-rtgwg-rfc3682bis-06.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all By submitting this Internet-Draft, each author represents that any
provisions of Section 3 of RFC 3667. By submitting this applicable patent or other IPR claims of which he or she is aware
Internet-Draft, each author represents that any applicable patent have been or will be disclosed, and any of which he or she becomes
or other IPR claims of which he or she is aware have been or will aware will be disclosed, in accordance with Section 6 of BCP 79.
be disclosed, and any of which he or she become aware will be
disclosed, in accordance with RFC 3668.
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
other groups may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six months
months and may be updated, replaced, or obsoleted by other and may be updated, replaced, or obsoleted by other documents at any
documents at any time. It is inappropriate to use time. It is inappropriate to use Internet-Drafts as reference
Internet-Drafts as reference material or to cite them other than material or to cite them other than as "work in progress."
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 document is a product of the RTGWG WG. Comments should be This Internet-Draft will expire on March 1, 2007.
addressed to the authors, or the mailing list at rtgwg@ietf.org.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved. Copyright (C) The Internet Society (2006).
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 protect a protocol stack from CPU-utilization based attacks has to verify whether the packet originated within the same link has been
been proposed in many settings (see for example, RFC 2461). This used in many recent protocols. This document generalizes this
document generalizes these techniques for use by other protocols such technique. This document obsoletes RFC 3682.
as BGP (RFC 1771), Multicast Source Discovery Protocol (MSDP),
Bidirectional Forwarding Detection, and Label Distribution Protocol
(LDP) (RFC 3036). While the Generalized TTL Security Mechanism (GTSM)
is most effective in protecting directly connected protocol peers, it
can also provide a lower level of protection to multi-hop sessions.
GTSM is not directly applicable to protocols employing flooding
mechanisms (e.g., multicast), and use of multi-hop GTSM should be
considered on a case-by-case basis. This document obsoletes RFC
3682.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Assumptions Underlying GTSM. . . . . . . . . . . . . . . . . . 4 2. Assumptions Underlying GTSM . . . . . . . . . . . . . . . . . 3
2.1. GTSM Negotiation. . . . . . . . . . . . . . . . . . . . . . 4 2.1. GTSM Negotiation . . . . . . . . . . . . . . . . . . . . . 4
2.2. Assumptions on Attack Sophistication. . . . . . . . . . . . 5 2.2. Assumptions on Attack Sophistication . . . . . . . . . . . 4
3. GTSM Procedure . . . . . . . . . . . . . . . . . . . . . . . . 5 3. GTSM Procedure . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Multi-hop Scenarios . . . . . . . . . . . . . . . . . . . . 6 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.1. Intra-domain Protocol Handling . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
4. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. TTL (Hop Limit) Spoofing . . . . . . . . . . . . . . . . . 7
5. Security Considerations. . . . . . . . . . . . . . . . . . . . 7 5.2. Tunneled Packets . . . . . . . . . . . . . . . . . . . . . 7
5.1. TTL (Hop Limit) Spoofing. . . . . . . . . . . . . . . . . . 8 5.2.1. IP in IP . . . . . . . . . . . . . . . . . . . . . . . 8
5.2. Tunneled Packets. . . . . . . . . . . . . . . . . . . . . . 8 5.2.2. IP in MPLS . . . . . . . . . . . . . . . . . . . . . . 8
5.2.1. IP in IP . . . . . . . . . . . . . . . . . . . . . . . . 9 5.3. Multi-Hop Protocol Sessions . . . . . . . . . . . . . . . 9
5.2.2. IP in MPLS . . . . . . . . . . . . . . . . . . . . . . . 10 6. Applicability Statement . . . . . . . . . . . . . . . . . . . 10
5.3. Multi-Hop Protocol Sessions . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Applicability Statement. . . . . . . . . . . . . . . . . . . . 12 8. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 12 8.1. Changes between -05 and -06 . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References. . . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
8.2. Informative References. . . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . . 11
9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 Appendix A. Multihop GTSM . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 13
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 TCP/IP based control plane from CPU-utilization based a router's IP based control plane from CPU-utilization based attacks.
attacks. In particular, while cryptographic techniques can protect In particular, while cryptographic techniques can protect the router-
the router-based infrastructure (e.g., BGP [RFC1771], [RFC1772]) from based infrastructure (e.g., BGP [RFC4271], [RFC4272]) from a wide
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 [PEERING]. Thus are established between routers that are adjacent [PEERING]. Thus
most protocol peerings are either directly between connected most protocol peerings are either directly between connected
interfaces or at the worst case, are between loopback and loopback, interfaces or at the worst case, are between loopback and loopback,
with static routes to loopbacks. Since TTL spoofing is considered with static routes to loopbacks. Since TTL spoofing is considered
nearly impossible, a mechanism based on an expected TTL value can nearly impossible, a mechanism based on an expected TTL value can
provide a simple and reasonably robust defense from infrastructure provide a simple and reasonably robust defense from infrastructure
attacks based on forged protocol packets from outside the network. attacks based on forged protocol packets from outside the network.
Note, however, that GTSM is not a substitute for authentication Note, however, that GTSM is not a substitute for authentication
mechanisms. In particular, it does not secure against insider on-the- mechanisms. In particular, it does not secure against insider on-
wire attacks, such as packet spoofing or replay. the-wire 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
Limit have identical semantics. As a result, in the remainder of this Limit have identical semantics. As a result, in the remainder of
document the term "TTL" is used to refer to both TTL or Hop Limit (as this document the term "TTL" is used to refer to both TTL or Hop
appropriate). Limit (as appropriate).
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 BCP 14, RFC 2119 document are to be interpreted as described in RFC 2119 [RFC2119].
[RFC2119].
2. Assumptions Underlying GTSM 2. Assumptions Underlying GTSM
GTSM is predicated upon the following assumptions: GTSM is predicated upon the following assumptions:
(i) The vast majority of protocol peerings are between adjacent 1. The vast majority of protocol peerings are between adjacent
routers [PEERING]. routers [PEERING].
(ii) It is common practice for many service providers to 2. It is common practice for many service providers to ingress
ingress filter (deny) packets that have the provider's filter (deny) packets that have the provider's loopback addresses
loopback addresses as the source IP address. as the source IP address.
(iii) Use of GTSM is OPTIONAL, and can be configured on a 3. Use of GTSM is OPTIONAL, and can be configured on a per-peer
per-peer (group) basis. (group) basis.
(iv) The router supports a method of classifying traffic 4. The peer routers both implement GTSM.
destined for the route processor into interesting/control
and not-control queues.
(v) The peer routers both implement GTSM. 5. The router supports a method to use separate resource pools
(e.g., queues, processing quotas) for differently classified
traffic.
Note that this document does not prescribe further restrictions that
a router may apply to the packets not matching the GTSM filtering
rules, such as dropping packets that do not match any configured
protocol session and rate-limiting the rest. This document also does
not suggest the actual means of resource separation, as those are
hardware and implementation-specific.
The possibility of DoS attack prevention, however, is based on the
assumption that packet classification and separation of their paths
is done before they go through a scarce resource in the system. In
practice, this means that, the closer GTSM processing is done to the
line-rate hardware, the more 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 envisioned by RFC automatic GTSM capability negotiation, such as is envisioned by RFC
2842 [RFC2842] 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
skipping to change at page 5, line 27 skipping to change at page 5, line 8
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., has the source/destination
of configured peer routers). 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).
Since the vast majority of our peerings are between adjacent routers, Since the vast majority of peerings are between adjacent routers, we
we can set the TTL on the protocol packets to 255 (the maximum can set the TTL on the protocol packets to 255 (the maximum possible
possible for IP) and then reject any protocol packets that come in for IP) and then reject any protocol packets that come in from
from configured peers which do NOT have an inbound TTL of 255. configured peers which 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
large diameter multi-hop peerings. In the event that an the attack large diameter multi-hop peerings. In the event that an the attack
comes in from a compromised multi-hop peering, that peering can be comes in from a compromised multi-hop peering, that peering can be
shut down (a method to reduce exposure to multi-hop attacks is shut down (a method to reduce exposure to multi-hop attacks is
outlined below). outlined below).
3. GTSM Procedure 3. GTSM Procedure
If GTSM is not built into the protocol and used as an additional If GTSM is not built into the protocol and used as an additional
feature (e.g., for BGPv4, or LDP), it SHOULD NOT be enabled by feature (e.g., for BGP, LDP, or MSDP), it SHOULD NOT be enabled by
default. Each session protected with GTSM is associated with a default.
variable TrustRadius that denotes the distance from the node
performing the GTSM check to the trusted sources of protocol packets.
(i) If GTSM is enabled, an implementation performs the If GTSM is enabled for a protocol session, the following steps are
following procedure: added to the IP packet sending and reception procedures:
(a) For directly connected routers, Sending protocol packets:
o Set the outbound TTL for the protocol connection to The TTL field in all IP packets used for transmission of
255. messages associated with GTSM-enabled protocol sessions MUST be
set to 255. This also related error handling messages such as
TCP RSTs or ICMP errors.
o For each configured protocol peer: On some architectures, the TTL of control plane originated
traffic is under some configurations decremented in the
forwarding plane. The TTL of GTSM-enabled sessions MUST NOT be
decremented.
Update the receive path Access Control List (ACL) Receiving protocol packets:
or firewall to only allow protocol packets to pass
onto the Route Processor (RP) that have the correct
<source, srcPort, destination, destPort, TTL>
tuple. The TTL must either be 255 (for a directly
connected peer), or 255 - TrustRadius for a
multi-hop peer. We specify a range here to achieve
some robustness to changes in topology. Any
directly connected (i.e., such as may be used in a
BGP implementation to determine whether a peer is
directly connected) check MUST be disabled for
such peerings.
It is assumed that a receive path ACL is an ACL The GTSM packet identification step associates each received
that is designed to control which packets are packet addressed to the router's control plane with one of the
allowed to go to the RP. This procedure will only following three trustworthiness categories:
allow protocol packets from adjacent router to pass
onto the RP.
(b) Otherwise, a TTL value in a received packet is + Unknown: these are packets that cannot be associated with
considered valid if it is not less than any registered GTSM-enabled session, and hence GTSM cannot
(255 - TrustRadius). make any judgement on the level of risk associated with
them.
In summary, if TrustRadius is set to zero for a particular + Trusted: these are packets that have been identified as
session, only packets from directly connected neighbors belonging to one of the GTSM-enabled sessions, and their TTL
(TTL=255) will be considered valid. As a result, values are within the expected range.
TrustRadius values greater than 0 will allow packets from
more remote nodes to be accepted.
(ii) If GTSM is not enabled, normal protocol behavior is followed. + Dangerous: these are packets that have been identified as
belonging to one of the GTSM-enabled sessions, but their TTL
values are NOT within the expected range, and hence GTSM
believes there is a risk that the packets have been spoofed.
3.1. Multi-hop Scenarios The exact policies applied to packets of different
classifications are not postulated in this document and are
expected to be configurable. Configurability is likely
necessary particular with the treatment of related messages
such as ICMP errors and TCP RSTs. It should be noted that
fragmentation may restrict the amount of information available
to the classification.
When a multi-hop protocol session is required, we set the expected However, by default, the implementations:
TTL value to be 255 - TrustRadius. This approach provides a
qualitatively lower degree of security for the protocol implementing
GTSM (i.e., a DoS attack could theoretically be launched by
compromising some box in the path). However, GTSM will still catch
the vast majority of observed DDoS attacks (launched from outside the
network) against a given protocol. Note that since the number of hops
can change rapidly in real network situations, it is considered that
GTSM may not be able to handle this scenario adequately and an
implementation MAY provide OPTIONAL support.
3.1.1. Intra-domain Protocol Handling + SHOULD ensure that packets classified as Dangerous do not
compete for resources with packets classified as Trusted or
Unknown.
In general, GTSM SHOULD NOT used for intra-domain protocol peers or + MUST NOT drop (as part of GTSM processing) packets
adjacencies. The special case of iBGP peers can be protected by classified as Trusted or Unknown.
filtering at the network edge for any packet that has a source
address of one of the loopback addresses used for the intra-domain + MAY drop packets classified as Dangerous.
peering. In addition, the current best practice is to further protect
such peers or adjacencies with an MD5 signature [RFC2385].
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, Pekka Savola, Borkenhagen, Randy Bush, Alfred Hoenes, Vern Paxon, Robert Raszuk and
Robert Raszuk and Alex Zinin also provided useful feedback on earlier Alex Zinin also provided useful feedback on earlier versions of this
versions of this document. David Ward provided insight on the document. David Ward provided insight on the generalization of the
generalization of the original BGP-specific idea. original BGP-specific idea. Alex Zinin and Alia Atlas provided
significant amount of feedback for the newer versions of the
document.
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 8, line 22 skipping to change at page 7, line 23
it can determine how many router hops away it is (again, assuming it can determine how many router hops away it is (again, assuming
none of the routers in the path are compromised in such a way that none of the routers in the path are compromised in such a way that
they would reset the packet's TTL). 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 hasn't been tunneled to the decapsulator, and the intervening routers
are operating in accordance with RFC 791 [RFC791]). 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
authentication at the tunnel endpoints, as well as how the tunneled
packets are protected in flight. Such mechanisms are, however,
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 occurs when a protocol packet is tunneled to a difficult to spoof may occur when a protocol packet is tunneled and
decapsulator who then forwards the packet to a directly connected the tunnel is not integrity-protected (i.e., the lower layer is
protocol peer. In this case the decapsulator (tunnel endpoint) can compromised).
either be the penultimate hop, or the last hop itself. A related case
arises when the protocol packet is tunneled directly to the protocol
peer (the protocol peer is the decapsulator).
When the protocol packet is encapsulated in IP, it is possible to When the protocol packet is tunneled directly to the protocol peer
spoof the TTL. It may also be impossible to legitimately get the (the protocol peer is the decapsulator), the GTSM provides no added
packet to the protocol peer with a TTL of 255, as in the IP in MPLS protection as the security depends entirely on the integrity of the
cases described below. tunnel.
Finally, note that the security of any tunneling technique depends When the protocol packet is tunneled to the penultimate hop which
heavily on authentication at the tunnel endpoints, as well as how the then forwards the packet to a directly connected protocol peer, TTL
tunneled packets are protected in flight. Such mechanisms are, is decremented as described below except in some myriad Bump-in-the-
however, beyond the scope of this memo. Wire (BITW) cases [BITW].
In IP-in-MPLS cases described below, the TTL is always decremented by
at least one.
5.2.1. IP in IP 5.2.1. IP in 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 (e.g., in IP-in-IP [RFC2003], to a directly connected protocol peer (e.g., in IP-in-IP [RFC2003],
GRE [RFC2784], or various forms of IPv6-in-IPv4 [RFC2893]). These GRE [RFC2784], or various forms of IPv6-in-IPv4 [RFC4213]). These
cases are depicted below. 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 egress] [TTL=255 at egress]
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]
In the first case, in which the encapsulated packet is tunneled In the first case, in which the encapsulated packet is tunneled
directly to the protocol peer, the encapsulated packet's TTL can be directly to the protocol peer, the encapsulated packet's TTL can be
set arbitrary value. In the second case, in which the encapsulated set arbitrary value. In the second case, in which the encapsulated
packet is tunneled to a decapsulator (tunnel endpoint) which then packet is tunneled to a decapsulator (tunnel endpoint) which then
forwards it to a directly connected protocol peer, RFC 2003 specifies forwards it to a directly connected protocol peer, RFC 2003 specifies
the following behavior: the following behavior:
skipping to change at page 10, line 41 skipping to change at page 9, line 5
it may not be possible to deliver the protocol packet to the peer it may not be possible to deliver the protocol packet to the peer
with a TTL of 255. with a TTL of 255.
5.2.2. IP in MPLS 5.2.2. IP in MPLS
Protocol packets may also be tunneled over MPLS to a protocol peer Protocol packets may also be tunneled over MPLS to a protocol peer
which either the penultimate hop (when the penultimate hop popping which either the penultimate hop (when the penultimate hop popping
(PHP) is employed [RFC3032]), or one hop beyond the penultimate hop. (PHP) is employed [RFC3032]), or one hop beyond the penultimate hop.
These cases are depicted below. These cases are depicted below.
Peer router ---------- Penultimate Hop (PH) and peer Peer router -------- Penultimate Hop (PH) and peer
TTL=255 [tunnel] [TTL=255 at ingress] TTL=255 [tunnel] [TTL=255 at ingress]
[TTL<=254 at egress] [TTL<=254 at egress]
Peer router ---------- Penultimate Hop -------- On-link peer Peer router -------- Penultimate Hop -------- 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]
TTL handling for these cases is described in RFC 3032. RFC 3032 TTL handling for these cases is described in RFC 3032. RFC 3032
states that when the IP packet is first labeled: states that when the IP packet is first labeled:
... the TTL field of the label stack entry MUST BE set to the ... the TTL field of the label stack entry MUST BE set to the
value of the IP TTL field. (If the IP TTL field needs to be value of the IP TTL field. (If the IP TTL field needs to be
decremented, as part of the IP processing, it is assumed that decremented, as part of the IP processing, it is assumed that
this has already been done.) this has already been done.)
When the label is popped: When the label is popped:
skipping to change at page 11, line 25 skipping to change at page 9, line 34
then the value of the IP TTL field SHOULD BE replaced with the then the value of the IP TTL field SHOULD BE replaced with the
outgoing TTL value, as defined above. In IPv4 this also outgoing TTL value, as defined above. In IPv4 this also
requires modification of the IP header checksum. requires modification of the IP header checksum.
where the definition of "outgoing TTL" is: where the definition of "outgoing TTL" is:
The "incoming TTL" of a labeled packet is defined to be the The "incoming TTL" of a labeled packet is defined to be the
value of the TTL field of the top label stack entry when the value of the TTL field of the top label stack entry when the
packet is received. packet is received.
The "outgoing TTL" of a labeled packet is defined to be the larger of: The "outgoing TTL" of a labeled packet is defined to be the
larger of:
a) one less than the incoming TTL, a) one less than the incoming TTL,
b) zero. b) zero.
In either of these cases, the minimum value by which the TTL could be In either of these cases, the minimum value by which the TTL could be
decremented would be one (the network operator prefers to hide its decremented would be one (the network operator prefers to hide its
infrastructure by decrementing the TTL by the minimum number of LSP infrastructure by decrementing the TTL by the minimum number of LSP
hops, one, rather than decrementing the TTL as it traverses its MPLS hops, one, rather than decrementing the TTL as it traverses its MPLS
domain). As a result, the maximum TTL value at egress from the MPLS domain). As a result, the maximum TTL value at egress from the MPLS
cloud is 254 (255-1), and as a result the check described in section cloud is 254 (255-1), and as a result the check described in section
3 will fail. 3 will fail.
5.3. Multi-Hop Protocol Sessions 5.3. Multi-Hop Protocol Sessions
While the GTSM method is less effective for multi-hop protocol While GTSM could possibly offer a slightly more limited security
sessions, it does close the window on several forms of attack. properties also when used with multi-hop protocol sessions (see
However, in the multi-hop scenario GTSM is an OPTIONAL extension. Appendix A), we do not specify GTSM for multi-hop scenarios due to
Protection of the protocol infrastructure beyond what is provided by simplicity, lack of deployment and implementation.
the GTSM method will likely require cryptographic machinery such as
is envisioned by Secure BGP (S-BGP) [SBGP1,SBGP2], and/or other
extensions. Finally, note that in the multi-hop case described
above, we specify a range of acceptable TTLs in order to achieve some
robustness to topology changes. This robustness to topological
change comes at the cost of the loss of some robustness to different
forms of attack.
6. Applicability Statement 6. Applicability Statement
As described above, GTSM is only applicable to environments with GTSM is only applicable to environments with inherently limited
inherently limited topologies (and is most effective in those cases topologies (and is most effective in those cases where protocol peers
where protocol peers are directly connected). In particular, its are directly connected). In particular, its application should be
application should be limited to those cases in which protocol peers limited to those cases in which protocol peers are directly
are either directly connected, or in which the topology between peers connected.
is fairly static and well known, and in which the intervening network
(between the peers) is trusted. Experimentation on GTSM's applicability and security properties is
needed in multi-hop scenarios. The multi-hop scenarios where GTSM
might be applicable is expected to have the following
characteristics: the topology between peers is fairly static and well
known, and in which the intervening network (between the peers) is
trusted.
7. IANA Considerations 7. IANA Considerations
This document creates no new requirements on IANA namespaces This document requires no action from IANA.
[RFC2434].
8. References 8. Changelog
8.1. Normative References NOTE to the RFC-editor: please remove this section before
publication.
[RFC791] Postel, J., "Internet Protocol Specification", 8.1. Changes between -05 and -06
STD 5, RFC 791, September 1981.
[RFC1771] Rekhter, Y. and T. Li (Editors), "A Border o Clarify the assumptions wrt. resource separation and protection
Gateway Protocol (BGP-4)", RFC 1771, March 1995. based on comments from Alex Zinin.
[RFC1772] Rekhter, Y. and P. Gross, "Application of the o Rewrite the GTSM procedure based on text from Alex Zinin.
Border Gateway Protocol in the Internet", RFC
1772, March 1995.
[RFC2003] Perkins, C., "IP Encapsulation with IP", RFC o Reduce TrustRadius and multi-hop scenarios to a mention in an
2003, October 1996. Appendix.
[RFC2119] Bradner, S., "Key words for use in RFCs to o Describe TCP-RST, ICMP error and "related messages" handling.
Indicate Requirement Levels", BCP 14, RFC 2119,
March 1997.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via o Update the tunneling security considerations text.
the TCP MD5 Signature Option", RFC 2385, August
1998.
[RFC2461] Narten, T., Nordmark, E. and W. Simpson, o Editorial updates (e.g., shortening the abstract).
"Neighbor Discover for IP Version 6 (IPv6)", RFC
2461, December 1998.
[RFC2784] Farinacci, D., "Generic Routing Encapsulation 9. References
(GRE)", RFC 2784, March 2000.
[RFC2842] Chandra, R. and J. Scudder, "Capabilities 9.1. Normative References
Advertisement with BGP-4", RFC 2842, May 2000.
[RFC2893] Gilligan, R. and E. Nordmark, "Transition [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
Mechanisms for IPv6 Hosts and Routers", RFC 2893, September 1981.
August 2000.
[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
A. and B. Thomas, "LDP Specification", RFC 3036, October 1996.
January 2001.
[RFC3032] Rosen, E. Tappan, D., Fedorkow, G., Rekhter, Y., [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Farinacci, D., Li, T. and A. Conta, "MPLS Label Requirement Levels", BCP 14, RFC 2119, March 1997.
Stack Encoding", RFC 3032, January 2001.
[RFC3667] Bradner, S., "IETF Rights in Contributions", [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
BCP 78, RFC 3667, February, 2004. Discovery for IP Version 6 (IPv6)", RFC 2461,
December 1998.
[RFC3668] Bradner, S., "Intellectual Property Rights in [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
IETF Technology", BCP 79, RFC 3668, February, Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
2004. March 2000.
[SBGP1] Kent, S., C. Lynn, and K. Seo, "Secure Border [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Gateway Protocol (Secure-BGP)", IEEE Journal on Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Selected Areas in Communications, volume 18, Encoding", RFC 3032, January 2001.
number 4, April 2000.
[SBGP2] Kent, S., C. Lynn, J. Mikkelson, and K. Seo, [RFC3392] Chandra, R. and J. Scudder, "Capabilities Advertisement
"Secure Border Gateway Protocol (S-BGP) -- Real with BGP-4", RFC 3392, November 2002.
World Performance and Deployment Issues",
Proceedings of the IEEE Network and Distributed
System Security Symposium, February, 2000.
8.2. Informative References [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, October 2005.
[BFD] Katz, D. and D. Ward, "Bidirectional Forwarding [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Detection", draft-ietf-bfd-base-02.txt, Work in Protocol 4 (BGP-4)", RFC 4271, January 2006.
Progress.
[PEERING] Empirical data gathered from the Sprint and AOL [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis",
backbones, October, 2002. RFC 4272, January 2006.
[RFC2434] Narten, T., and H. Alvestrand, "Guidelines for 9.2. Informative References
Writing an IANA Considerations Section in RFCs",
BCP 26, RFC 2434, October 1998.
[RFC3618] Meyer, D. and W. Fenner, Eds., "The Multicast [BITW] "Thread: 'IP-in-IP, TTL decrementing when forwarding and
Source Discovery Protocol (MSDP)", RFC 3618, BITW' on int-area list, Message-ID:
October 2003. <Pine.LNX.4.64.0606020830220.12705@netcore.fi>",
June 2006, <http://www1.ietf.org/mail-archive/web/
int-area/current/msg00267.html>.
9. Authors' Addresses [PEERING] "Empirical data gathered from the Sprint and AOL
backbones", October 2002.
Appendix A. Multihop GTSM
NOTE: This is a non-normative part of the specification.
The main applicability of GTSM is for directly connected peers. GTSM
could be used for non-directly connected sessions as well, where the
recipient would check that the TTL is within "TrustRadius" (e.g., 1)
of 255 instead of 255. As such deployment is expected to have a more
limited applicability and different security implications, it is not
specified in this document.
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
Intellectual Property Statement Email: dmm@1-4-5.net
Pekka Savola
Espoo
Finland
Email: psavola@funet.fi
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 15, line 29 skipping to change at page 13, line 45
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.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 80 change blocks. 
257 lines changed or deleted 261 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/