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

From: Charles Swiger (cswiger_at_mac.com)
Date: 04/21/04

  • Next message: Gary Corcoran: "Re: Other possible protection against RST/SYN attacks (was Re: TCP RST attack" 
    Date: Wed, 21 Apr 2004 17:54:58 -0400
To: Mike Tancsa <mike@sentex.net>

    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
_______________________________________________
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"
  • Next message: Gary Corcoran: "Re: Other possible protection against RST/SYN attacks (was Re: TCP RST attack"

    Relevant Pages

    • Re: Dynamic IP addresses: changed how?
      ... > relating to the honouring of TTL values. ... then the datagram must be destroyed. ... in internet header processing. ... Lew Pitcher, IT Specialist, Enterprise Data Systems ...
      (comp.os.linux.misc)
    • Re: Incoherent E-mails
      ... Re TTL, yes it's network stack function, and if you look at the basics, ... TCP verses UPD. ... The Novell crap was originally run on IPX ... As for UPD verses TCP - the Berkeley services were UDP - mainly because ...
      (alt.computer.security)
    • packet filter fingerprinting(open but closed, closed but filtered)
      ... that when you have return-rst rule for some tcp packet, ttl field ... tcp ports are blocked by pf and which are open, ... we modify exploit to bind a shell on an open port, ...
      (Bugtraq)
    • Re: traceroute-like tool for UDP or TCP packet
      ... On Thu, 2003-08-21 at 16:00, Ranjeet Shetye wrote: ... >> a defualt TTL, rather than a series of increasing TTLs. ... > own RDP over IP and not have any TCP or UDP at all! ... Ranjeet dot Shetye2 at Zultys dot com ...
      (Security-Basics)
    • Traceroute mit tcp
      ... Doch leider kann man dem nicht die TTL vorgeben. ... und welche Rechner dazwischen Antworten, dass die TTL ggf. ... Mit ping würde das so gehen, aber ich muss TCP und nicht ICMP testen: ...
      (de.comp.os.unix.linux.misc)