OpenBSD Journal
Home : : Add Story : : Archives : : About : : Create Account : : Login :
OpenBSD IPv6 Security Audit
Contributed by merdely on Tue Sep 11 23:31:11 2007 (GMT)
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 info@ipv6samurais.com.

[topicnetworking]

<< New Ports of the Week #36 (September 2) | Reply | Flattened | Expanded | Theo de Raadt on Relicensing BSD Code >>

Threshold: Help

Related Links
more by merdely


  Re: OpenBSD IPv6 Security Audit (mod -7/31)
by Anonymous Coward (68.107.65.28) on Thu Sep 13 07:38:39 2007 (GMT)
  Seems to me that the best path would be to make it configurable, with a sensible default. We can always change it to something less sane if we see fit :-)
  [ Show thread ] [ Reply to this comment ] [ Mod Up ] [ Mod Down ]

  Re: OpenBSD IPv6 Security Audit (mod 0/38)
by jirib (2001:15c0:65ff:ff::2) on Thu Sep 13 09:52:51 2007 (GMT)
  not related to security but... what about to make more daemons in base ipv6 friendly? nfs, syslogd...

as there's some progress in samba development for ipv6, it would be nice to have openbsd as platform for core servers in only native ipv6 network :)
  [ Show thread ] [ Reply to this comment ] [ Mod Up ] [ Mod Down ]

[ Home | Add Story | Archives | Polls | About ]

Copyright © 2004-2008 Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to April 2nd 2004 as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. Some icons from slashdot.org used with permission from Kathleen. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. Search engine is ht://Dig. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]