draft-gill-gtsh-01.txt

[Randy Bush <randy@psg.com>]

[ put into data tracker ]

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.