On 04/03/15 10:52, Robert N. M. Watson wrote:
On 3 Apr 2015, at 09:40, Hans Petter Selasky <h...@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
Hi,
I went to wikipedia and looked up covert channel and found this:
https://www.sans.org/security-resources/idfaq/covert_chan.php
What's described there is entirely about Peer2Peer communication. What
I'm describing is broadcast for the whole system or firewall. Don't you
understand that the IP ID counter is _linearly_ adding up and feeding
back the sum to the source. It is like a radio channel for the whole
firewall. Do you know how analog modems work? I have other things to do
this easter and I don't want to spend more time with this either. I
think the people responsible in the IP-stack area should make a fix. The
IP ID must be randomized much more than it is today.
--HPS
_______________________________________________
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
