Contributed by merdely on from the cleaning-up-ipv6 dept.
Recently, Jun-ichiro itojun Hagino (itojun@) announced the KAME Project's OpenBSD IPv6 security audit on tech@. The issues outlined in the IPv6 Transition/Co-existence Security Considerations draft, posted to the IETF community, were addressed. According to Itojun:
Since I made the diagnosis from OpenBSD standpoint, there are a lot of problems that have already been avoided, for instance, because of the use of random numbers in protocol fields ("network randomness in OpenBSD"). If I think about other OSes there will be a lot more issues and problems. For instance, [Windows Vista] implements a lot of transition technologies which can bring in so much complexities and problems into the OS kernel (not the app!).
The only serious problem we have in OpenBSD is the abuse of hop-by-hop option headers. I'm trying to find the best avenue to combat this problem, both from implementation and specification point of view.
From the audit project's site explaining the issues Excessive Hop-by-Hop Options:
- It may be feasible to limit the number of hop-by-hop option headers on a single packet, maybe "at most 1", as the sender can put as many hop-by-hop options as needed into a single hop-by-hop option header. However, since it is permitted to put as many hop-by-hop option headers as needed in a single packet, some naive implementation may choose to put many hop-by-hop option headers as needed.
- We do not want to see an incident like rthdr0 again, of course, so we need some consensus on this, quickly.
- As for OpenBSD, we have upper limit for the number of total extension headers in a packet (net.inet6.ip6.hdrnestlimit, the default value is 10) but we do not enforce any limit on the number of simultaneous hop-by-hop option headers. Maybe we should.
Proposed diff (not really tested but should work fine, not spec conformant)
- For more discussion on this topic, check out draft-krishnan-ipv6-hopbyhop-01.txt too.
Itojun requests feedback from the networking and PF experts to email@example.com.
(Comments are closed)