RFC 3682:The Generalized TTL Security Mechanism (G...
RFC-Ref

TTL


Click on the red underlined text to get to the source

... The Generalized TTL Security Mechanism (GTSM) is designed to protect a router ...
... loopback and loopback, with static routes to loopbacks. Since TTL spoofing is considered nearly impossible, a mechanism based on an expected TTL value ...
... TTL spoofing is considered nearly impossible, a mechanism based on an expected TTL value can provide a simple and reasonably robust defense from infrastructure ...
... Finally, the GTSM mechanism is equally applicable to both TTL (IPv4) and Hop Limit ...
... Hop Limit (IPv6), and from the perspective of GTSM, TTL and Hop Limit have identical semantics. As a result, in the remainder of ...
... Hop Limit have identical semantics. As a result, in the remainder of this document the term "TTL" is used to refer to both TTL or Hop Limit (as appropriate). ...
... semantics. As a result, in the remainder of this document the term "TTL" is used to refer to both TTL or Hop Limit (as appropriate). ...


... router in the path between the attacker and the victim protocol speaker decrements TTL properly (clearly, if either the path or the adjacent peer is compromised, then there are worse problems to worry about). ...
... Since the vast majority of our peerings are between adjacent routers, we can set the TTL on the protocol packets to 255 (the maximum possible for IP) and then reject any protocol packets that come in ...
... possible for IP) and then reject any protocol packets that come in from configured peers which do NOT have an inbound TTL of 255. GTSM ...


... routers, o Set the outbound TTL for the protocol connection to 255. ...
... RP) that have the correct <source, destination, TTL> tuple. The TTL must either be 255 (for a directly connected peer), or 255-(configured- ...
... destination, TTL> tuple. The TTL must either be 255 (for a directly connected peer), or 255-(configured- range ...
... RP. (b) If the inbound TTL is 255 (for a directly connected peer), or 255-(configured-range-of-acceptable-hops) (for ...
... multi-hop protocol session is required, we set the expected TTL value to be 255-(configured-range-of-acceptable-hops). This approach provides a qualitatively lower degree of security ...


... The use of the TTL field to protect BGP originated with many different people, including Paul Traina and Jon Stewart. Ryan ...


... TTL (Hop Limit) Spoofing ...
... The approach described here is based on the observation that a TTL (or Hop Limit) value of 255 is non-trivial to spoof, since as the ...
... packet passes through routers towards the destination, the TTL is decremented by one. As a result, when a router receives a packet, it ...
... none of the routers in the path are compromised in such a way that they would reset the packet's TTL). Note, however, that while engineering a packet's TTL ...
... TTL). Note, however, that while engineering a packet's TTL such that it has a particular value when sourced from an arbitrary location is difficult (but not impossible), engineering a TTL value ...
... TTL such that it has a particular value when sourced from an arbitrary location is difficult (but not impossible), engineering a TTL value of 255 from non-directly connected locations is not possible (again, assuming none of the directly connected neighbors ...
... 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 decapsulator ...
... encapsulated in IP, it is possible to spoof the TTL. It may also be impossible to legitimately get the packet to the protocol peer with a TTL of 255, as in the IP ...
... spoof the TTL. It may also be impossible to legitimately get the packet to the protocol peer with a TTL of 255, as in the IP in MPLS ...
... Tunnel endpoint router and peer TTL=255 [tunnel] [TTL=255 at ingress] ...
... TTL=255 [tunnel] [TTL=255 at ingress] [TTL=255 at egress] ...
... tunnel] [TTL=255 at ingress] [TTL=255 at egress] Peer router ...
... router ----- On-link peer TTL=255 [tunnel] [TTL=255 at ingress] [TTL ...
... TTL=255 [tunnel] [TTL=255 at ingress] [TTL=254 at ingress] [TTL ...
... TTL=255 [tunnel] [TTL=255 at ingress] [TTL=254 at ingress] [TTL=254 at egress] ...
... TTL=255 at ingress] [TTL=254 at ingress] [TTL=254 at egress] In the first case, in which the encapsulated packet ...
... encapsulated packet is tunneled directly to the protocol peer, the encapsulated packet's TTL can be set arbitrary value. In the second case, in which the encapsulated packet is tunneled to a decapsulator ...
... When encapsulating a datagram, the TTL in the inner IP header is decremented by one if the tunneling ...
... forwarding the datagram; otherwise, the inner header TTL is not changed during encapsulation. If the resulting TTL ...
... TTL is not changed during encapsulation. If the resulting TTL in the inner IP header is 0, the datagram ...
... encapsulator MUST NOT encapsulate a datagram with TTL = 0. Hence the inner IP packet ...
... Hence the inner IP packet header's TTL, as seen by the decapsulator, can be set to an arbitrary value (in particular, 255). As a result, ...
... can be set to an arbitrary value (in particular, 255). As a result, it may not be possible to deliver the protocol packet to the peer with a TTL of 255. ...
... 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] ...
... tunnel] [TTL=255 at ingress] [TTL<=254 at egress] Peer router ...
... router ---------- Penultimate Hop -------- On-link peer TTL=255 [tunnel] [TTL=255 at ingress] [TTL ...
... TTL=255 [tunnel] [TTL=255 at ingress] [TTL <=254 at ingress] [TTL ...
... TTL=255 [tunnel] [TTL=255 at ingress] [TTL <=254 at ingress] [TTL<=254 at egress] ...
... TTL=255 at ingress] [TTL <=254 at ingress] [TTL<=254 at egress] TTL ...
... TTL<=254 at egress] TTL handling for these cases is described in RFC 3032prop. RFC 3032prop ...
... IP packet is first labeled: ... the TTL field of the label stack entry MUST BE set to the value of the IP TTL field. (If the IP TTL ...
... ... 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 decremented, as part of the IP ...
... 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 decremented, as part of the IP processing, it is assumed that ...
... When a label is popped, and the resulting label stack is empty, then the value of the IP TTL field SHOULD BE replaced with the outgoing TTL value, as defined above. In IPv4 ...
... then the value of the IP TTL field SHOULD BE replaced with the outgoing TTL value, as defined above. In IPv4 this also requires modification of the IP header ...
... checksum. where the definition of "outgoing TTL" is: The "incoming TTL ...
... TTL" is: 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 packet is ...
... 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 packet is received. ...
... received. The "outgoing TTL" of a labeled packet is defined to be the larger of: ...
... of: 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 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 hops, one, rather than decrementing the TTL ...
... TTL by the minimum number of LSP hops, one, rather than decrementing the TTL as it traverses its MPLS domain ...
... MPLS domain). As a result, the maximum TTL value at egress from the MPLS cloud ...
... 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 ...



Google
Web
RFC-Ref