draft-gill-gtsh-01.txt - ops dir review

[Randy Bush <randy@psg.com>]

From: Pekka Savola <pekkas@netcore.fi>
To: Randy Bush <randy@psg.com>
cc: ops directorate <ops-dir@ops.ietf.org>
Subject: draft-gill-gtsh-01.txt [Re: Agenda and Package for October 2, 2003
 Telechat]
Date: Tue, 30 Sep 2003 00:35:42 +0300 (EEST)

On Fri, 26 Sep 2003, Randy Bush wrote:
> ****  o draft-gill-gtsh-01.txt
> 	The Generalized TTL Security Mechanism (GTSM) (Experimental) - 2 of 2 
> 	Token: Alex Zinin


==> 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..


                     <source, destination, TTL> 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/

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings