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 02:38, Hans Petter Selasky <hps at selasky.org> wrote:

> I would like have a comment on one final issue about the IP ID field.
> 
> Given two [small] prime numbers: P and Q
> 
> Assume you have a firewall that separate two networks, called A and B, that are not allowed to communicate.
> 
> In network A an application pings the firewall and sees the IP ID field changing P steps.
> 
> In network B an application pings the firewall and sees the IP ID field changing Q steps.
> 
> If the application in network A always see that the IP ID field is changing P steps, it knows the application in network B did not send any packets.
> 
> If the application in network B always see that the IP ID field is changing Q steps, it knows the application in network A did not send any packets.
> 
> Detecting sending and not sending packets can be used as a way of reliable duplex binary communication.
> 
> I think the current and past implementation of the IP ID field in FreeBSD can be used to leak information between networks, or am I totally wrong?
> 
> As long as the IP ID counters are shared between two or more secured networks, there will be a problem. Something along the lines of D2211 might be a way to solve such an information leak without too much overhead!


There are countless covert channels in TCP/IP; breaking the IP implementation to close a covert channel is probably not a worthwhile investment.

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.

Robert