The Generalized TTL Security Mechanism (GTSM)
draft-gill-gtsh-04

IESG-review comments:

==> the document cites IPv6 Neighbor Discovery as one applier of this kind
of methodology, but the text in the spec is awfully IPv4-centric.  With
minor rewording ("TTL" to cover for Hop Limit as well), we could have nice
and neat IPv6 spec out of this.

==> should one add a disclaimer somewhere that GTSM is not directly
applicable to protocols employing flooding mechanisms, e.g., where packets
are multicast or broadcast.  Applying it would require that every
implementation would have a special check to disable the propagation of
these special TTL-255 packets.

  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
  from configured peers which do NOT have a TTL in the range 255-254.
  That is, the receive TTL is expected to be within a small range of 1
  or 2 (254-255). The actual value depends upon the architecture, but
  is it is expected that the receiver will verify the range.

==> I'd like to hear more of this "254-255".  Is there really a
significant faction with 254 (because 255 is prevalent -- and IPv6
neighbor discovery, for example, wouldn't work at all with such
architectures!)??  It seems like that we should fix those architectures
instead (or make them have an emulation layer or what have you).


          (a).    For directly connected routers,

                  o Set the TCP TTL for the protocol connection a
                    value in the range 255-254.

==> one should maybe clarify here that you're talking about _outbound_
TTL.  The receive-side checks are described below..


                      tuple. The TTL must
                    either be in the range 255-254 (directly
                    connected peer), or 255-(configured-range-of-hops)
                    for a multi-hop peer. We specify a range here

==> the "255-(configured-range-of-hops)" should actually probably be
"255-(255-configured-range-of-hops)" but that would be even more confusing
:-)

3.1.1.  Intra-domain Protocol Handling


  In general, GTSM is not used for intra-domain protocol peers or
  adjacencies. Current best practice is to protect such peers or
  adjacencies with an MD5 signature [RFC2385]. The special case of iBGP
  peers can be further protected by filtering at the network edge for
  any packet that has a source address of one of the loopbacks
  addresses used for the intra-domain peering.

==> the whole point of GSTM was to avoid the cost of MD5 signature, so I'd
reorder and reword this slightly, like:

  In general, GTSM is not used for intra-domain protocol peers or
  adjacencies. The special case of iBGP peers can be protected by
  filtering at the network edge for any packet that has a source address
  of one of the loopback addresses used for the intra-domain peering.
  In addition, the current best practice is to further protect such peers
  or adjacencies with an MD5 signature [RFC2385].

(as an operational aside, I fail to see why you'd just restrict filtering
out the loopback at your edge.  we certainly filter out everything with a
wrong IP source address....)

                                                                  For
  example, consider the class of attacks based on forged SYN packets
  directed to port 179/tcp on a large core infrastructure routers. In
  this case, the routers respond with SYN/ACKs (or ICMP messages)
  towards the victim, resulting in flooding of the victim's link being
  flooded with SYN/ACK or ICMP traffic. Preventing such attacks will
  likely require that protocol speakers send SYN/ACKs only to
  configured neighbors, and they never send ICMP messages related to
  these events.

==> I fail to see how this is specific to GSTM (or even closely relates to
it).  1) the core routers can't protect against such SYN reflections
except with TTL hack, rate-limiters, or access lists which only work to an
extent; 2) the victims can do the same.

purely editorial
----------------

  This document is a product of an individual.  Comments are solicited
  and should be addressed to the author(s).

==> looks like it's one individual in three different bodies..

  the router-based infrastructure (.e.g., BGP [RFC1771]) from a wide

==> s/.e/e/

                  o Set the TCP TTL for the protocol connection a
                    value in the range 255-254.

