Are you just auditing the implementation or searching for possible problems included in the specifications too? RH0 comes to my mind...

Yes, I was looking for problems both in implementations and specifications.

The project was a bit too easy because I've focused (only on the) OpenBSD implementation. I have been careful not to incorporate code based on insecure (or) pointless specifications. OpenBSD IPv6 integration has been following OpenBSD IPv4 practices, such as the use of pseudo-random number in packet fragment ID fields, Therefore, it is less likely to find implementation issues in OpenBSD than other operating systems!

There have been some bugs in OpenBSD IPv6 stack. Do you think this happened because IPv6 is more complicated to implement?

No. The sole reason is that there are too few number of eyes watching over it.

The second OpenBSD remote hole in these 10+ years was in IPv6, but it was not because of IPv6 -- this was in the mbuf manipulation within IPv6 code path. The code was modified with less care than needed, when we switched the way of mbuf tagging, if I remember correctly.

RH0 was a serious issue, however. It is a specification bug, which we have been checking with the spec authors thousands of times before implementing it. The trap was that the spec authors were not security-minded people.

I would like to see more people look at the gory details and try to audit (and) catch any mistakes we might have. A good starting point is the book "IPv6 core protocol implementation" which is basically "TCP/IP illustrated volume II" for BSD IPv6 code base.

Is your project still under work, or already completed?

The audit project itself is basically finished, but I intend to do the same thing for popular code bases like Darwin if my time allows.

Will the results be part of OpenBSD 4.2 or 4.3?

I've sent the email to all of the OpenBSD developers to know how they feel about it. The only significant issue -- both implementation and spec -- is about excessive use of hop-by-hop option headers. Since the fix will make OpenBSD spec non-conformant, we have to be a bit careful not to break other people's communications, as OpenBSD boxes tend to be used as an IPv6 router which throws packets around between IPv6 machines. I guess the suggested -- spec non-conformant -- (fix) will miss 4.2, but I will push it to 4.3 as well as IETF documents.

Please tell us more about this proposed fix.

From the current specification, there seem to be possibilities for malicious parties to abuse a large number of hop-by-hop headers (the header examined by every intermediate routers) on a single packet, so that CPU load of those routers will increase, and maybe they can be panicked in the worst case (denial-of-service).

OpenBSD boxes do not have distinction of slow path (CPU forwarding) and fast path (silicon chip forwarding). But for commercial routers which reduce their costs by using cheap CPU and expensive silicon, it would be a big problem.

The proposed diff (change) will change the behavior of nodes -- both hosts and routers -- so that they will drop any packets with more than 1 hop-by-hop headers. For the packet originators, there is no real reason to attach more than one hop-by-hop header, as the originators can include as many hop-by-hop option data items into a single hop-by-hop header. If anyone sees a packet with more than 1 hop-by-hop headers, it would be an attack, or it may be because the source node implementation was too lazy that they simplified the behavior by not implementing hop-by-hop options packing.