In some email I received from Mikael Olsson, sie wrote: [...] > Darren Reed wrote: > > That aside, my view on this is "funky ACKing" may be within the > > bounds of legal TCP operation, but it's not what any "nornmal" > > FTP client is going to do so throw those packets away. > > I've been asking myself this question. It applies to IDSes too. > (Indeed, I was pondering IDS evasion techniques when I came up with this.) > There _is_ in fact a valid use for partial acknowledgments. > > - Receiving end checks pool of receive window buffers and comes to > the conclusion that there's plenty free. Sends out RWIN=8192 > - Sender sees RWIN=8192 and fires off several full-length segments. > - Receiver receives segments, but, ACK(tm)! Other sockets snarfed all > the buffers! All we can get our hands on is a measly 512 byte one! > > At this point, the receiver can either just drop all segments, _OR_ > grab hold of the 512 first bytes of the first segment, and send out > an ACK that only partially acknowledges the first segment. Sure it can happen but how often does it really happen ? For the minor convienience of dropping whatever packets and causing a full resend, I think I'm happy to discard partial segments. Given this is only currently done for the FTP command channel (and that's hardly a massive user of buffering), I'm not concerned. If it breaks 1 time in 100, but the other 99 are secured, that 1 off is a sacrifice I'm willing to force. [...] > However, IMHO, the same _shouldn't_ have to be true for an attacker that > simply creates file names (without CRLFs in them) via FTP and issues > STAT commands. I'm thinking that f.i. the latest version of ipf stops > this, but not the version currently shipping with NetBSD? I'm not in control of what version ships with NetBSD. SEP. Darren _______________________________________________ firewall-wizards mailing list firewall-wizardsat_private http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
This archive was generated by hypermail 2b30 : Fri Oct 11 2002 - 05:21:37 PDT