svn commit: r280971 - in head: contrib/ipfilter/tools share/man/man4 sys/contrib/ipfilter/netinet sys/netinet sys/netipsec sys/netpfil/pf

[Robert N. M. Watson]

On 3 Apr 2015, at 09:40, Hans Petter Selasky <hps at selasky.org> wrote:

>> There are countless covert channels in TCP/IP; breaking the IP implementation to close a covert channel is probably not a worthwhile investment.
> 
> The IP ID channel is a _broadcast_ channel to all devices connected to the same network stack, including all VPN connections and even localhost. It is high speed and it cannot be blocked by firewall rules, and works across large networks. The other covert channels can easily be reduced by firewall rules. This one can't.
> 
> Now that Gleb put in a patch that the shared IP ID counter is not used that frequently, only for specific traffic like ping packets, I believe this is very likely to be abused.

Research into covert channels has been going on for 30+ years, and the conclusion of that research has been that it is almost impossible to eliminate covert channels from designs intended for high-performance data sharing. This is just one covert channel of countless channels, and given that the stack would need to be fundamentally redesigned to eliminate many of them, covert-channel elimination should not be a primary design concern for this code. As such, we might eliminate it as a side effect of another change, but I don't think it's a good motivation to make changes.

>> As indicated in pretty much the original RFC on the topic, IP IDs
>> need to be at minimum unique to a 2-tuple pair, so cannot be
>> unique only at the granularity of TCP or UDP connections, GRE
>> associations, etc. However, our current implementation keeps them
>> globally unique, which means they wrap much faster than
>> necessary. Shifting to unique IP ID spaces for IP 2-tuples would
>> provide for a much longer wrapping time at the cost of
>> maintaining (and looking up!) additional state. There are various
>> ways to improve things -- and not all require a full set of
>> per-IP-2-tuple IP ID counters, for example, you could have hash
>> buckets based on 2 tuples. It's harder to do this in a
>> multiprocessor-scalable way, however, as the uniqueness
>> requirements are global, and the IP ID space is very small -- a
>> more fundamental problem. In general, the world therefore tries
>> quite hard not to fragment, using TCP PMTU and careful MTU
>> selection for UDP (etc). Also, the world has become quite a lot
>> more homogeneous with respect to link-layer MTU over time --
>> e.g., with convergence on Ethernet, although VPNs have made
>> things a bit less fun.
> 
> The IP ID field should have been 64-bit, containing a copy of the 16-bit source and destination TCP/UDP ports and a 32-bit sequence number. Now that's not possible, but how about saying that each unique IP can have at maximum 16 different connections passing to another unique IP. And then reduce the sequence number to 8-bits. So:
> 
> IP ID = ((src port) & 0xF) | (((dst port) & 0xF) << 4) | ((inp->inp_sequence++) << 8);
> 
> Whenever we see TCP PMTU activated we can release some more combinations to a common pool somewhere. Will also work with IP encapsulations, where some bits of the sequence number gets replaced, if the IP ID is encoded the same ...
> 
> You might call me a freshman in the IP stack area and I'm very surprised about all the issues I've come across in this area the last couple of months. I start understanding why DragonFly forked and why there is something called infiniband.

Before engaging further in this conversation, and trying to modify the behaviour of the TCP/IP stack, you need to educate yourself about the design and history of the protocols involved. Otherwise, you're going to repeatedly suggest ideas that are fundamentally broken, and we're going to waste our time shooting them down when you could just have done a bit of background reading and learned the basics of the protocol design and implementation.

Robert


> 
> Robert and Gleb:
> 
> >  multiprocessor-scalable
> 
> Won't r280971 exactly do what you told me was not a good idea and are giving me some critisism for? Namely, result in one IP ID counter per TCP/UDP connection. If you have two applications that run on each their core. One cause updates to the IP-ID value X times per time unit and the other one Y times per time unit. If "(X ⁻ Y)" is odd (50% chance), then at some point the IP-ID *will* resemble exactly to the same value in a predictable fashion, even if the amount of traffic is considered "low". And I think the chance increases with more cores, looking at this from the pure perspective of mathematics.
> 
> Why is then r280971 fine, when it is doing the same like D2211, only D2211 does it in a predictable fashion while r280971 is unpredictable. A clear IP ID number sequence on a TCP stream maybe wouldn't even need an explanation. Even a 12-year-old would understand, a-ha, that TCP stream is incrementing that fast and that stream is incrementing that fast, and in the end there is a collision. When a collision happens we will have a retransmit, and then maybe we can then randomize the next IP ID value a bit to avoid repeated collisions.
> 
> --HPS