> 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 [EMAIL PROTECTED]
_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
