Patch to reduce use of global IP ID value(s) to avoid leaking information

Robert N. M. Watson rwatson at FreeBSD.org
Sat Apr 4 19:06:46 UTC 2015


On 4 Apr 2015, at 19:24, Hans Petter Selasky <hps at selasky.org> wrote:

> The IPv4 protocol was intentionally designed to be such, that in any ways trying to make it more secure, will require additional CPU overhead, like keeping track of 2-tuples for generating per-stream IP IDs, that it will not be feasible in practice and then vendors will do insecure implementations instead of secure implementations to get the needed performance. The IP ID field was then intentionally designed to be too small, 16-bit. If Snowden leaks documents on this, would for sure confirm this claim.

Remember that TCP/IP is a product of 1980s computer architecture and communication technologies. While it's true that a number of the key design decisions from that period are suited for very different problems than we face today (e.g., a real concern with global passive adversaries), they were also working with far more limited communications speeds, processor speeds, and memory sizes. Although I wasn't there myself, you have to suspect that some folk involved felt that 16 bits was far too much when prevailing communication speeds were <9,600bps.

More generally, though, the covert channel problem is actually a fundamental one to the design of computer systems, and in the territory of "we just don't know how to engineer solutions to this problem in a scalable way" still. Maybe another 10-20 years will fix that, especially with formal techniques becoming more viable. In the end, I think that does need to the approach due to weakest-link concerns in security. The good news is that formal methods are starting to become viable at scale, so there is real hope in that regard (I believe, anyway).

I think there is real, interesting, and immediate work to do in improving our IP ID implementation though, which will have substantial performance and functionality benefits, along with the side effect of reducing the impact of the covert channel you've raised, though. Hopefully that's something we can sort out in the next few months since it will help with contention issues such as the one raised.

Robert

> 
> OK, Robert, I fully understand and will not touch this issue any more before my head gets cut off :-) I appreciate your openness and willingness to share information on this issue. You know the IPv4 history even before I came to this world.
> 
> --HPS



More information about the freebsd-net mailing list