kern/60889 - zero IP id change issues in 5.2RC2

[Andre Oppermann]

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