Date: Wed, 21 Apr 2004 17:54:58 -0400 From: Charles Swiger <cswiger@mac.com> To: Mike Tancsa <mike@sentex.net> Cc: freebsd-security@freebsd.org Subject: Re: Other possible protection against RST/SYN attacks (was Re: TCP RST attack Message-ID: <8830A10E-93DE-11D8-90F9-003065ABFD92@mac.com> In-Reply-To: <6.0.3.0.0.20040421163904.0738d960@209.112.4.2> References: <6.0.3.0.0.20040420125557.06b10d48@209.112.4.2> <xzp65buh5fa.fsf@dwp.des.no> <6.0.3.0.0.20040420144001.0723ab80@209.112.4.2> <200404201332.40827.dr@kyx.net> <20040421111003.GB19640@lum.celabo.org> <6.0.3.0.0.20040421121715.04547510@209.112.4.2> <20040421165454.GB20049@lum.celabo.org> <6.0.3.0.0.20040421132605.0901bb40@209.112.4.2> <48FCF8AA-93CF-11D8-9C50-000393C94468@sarenet.es> <6.0.3.0.0.20040421161217.05453308@209.112.4.2> <75226E9B-93D3-11D8-90F9-003065ABFD92@mac.com> <6.0.3.0.0.20040421163904.0738d960@209.112.4.2>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8830A10E-93DE-11D8-90F9-003065ABFD92>