==> "TCP TTL"?? the last time I checked, it was still IP ;-)

          (c).    If the TTL is not in the range 255-254 (or

==> this should be (b).

  TTL value to be 255-(configured-range-of-acceptable-of-hops).  While

==> s/of-hops/hops/, or s/acceptable-of-// for consistency

  TTL value to be 255-(configured-range-of-acceptable-of-hops).  While
  this approach provides a qualitatively lower degree of security for
  the protocol implementing GTSM (i.e., an DoS attack could be
  theoretically be launched  by compromising some box in the path).

==> s/While this/This/ (the sentence does not continue).
==> s/  by/ by/

IESG-review comments:

Ops Directorate Reviewer:

High-order bit: good stuff.

It's not clear whether the hack is intended just to protect routing control
information, or also to provide a cheap way to filter out floods targetting
routers.  The text is written mostly with regard to the first, but the
second seems like a significant win, too; except it would then be good to
have some discussion of the fact that the hack isn't applicable to some
of the other ports a router may need to listen on, such as SSH (unless it
has OOB control access), so there's still a flooding vector.

The document doesn't make it clear how GTSM is negotiated.  I assume that
this is because it *isn't* negotiated, but instead is explicitly configured
in.  Worth mentioning.  Might also discuss how to rapidly detect possible
configuration mismatches - if, say, the first packet reply received during
the establishment of a peering session arrives with a TTL that's too low,
then there's very likely a configuration mismatch.  Hmmm, I'm not sure what's
the right thing to do in this case, probably alert it specially and indeed
refuse to establish the peering session, as otherwise there will be a race
condition that can be used to try to subvert the mechanism.

>    the victim protocol speaker decrements TTL properly (clearly, if the
>    either the path or the adjacent peer is compromised, then there are

typo, if the -> if

>            (c).    If the TTL is not in the range 255-254 (or
>                    255-(configured-range-of-hops) for multi-hop
>                    peers), the packet is placed into a low priority
>                    queue, and subsequently logged and/or silently
>                    discarded.

Might emphasize: it is *not* processed.  The "and/or" makes it not
clear whether it might be logged but still processed, which of course
would defeat the whole purpose.

> 3.1.1.  Intra-domain Protocol Handling
>
>
>    In general, GTSM is not used for intra-domain protocol peers or
>    adjacencies. Current best practice is to protect such peers or
>    adjacencies with an MD5 signature [RFC2385]. The special case of iBGP
>    peers can be further protected by filtering at the network edge for
>    any packet that has a source address of one of the loopbacks
>    addresses used for the intra-domain peering.

I didn't get this.  It seems it's applicable to any protocol for which
there's a notion of IP-level adjaceny.

>    directed to port 179/tcp on a large core infrastructure routers. In

a large -> large

>    this case, the routers respond with SYN/ACKs (or ICMP messages)
>    towards the victim, resulting in flooding of the victim's link being
>    flooded with SYN/ACK or ICMP traffic.

I didn't get this.  If the core routers are using GTSM, then they won't
honor the incoming SYNs, and hence won't respond with SYN/ACKs or ICMPs,
right?

(Also, "in flooding ... being flooded" is awkwardly phrased.)

>    [BALDWIN2001]  http://www.sekure.net/docs/detecting_spoof.txt

I can't resolve www.sekure.net.  Given that this is the sole citation for
"TTL spoofing is thought to be basically impossible", it's worth fixing
this.

LC ended. Received several supportive comments (on rtg-area list, rtg-dir, and privately), no negative.
Believe that the idea is useful. Will take to the IESG
when the AD-review comments are addressed:

I do not have any major comments on it, some minor ones
below:

1. BTSH reference in Abstract.

    The abstract refers to BTSH. You may want to consider
    making it BTSH-agnostic, since the reader will not have
    any document to refer to when the BTSH draft expires.

2. Section 3.1.1 "Intra-domain Protocol Handling"

    The section reads as BGP-specific. I.e., it should be
    possible to use the TTL method to protect, say, OSPF
    single-hop adjacencies.

3. Prior art

    You may want to point out that the TTL method has been
    used in other protocols, and point to IPv6 ND [RFC2461],
    for example.