Date: Fri, 20 Jul 2001 09:24:53 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Peter Wemm <peter@wemm.org> Cc: Barry Pederson <bpederson@geocities.com>, freebsd-arch@FreeBSD.ORG Subject: Re: TCP Initial Sequence Numbers: We need to talk Message-ID: <3B585B55.EFBF2F01@mindspring.com> References: <20010720000852.36B7B3811@overcee.netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Peter Wemm wrote: > > My favorite attack for this would be to just ACK the hell > > out of your machine so that it burnt up all your CPU doing > > RC5's, which the attacker could just ignore... > > Exactly. This is the fundamental difference between classic syn cookies > vs the syn_cache compressed tcp state engine stuff. syn cookies move > the expensive part of the syn processing to the ack side, which you can > still attack. > > The BSDi (and improved by NetBSD) syn_cache stuff does lightweight > preprocessing and protects the expensive stack from this crud. It has > optional RFC1948 (or whatever number it is) ISN support as well. I couldn't see where this had really been improved by NetBSD; maybe you can point it out to me. I did like the suggestion last June on -hackers of delaying the state transition from compressed state to full blown state until data had been received, but it was very, very specific to applications where the client sends data first; this means it's useless for SMTP, POP3, and other servers, and you would have to make it an option on the listen socket for it to be useful (e.g. "I, the opener of the socket, promise not to speak until spoken to, when I get connections on this socket"). > Windows NT has something similar too.. They have a compressed tcp state > for tracking massive numbers of TIME_WAIT connections without consuming a > full pcb/tcpcb etc. I'm sure they use this for other things too. This is called a "TIME_WAIT zombie" structure; implementation is really trivial, but requires that the serial numbers not go backwards, as they currently do, since it would panic the kernel when it attempted to reference structure elements which weren't there, in the case that the state machine went backwards (to SYN_SENT, which is what it does, and then it hangs forever). The "SYN cache" and "TIME_WAIT zombie" issues, along with two other technologies which I'm willing to talk to you about off-list at my work address (terry#clickarray.com) are why I regretted the elimination of the TCP template, rather than a reduction in its size. It turns out that they could all use something about 60 bytes in size, and it would have been handy to have not eliminated it, and kept the code simple (not to disparage Mike's work on the elimination). I've also got some patches applicable to many of the Bill Paul drivers that should drastically reduce overhead, as well some other patches to address the top end load behaviour and receiver livelock avoidance (these are extremely complex, and have taken me several weeks to do; I have only recently stabilized them to the point I trust putting them into production). I also have some issues with the "callout wheel" timers, which I have some prototype code to address, and am looking at thevPittsburg patches for SACK and FACK (the rate halving doesn't work quite right). I think that Luigi's TSACK day has come and gone, now that it's supported by Windows by default; too bad FreeBSD didn't integrate many of these innovations earlier on, since much of the research has been taking place on FreeBSD... 8-(. Eventually, we will get FreeBSD beaten into shape, and I expect that most of what I've done will make it back to the project, if it wants it, after a couple of product releases, since we expect to push forward on other fronts which I haven't seen anyone working on yet. Integration into -current will be a bitch, though. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3B585B55.EFBF2F01>