Date: Thu, 08 Jan 2004 12:47:23 +0100 From: Andre Oppermann <andre@freebsd.org> To: rw@codeburst.co.uk Cc: freebsd-net@freebsd.org Subject: Re: kern/60889 - zero IP id change issues in 5.2RC2 Message-ID: <3FFD434B.A634FC8B@freebsd.org> References: <200401080018.AAA19786@starburst.demon.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
Richard Wendland wrote: > > > I've attached a patch that fixes the problem with FIN/ACK and one more > > case which got it wrong. > > Well done! I couldn't track that down. > > > 1. Do you think it is necessary to do a htons() on the randomized > > ip_id too? I'd say yes if there is a case where it has to > > monotonically increase afterwards. Does it? > > No need for monotonic increase, it's a nonce and can cycle in any order. Ok. I wasn't sure. > The only need is to be consistent in all the places ip_id is emitted. > Maximising the cycle is a strong consideration (64K for the old-fashioned > incrementing ip_id), and in my view a powerful argument against using > randomized ip_id. Agreed that we need to maximize the cycle. > Without htons() a remote observer may be able to detect if the system > is little-endian or not (in practice today i386 or not); you certainly > can for an incrementing ip_id. There is a security argument for not > disclosing that (so remote attacker has to try more methods), but I > don't think that's a strong argument for the randomized ip_id. Na, there are so many ways to detect the OS/architecture this doesn't matter. > My inclination would be to stick with tradition, htons() for incrementing > ip_id, natural byte order for randomized ip_id. But other views are > perfectly reasonable. I've done it this way to be consistent in all places. > > 2. I have a Win2k machine but have check out how I can get tcp header > > compression to work with my Cisco AS5300 (if it doesn't do that by > > default). Will I see the problem when I do a download from a FreeBSD > > 5.2RC2 machine or do I have to use the Windoze as router sending > > packets upwards?` > > All I know is from that comment in Linux, and that they backed-out their > zero when DF change. > > I suspect Windows VJ compression is easiest to get going with PPP > dial-up access to the Internet (default I'd guess). So a dial-up Windows > system talking to any 5.2RC2 machine on the internet might well be the > easiest way to test this, with tcpdump on the 5.2RC2 machine to check > for excessive retransmission. You'd just make TCP connections from > Windows to 5.2RC2 - web browsing with IE would be a simple way to do that. > > The other consideration is to not use RFC1323 (or any TCP options) > on the connection, as TCP options defeat VJ compression. If Windows > makes the active open I don't think Windows will negotiate RFC1323, > but to be sure maybe set net.inet.tcp.rfc1323=0 on the 5.2RC2 machine. Ok, will try to do that. > > 3. There are indeed devices clearing the DF bit. For example Cisco > > is recommending this in it's trouble shooting section for broadband > > access via DSL/L2TP where the MTU is lower than 1500 because of the > > tunnelling overhead. Make a route-map to unset the DF bit and apply > > it to the incoming interface. > > If that's clearing DF without setting a fresh IP id, then zero ip_ids > when DF is set should certainly not be emitted by FreeBSD, as it will > lead to re-assembly errors with middle-boxen like this. > > Actually setting a fresh IP id is problematic for middle-boxen and I'd be > amazed if they did this. Properly you'd have to try to avoid treading on > the genuine ip_id sequence, which is pretty hard - you need to maintain > a lot of flow state like a NAT box would. > > If you have firm documentary evidence of this we should let the IETF TSVWG > (or the soon to be split off TCP Maintenance WG) know about this to try > to get this recorded in an RFC. I think the proper RFC view would be > clearing DF in middle-boxen is wrong; but practical reality probably > dictates here. I can do that if you like. I fairly certain that the Cisco route-map hack is not setting a new ip_id. The OpenBSD pf.conf man page explicitly mentions that stateful connection tracking is required for clearing DF. So I'd say go ahead and raise this issue in IETF TSVWG. -- Andre
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3FFD434B.A634FC8B>