draft-ietf-rtgwg-rfc3682bis-07.txt   draft-ietf-rtgwg-rfc3682bis-08.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 Intended status: Standards Track P. Savola, Ed.
Expires: May 26, 2007 November 22, 2006 Expires: June 16, 2007 C. Pignataro
December 13, 2006
The Generalized TTL Security Mechanism (GTSM) The Generalized TTL Security Mechanism (GTSM)
draft-ietf-rtgwg-rfc3682bis-07.txt draft-ietf-rtgwg-rfc3682bis-08.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 35 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 May 26, 2007. This Internet-Draft will expire on June 16, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2006). Copyright (C) The IETF Trust (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 verify whether the packet originated within the same link has been to verify whether the packet was originated by an adjacent node on a
used in many recent protocols. This document generalizes this connected link has been used in many recent protocols. This document
technique. This document obsoletes RFC 3682. generalizes this technique. This document obsoletes 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 . . . . . . . . . . . . . . . . . . . . . . . 6 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 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 in IP . . . . . . . . . . . . . . . . . . . . . . . 7 5.2.1. IP Tunneled over IP . . . . . . . . . . . . . . . . . 8
5.2.2. IP in MPLS . . . . . . . . . . . . . . . . . . . . . . 8 5.2.2. IP Tunneled over MPLS . . . . . . . . . . . . . . . . 9
5.3. Multi-Hop Protocol Sessions . . . . . . . . . . . . . . . 9 5.3. Onlink Attackers . . . . . . . . . . . . . . . . . . . . . 11
6. Applicability Statement . . . . . . . . . . . . . . . . . . . 9 5.4. Fragmentation Considerations . . . . . . . . . . . . . . . 11
6.1. Backwards Compatibility . . . . . . . . . . . . . . . . . 10 5.5. Multi-Hop Protocol Sessions . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. Applicability Statement . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Backwards Compatibility . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Appendix A. Multihop GTSM . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13
Appendix B. Changes Since RFC3682 . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix C. Draft Changelog . . . . . . . . . . . . . . . . . . 12 Appendix A. Multi-hop GTSM . . . . . . . . . . . . . . . . . . . 14
Appendix C.1. Changes between -06 and -07 . . . . . . . . . . . . 12 Appendix B. Changes Since RFC3682 . . . . . . . . . . . . . . . 14
Appendix C.2. Changes between -05 and -06 . . . . . . . . . . . . 12 Appendix C. Draft Changelog . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Appendix C.1. Changes between -07 and -08 . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 14 Appendix C.2. Changes between -06 and -07 . . . . . . . . . . . . 15
Appendix C.3. Changes between -05 and -06 . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 17
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
skipping to change at page 3, line 46 skipping to change at page 3, line 46
"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 RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Assumptions Underlying GTSM 2. Assumptions Underlying GTSM
GTSM is predicated upon the following assumptions: GTSM is predicated upon the following assumptions:
1. The vast majority of protocol peerings are between adjacent 1. The vast majority of protocol peerings are between adjacent
routers. routers.
2. It is common practice for many service providers to ingress 2. Service providers may or may not configure strict ingress
filter (deny) packets that have the provider's loopback addresses filtering [RFC3704] on non-trusted links. If maximal protection
as the source IP address. is desired, such filtering is necessary as described in
Section 2.2.
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 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 DoS attack prevention, however, is based on the The possibility of denial-of-service (DoS) attack prevention,
assumption that packet classification and separation of their paths however, is based on the assumption that packet classification and
is done before they go through a scarce resource in the system. In separation of their paths is done before they go through a scarce
practice, this means that, the closer GTSM processing is done to the resource in the system. In practice, this means that, the closer
line-rate hardware, the more resistant the system is to the DoS GTSM processing is done to the line-rate hardware, the more resistant
attacks. 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 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
skipping to change at page 5, line 8 skipping to change at page 5, line 11
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).
For maximal protection, ingress filtering should be applied before
the packet goes through the scarce resource. Otherwise an attacker
directly connected to one interface could disturb a GTSM-protected
session on the same or another interface. Interfaces which aren't
configured with this filtering (e.g., backbone links) are assumed to
not have such attackers (i.e., trusted).
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
GTSM-protected peering session with a directly connected neighbor.
We assume that: 1) there are no tunneled packets terminating on the
router, 2) tunnels terminating on the router are assumed to be secure
and endpoints are trusted, 3) tunnel decapsulation includes source
address spoofing prevention [RFC3704], or 4) the GTSM-enabled session
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 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
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 used as an additional If GTSM is not built into the protocol and 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. default in order to be backward-compatible with the unmodified
protocol.
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 related error handling
messages such as TCP RSTs or ICMP errors. messages associated with said session, such as TCP RSTs or ICMP
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 7, line 37 skipping to change at page 8, line 9
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 no added (the protocol peer is the decapsulator), the GTSM provides some
protection as the security depends entirely on the integrity of the limited added protection as the security depends entirely on the
tunnel. integrity of the tunnel.
When the protocol packet is tunneled to the penultimate hop which For protocol adjacencies over a tunnel, if the tunnel itself is
then forwards the packet to a directly connected protocol peer, TTL deemed secure (e.g., the underlying infrastructure is deemed secure,
is decremented as described below except in some myriad Bump-in-the- and the tunnel offers degrees of protection against spoofing such as
Wire (BITW) cases [BITW]. keys or cryptographic security), the GTSM can serve as a check that
the protocol packet did not originate beyond the head-end of the
tunnel. In addition, if the protocol peer can receive packets for
the GTSM-protected protocol session from outside the tunnel, the GTSM
can help thwart attacks from beyond the adjacent router.
In IP-in-MPLS cases described below, the TTL is always decremented by When the tunnel tail-end decapsulates the protocol packet and then
at least one. IP-forwards the packet to a directly connected protocol peer, TTL is
decremented as described below. This means that the tunnel
decapsulator is the penultimate node from the GTSM-protected protocol
peer's perspective. As a result, the GTSM check protects from
attackers encapsulating packets to your peers. However, specific
cases arise when the connection from the tunnel decapsulator node to
the protocol peer is not an IP forwarding hop, where TTL-decrementing
does not happen (e.g., layer-2 tunneling, bridging, etc). In the
IPsec architecture [RFC4301], another example is the use of Bump-in-
the-Wire (BITW) [BITW].
5.2.1. IP in 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 (e.g., in IP-in-IP [RFC2003], to a directly connected protocol peer. Examples of tunneling IP over
GRE [RFC2784], or various forms of IPv6-in-IPv4 [RFC4213]). These IP include IP-in-IP [RFC2003], GRE [RFC2784], or various forms of
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 egress] [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]
In the first case, in which the encapsulated packet is tunneled In both cases, the encapsulator (origination tunnel endpoint) is the
directly to the protocol peer, the encapsulated packet's TTL can be (supposed) sending protocol peer. The TTL in the inner IP datagram
set to an arbitrary value. can be set to 255, since RFC 2003 specifies the following behavior:
In the second case, in which the encapsulated packet is tunneled to a
decapsulator (tunnel endpoint) which then forwards it to a directly
connected protocol peer, RFC 2003 specifies the following behavior:
When encapsulating a datagram, the TTL in the inner IP When encapsulating a datagram, the TTL in the inner IP
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. If inner header TTL is not changed during encapsulation.
the resulting TTL in the inner IP header is 0, the
datagram is discarded and an ICMP Time Exceeded message In the first case, the encapsulated packet is tunneled directly to
SHOULD be returned to the sender. An encapsulator MUST the protocol peer (also a tunnel endpoint), and therefore the
NOT encapsulate a datagram with TTL = 0. encapsulated packet's TTL can be received by the protocol peer with
an arbitrary value, including 255.
In the second case, the encapsulated packet is tunneled to a
decapsulator (tunnel endpoint) which then forwards it to a directly
connected protocol peer. For IP-in-IP tunnels, RFC 2003 specifies
the following decapsulator behaviour:
The TTL in the inner IP header is not changed when decapsulating.
If, after decapsulation, the inner datagram has TTL = 0, the
decapsulator MUST discard the datagram. If, after decapsulation,
the decapsulator forwards the datagram to one of its network
interfaces, it will decrement the TTL as a result of doing normal
IP forwarding. See also Section 4.4.
And similarly, for GRE tunnels, RFC 2784 specifies the following
decapsulator behaviour:
When a tunnel endpoint decapsulates a GRE packet which has an IPv4
packet as the payload, the destination address in the IPv4 payload
packet header MUST be used to forward the packet and the TTL of
the payload packet MUST be decremented.
Hence the inner IP packet header's TTL, as seen by the decapsulator, Hence the inner IP packet header's TTL, as seen by the decapsulator,
can be set to an arbitrary value (in particular, 255), however as the can be set to an arbitrary value (in particular, 255). If the
decapsulator forwards the protocol packet to the peer, TTL will be decapsulator is also the protocol peer, it is possible to deliver the
decremented. protocol packet to it with a TTL of 255 (first case). On the other
hand, if the decapsulator needs to forward the protocol packet to a
directly connected protocol peer, the TTL will be decremented (second
case).
5.2.2. IP in MPLS 5.2.2. IP Tunneled over MPLS
Protocol packets may also be tunneled over MPLS to a protocol peer Protocol packets may also be tunneled over MPLS Label Switched Paths
which either the penultimate hop (when the penultimate hop popping (LSPs) to a protocol peer. The following diagram depicts the
(PHP) is employed [RFC3032]) or the final hop These cases are topology.
depicted below.
Peer router -------- Penultimate Hop (PH) and peer Peer router -------- LSP Termination router and peer
TTL=255 [tunnel] [TTL=255 at ingress] TTL=255 MPLS LSP [TTL=x at ingress]
[TTL<=254 at egress] MPLS LSPs can operate in Uniform or Pipe tunneling models. The TTL
handling for these models is described in RFC 3443 [RFC3443] that
updates RFC 3032 [RFC3032] in regards to TTL processing in MPLS
networks. RFC 3443 specifies the TTL processing in both Uniform and
Pipe Models, which in turn can used with or without penultimate hop
popping (PHP). The TTL processing in these cases results in
different behaviors, and therefore are analyzed separately. Please
refer to Section 3.1 through Section 3.3 of RFC 3443.
Peer router -------- Penultimate Hop -------- On-link peer The main difference from a TTL processing perspective between Uniform
TTL=255 [tunnel] [TTL=255 at ingress] [TTL <=254 at ingress] and Pipe Models at the LSP termination node resides in how the
[TTL<=254 at egress] incoming TTL (iTTL) is determined. The tunneling model determines
TTL handling for these cases is described in RFC 3032. RFC 3032 the iTTL: For Uniform Model LSPs, the iTTL is the value of the TTL
states that when the IP packet is first labeled: field from the popped MPLS header (encapsulating header), whereas for
Pipe Model LSPs, the iTTL is the value of the TTL field from the
exposed header (encapsulated header).
... the TTL field of the label stack entry MUST BE set to the For Uniform Model LSPs, RFC 3443 states that at ingress:
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
this has already been done.)
When the label is popped: For each pushed Uniform Model label, the TTL is copied from the
label/IP-packet immediately underneath it.
When a label is popped, and the resulting label stack is empty, From this point, the inner TTL (TTL of the tunneled IP datagram)
then the value of the IP TTL field SHOULD BE replaced with the represents non-meaningful information, and at the egress node or
outgoing TTL value, as defined above. In IPv4 this also during PHP, the ingress TTL (iTTL) is equal to the TTL of the popped
requires modification of the IP header checksum. MPLS header (see Section 3.1 of RFC 3443). In consequence, for
Uniform Model LSPs of more than one hop, the TTL at ingress (iTTL)
will be less than 255 (x <= 254), and as a result the check described
in Section 3 of this document will fail.
where the definition of "outgoing TTL" is: The TTL treatment is identical between Short Pipe Model LSPs without
PHP and Pipe Model LSPs (without PHP only). For these cases, RFC
3443 states that:
The "incoming TTL" of a labeled packet is defined to be the For each pushed Pipe Model or Short Pipe Model label, the TTL
value of the TTL field of the top label stack entry when the field is set to a value configured by the network operator. In
packet is received. most implementations, this value is set to 255 by default.
The "outgoing TTL" of a labeled packet is defined to be the In these models, the forwarding treatment at egress is based on the
larger of: tunneled packet as opposed to the encapsulation packet. The ingress
TTL (iTTL) is the value of the TTL field of the header that is
exposed, that is the tunneled IP datagram's TTL. The protocol
packet's TTL as seen be the LSP termination can therefore be set to
an arbitrary value (including 255). If the LSP termination router is
also the protocol peer, it is possible to deliver the protocol packet
with a TTL of 255 (x = 255).
a) one less than the incoming TTL, Finally, for Short Pipe Model LSPs with PHP, the TTL of the tunneled
b) zero. packet is unchanged after the PHP operation. Therefore, the same
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, the TTL at egress has the same value with or without
PHP.
In either of these cases, the minimum value by which the TTL could be In conclusion, GTSM-checks are possible for IP tunneled over Pipe
decremented would be one (the network operator prefers to hide its model LSPs, but not for IP tunneled over Uniform model LSPs.
infrastructure by decrementing the TTL by the minimum number of LSP Additionally, for all tunneling modes, if the LSP termination router
hops, one, rather than decrementing the TTL as it traverses its MPLS needs to forward the protocol packet to a directly connected protocol
domain). As a result, the maximum TTL value at egress from the MPLS peer, it is not possible to deliver the protocol packet to the
cloud is 254 (255-1), and as a result the check described in section protocol peer with a TTL of 255. If the packet is further forwarded,
3 will fail. the outgoing TTL (oTTL) is calculated by decrementing iTTL by one.
5.3. Multi-Hop Protocol Sessions 5.3. Onlink Attackers
While GTSM could possibly offer some small though difficult to As described in Section 2, an attacker directly connected to one
quantify degree of protection when used with multi-hop protocol interface can disturb a GTSM-protected session on the same or another
sessions (see Appendix A), we do not specify GTSM for multi-hop interface (by spoofing a GTSM peer's address) unless ingress
scenarios due to simplicity, lack of deployment and implementation. filtering has been applied on the connecting interface. As a result,
interfaces which do not include such protection need to be trusted
not to originate attacks on the router.
5.4. Fragmentation Considerations
As already mentioned, fragmentation may restrict the amount of
information available for classification. Since non-initial IP
fragments do not contain Layer 4 information, it is highly likely
that they cannot be associated with a registered GTSM-enabled
session. Following the receiving protocol procedures described in
Section 3, non-initial IP fragments would likely be classified with
Unknown trustworthiness. And since the IP packet would need to be
reassembled in order to be processed, the end result is that the
initial-fragment of a GTSM-enabled session effectively receives the
treatment of an Unknown-trustworthiness packet, and the complete
reassembled packet receives the aggregate of the Unknowns.
Further, reassembly requires to wait for all the fragments and
therefore likely invalidates or weakens the fifth assumption
presented in Section 2: it may not be possible to classify non-
initial fragments before going through a scarce resource in the
system, when fragments need to be buffered for reassembly and later
processed by a CPU. That is, when classification cannot be done with
the required granularity, non-initial fragments of GTSM-enabled
session packets would not use different resource pools.
Consequently, to get practical protection from fragment attacks,
operators may need to rate-limit or discard all received fragments.
As such, it is highly recommended for GTSM-protected protocols to
avoid fragmentation and reassembly by manual MTU tuning, using
adaptive measures such as Path MTU Discovery (PMTUD), or any other
available method.
5.5. Multi-Hop Protocol Sessions
GTSM could possibly offer some small though difficult to quantify
degree of protection when used with multi-hop protocol sessions (see
Appendix A). In order to avoid having to quantify the degree of
protection and the resulting applicability of multi-hop, we only
describe the single-hop 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.
Experimentation on GTSM's applicability and security properties is Experimentation on GTSM's applicability and security properties is
skipping to change at page 10, line 27 skipping to change at page 12, line 46
RSTs or ICMP errors. This specification mandates setting and RSTs or ICMP errors. This specification mandates setting and
verifying TTL=255 of those as well as the main protocol packets. verifying 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 discarded. the latter category of RFC 3682 implementations would be classified
This is not believed to be a significant problem because protocols do as Dangerous and treated as described in Section 3. This is not
not depend on related messages (e.g., typically having a protocol believed to be a significant problem because protocols do not depend
exchange for closing the session instead of doing a TCP-RST), and on related messages (e.g., typically having a protocol exchange for
indeed the delivery of related messages is not reliable. As such, closing the session instead of doing a TCP-RST), and indeed the
related messages typically provide an optimization to shorten a delivery of related messages is not reliable. As such, related
protocol keepalive timeout. Regardless of these issues, given that messages typically provide an optimization to shorten a protocol
related messages provide a significant attack vector to e.g., reset keepalive timeout. Regardless of these issues, given that related
protocol sessions, making this further restriction seems sensible. messages provide a significant attack vector to e.g., reset protocol
sessions, making this further restriction seems sensible.
7. IANA Considerations 7. IANA Considerations
This document requires no action from IANA. This document requires no action from IANA.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
skipping to change at page 11, line 23 skipping to change at page 13, line 41
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
March 2000. March 2000.
[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.
[RFC3392] Chandra, R. and J. Scudder, "Capabilities Advertisement [RFC3392] Chandra, R. and J. Scudder, "Capabilities Advertisement
with BGP-4", RFC 3392, November 2002. with BGP-4", RFC 3392, November 2002.
[RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing
in Multi-Protocol Label Switching (MPLS) Networks",
RFC 3443, January 2003.
[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.
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
RFC 4272, January 2006. 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>.
Appendix A. Multihop GTSM [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004.
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis",
RFC 4272, January 2006.
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 "TrustRadius" (e.g., 1)
of 255 instead of 255. As such deployment is expected to have a more of 255 instead of 255. As such deployment is expected to have a more
limited applicability and different security implications, it is not limited applicability and different security implications, it is not
specified in this document. specified in this document.
skipping to change at page 12, line 23 skipping to change at page 15, line 5
o Clarifications relating to security with tunneling. o Clarifications relating to security with tunneling.
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 -06 and -07 Appendix C.1. 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 behaviour 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.2. 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.2. Changes between -05 and -06 Appendix C.3. 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.
skipping to change at page 13, line 19 skipping to change at page 16, line 23
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 Pekka Savola (editor)
Espoo Espoo
Finland Finland
Email: psavola@funet.fi Email: psavola@funet.fi
Carlos Pignataro
Email: cpignata@cisco.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2006). Copyright (C) The IETF Trust (2006).
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
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 End of changes. 43 change blocks. 
123 lines changed or deleted 280 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/