OpenBSD Journal

OpenBSD IPv6 Security Audit

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 info@ipv6samurais.com.

(Comments are closed)


  1. By Anonymous Coward () on

    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 :-)

  2. By jirib () on

    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 :)

    1. By Anonymous Coward () on

      > 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 :)

      i wish apache supports IPv6 by default. I know there's a patch that can enable apache to support IPv6, but I hate to do the patch everytime I update my server to -current. Anyone know why IPv6 patch for Apache 1.3 is not incorporated into cvs tree?

      1. By Ryan McBride () mcbride@openbsd.org on

        > Anyone know why IPv6 patch for Apache 1.3 is not incorporated into cvs tree?

        Because it breaks the Apache modules API.

    2. By itojun () itojun@itojun.org on http://ipv6samurais.com/

      > not related to security but... what about to make more daemons in base ipv6 friendly? nfs, syslogd...

      to update NFS to be IPv6-capable, we need to switch the entire RPC codebase. this is not something we can do at ease.
      for syslogd, yes, i can do that. thanks for raising this one.

Credits

Copyright © - 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 as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]