Date: Thu, 8 Jan 2004 00:18:47 +0000 (GMT) From: Richard Wendland <richard@starburst.demon.co.uk> To: andre@freebsd.org (Andre Oppermann) Cc: freebsd-net@freebsd.org Subject: Re: kern/60889 - zero IP id change issues in 5.2RC2 Message-ID: <200401080018.AAA19786@starburst.demon.co.uk> In-Reply-To: <3FFC8CBE.13B527A3@freebsd.org> from "Andre Oppermann" at Jan 07, 2004 11:48:30 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> 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. 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. 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. 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. > 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. > 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. Richard -- Richard Wendland richard@wendland.org.uk
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200401080018.AAA19786>