Other possible protection against RST/SYN attacks (was Re: TCP RST attack

[Charles Swiger]

On Apr 21, 2004, at 4:43 PM, Mike Tancsa wrote:
>> The default TTL gets decremented with every hop, which means that a 
>> packet coming in with a TTL of 255 had to be sent by a directly 
>> connected system.  [ip_ttl is an octet, so it can't hold a larger TTL 
>> value.]  A packet with a TTL of 64 could have been many hops away.
>
> Thanks, I realize that.  My question is, what unintended consequences 
> might happen if the default is changed to 255 from 64.  As one poster 
> said, if a packet generated by that host had a ttl of 255, it would 
> bounce around a lot more if it was trying to reach a host with a bad 
> route somewhere.

Certainly true, but are we talking about changing the default TTL for 
FreeBSD, or only for routers running BGP where both sides agree to 
implement RFC-3682?  I wouldn't expect a router to be initiating much 
traffic on it's own.

> I am no IP expert, but I have been around long enough to know that 
> these default values get set only after long arduous debates and often 
> there are tradeoffs by raising or lowering a value.  I guess I am 
> trying to find that original debate to see what I might be in for by 
> implementing this with my peers who request it.

Changing the TTL to 255 means one should adjust the TCP MSL to ~4 
minutes, rather than one minute.  RFC-791 says:

     This field must be decreased at each point that the internet header
     is processed to reflect the time spent processing the datagram.
     Even if no local information is available on the time actually
     spent, the field must be decremented by 1.  The time is measured in
     units of seconds (i.e. the value 1 means one second).  Thus, the
     maximum time to live is 255 seconds or 4.25 minutes.  Since every
     module that processes a datagram must decrease the TTL by at least
     one even if it process the datagram in less than a second, the TTL
     must be thought of only as an upper bound on the time a datagram may
     exist.  The intention is to cause undeliverable datagrams to be
     discarded, and to bound the maximum datagram lifetime.

     Some higher level reliable connection protocols are based on
     assumptions that old duplicate datagrams will not arrive after a
     certain time elapses.  The TTL is a way for such protocols to have
     an assurance that their assumption is met.

RFC-793 says:

To be sure that a TCP does not create a segment that carries a
   sequence number which may be duplicated by an old segment remaining in
   the network, the TCP must keep quiet for a maximum segment lifetime
   (MSL) before assigning any sequence numbers upon starting up or
   recovering from a crash in which memory of sequence numbers in use was
   lost.  For this specification the MSL is taken to be 2 minutes.  This
   is an engineering choice, and may be changed if experience indicates
   it is desirable to do so.  Note that if a TCP is reinitialized in some
   sense, yet retains its memory of sequence numbers in use, then it need
   not wait at all; it must only be sure to use sequence numbers larger
   than those recently used.

-- 
-Chuck