Hagino was a core researcher at KAME Project, which wrote and now manages a freely distributable set of code for Internet Protocol Version 6 (IPv6) and IPSec technology used by the Unix-like operating systems FreeBSD, NetBSD and OpenBSD as well as by many companies in their next-generation networking products. During September and the beginning of October, SecurityFocus contributor Federico Biancuzzi interviewed Hagino by e-mail about IPv6 and his most recent project, the OpenBSD IPv6 Security Audit.

Sadly, Hagino's life was cut short; he died on October 29, 2007. He was only 37.

During his life, Hagino served as Internet Architecture Board member and served on the board of the Widely Integrated Distributed Environments (WIDE) project since March 2004. He had been hacking computers since his junior high school days and defined himself a "free software activist."

If you are using IPv6, you are probably running some of his code.

SecurityFocus: Could you introduce yourself?

Jun-ichiro "Itojun" Hagino: My name is Jun-ichiro Itojun Hagino. Just call me "Itojun". I'm a seasoned BSD developer, I guess I'm the only person who have commit rights to four out of six BSD projects -- OpenBSD, NetBSD, FreeBSD and Darwin. The rest are PC-BSD and DragonflyBSD. I have been implementing various free software since 20 years ago, for MS-DOS as well as UNIX. One of my major achievements is nvi-m17n, which is multilingual nvi -- it can operate on multilingual text just like recent GNU emacs.

(For) 10+ years I have been devoting my professional -- and some of my personal -- life to IPv6 as well as IPSec. I served as an Internet Architecture Board (IAB) member, the technical steering committee of the Internet Engineering Task Force (IETF) in (the) 2003 (to) 2005 timeframe.

I'm a technology fundamentalist. I have never configured (a) NAT box (a router implementing network address translation, or NAT) myself, since doing so I would damage my belief to IPv6. I have never operated Microsoft stuffs -- other than using a browser in (a) net cafe -- since they ... introduced long file names. I do use MacOS X as I can say that it is a BSD variant, and it has our IPv6 code in it. :-)

But anyways, I'm just another super geek from Tokyo, who loves manga, anime and sci-fi.

How did the OpenBSD IPv6 Security Audit project start?

The project is to audit IPv6 implementations and also standards, to proactively combat against security problems we might have in IPv6 implementations as well as specifications.

At the beginning, it actually was a proposal for government funding. However, the funding body turned the proposal down because I was too popular already and the funding was for newcomers. But I felt the urge to do it, so I've decided to start and finish it on my own. So it was not funded by anyone.

It took me around (a) month or so to go through the Internet draft which talks about various security issues in IPv6 specifications and implementations. Basically I cheated, because some part of the draft was based on my writing.

What link does the project have with the KAME tree?

KAME is the project which is responsible for IPv6 code in every single BSD-ish project, including Apple Mac OS X and Juniper JunOS. KAME code was integrated into OpenBSD and other BSDs (during the) 1999 to 2000 timeframe.

The audit was based on OpenBSD integration. There are differences between IPv6 integration among BSDs, because their technical needs, project focuses, and other random things. For example, OpenBSD does not integrate 6to4 (RFC3056) automatic tunneling mechanism, which is stf(4) in other BSDs. This is because OpenBSD cares about security, and I knew that there are serious problem in 6to4 specification just like those presented in RFC3964. Anyways, the audit based on OpenBSD IPv6 code will be beneficial to the KAME project too.

I have started a new effort, which is basically to continue KAME project effort -- KAME funding was cut in spring 2006 so I'm filling the void. So the auditing effort was under ipv6samurais.com umbrella. (Editor's note: The IPv6 Samurais site continues to be maintained by its two other members, Mark Uemura and Marc Blanchet.)

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.

What problems do you see in the excessive use of hop-by-hop option headers?

Hop-by-hop options are likely to be inspected by slow path (CPU forwarding) in the routers. Commercial routers use cheap CPU and expensive silicon to make it economical. So any increase in CPU load could result in denial-of- service attack, by chewing up CPU power and affecting other computations such as routing information exchanges.

Various RFC drafts try to improve or fix IPv6 security. Should we create something from scratch instead. Some countries, such as Japan for example, are working on "replacements" for the Internet...

The project mentioned on the above link is, honestly speaking, just another set of people from ivory towers, and/or telcos, who are trying to get government funding. The government (would do) better to fund OpenBSD instead :-)

There is no point in re-doing the whole thing when we are reaching the end of IPv4 allocation worldwide, which is predicted to be year 2010 or so. We have to convince Microsoft people to ship Windows Vista with IPv6 enabled by default, so there's no point in turning back. We just need more education, training, and documents to propagate IPv6 knowledge. Also, we need more amazing applications which use IPv6.

Do we really need IPv6 then?

Of course. I am performing ssh-over-IPv6 login to my mail server as I am writing this. My home wireless network is IPv6-only, since I do not have enough IP address to spare, unlike North America.

Both the U.S. Department of Defense and the White House's Office of Management and Budget have mandated that the military services and federal agencies move their backbone systems to IPv6 by June 30, 2008. What approach would you suggest to support IPv6?

If you are a vendor, you have to implement IPv6 as soon as possible. There are numerous consultants who can help your company to integrate IPv6 into your product. If your product is based on free software such as BSD and Linux, it is just a matter of configuration. If not, it may be a bit difficult to implement IPv6 from scratch -- again, go through Qing Li's "IPv6 core protocol implementation" book and see if you want to implement it for sure, and see if you can implement it in a timely manner so that you can compete with other vendors.

Government/military people has been saying that they require IPv6 for the procurement decisions. In Japan it has been enforced more than 5 years, if my memory serves. There are government documents which guides government departments/offices to become IPv6-ready (IPv4/v6 dual stack). It is amazing those people are prepared for the coming days.

However, I think we need to bring IPv6 to more attention to people by having more materials for education and training. For instance, the amount of CISCO CCNA IPv6 text books should become equal to IPv4.

Operation of IPv6 will be dual-stack (IPv4 and IPv6) for a long time, since the deployed IPv4 codebase is too huge. We can never have a flag day. It is just like having IP phones and PSTN (ground line) phones -- they use different technologies, but the sole goal is for people to make voice conversations. The difference between IPv4 or IPv6 matters for some engineers, but not for random people who have no idea what "192.168.1.1" means.

An important point here is that, engineers will be able to make more innovative services with IPv6. More innovation is made possible by IPv6, since we can have more time to spend on the key technology rather than circumventing troubles with NAT and private address. To achieve this, at the same time, security technologies such as OpenBSD "secure-by-default" approach becomes highly important, since, with firewalls, we cannot really deploy new stuffs. And, if you look at firewall situation without pair of glasses, (1) you have host firewall and network/organization firewalls which are duplicates (2) you have to update virus signature database because your OS is vulnerable from the start. OpenBSD have neither of the problems.

Does IPv6 make censorship efforts like China's big firewall more complicated?

I guess so, but you will want to use SSH, IPsec and whatever technologies that are truly secure to make sure. I have visited China in July and I was so surprised that all of the stuffs written down on Wikipedia are true -- all http traffic are sucked by squid and access controlled (maybe logged). I wonder how big is the squid box.

And what about firewalls and NIDS?

Yes, for those devices it will be very difficult. My take is that we should secure hosts rather than network borders. These days, we have a lot of laptops coming in and out of organization networks, and means to connect to organization internal from outside like IPsec VPN. So virus infection does not come from the outside network, they will be from the internal by virus-infected laptop carried by your boss.

Fragmentation and reassembly in IPv4 has been used to build attacks against TCP/IP stacks and bypass NIDS inspection, how is it going to change with IPv6?

No changes. They are equally difficult for NIDS.

How do you suggest auditing an IPv6 stack?

Not sure about what other OpenBSD project members are using, but for me, the greatest tools are grep(1), awk(1), perl(1) and vi(1). There are certain patterns in vulnerable code, such as the use of sprintf(3) instead of snprintf(3). Also the point to look at is pointer manipulations, structure/union definitions, critical sections such as splx(9) or splnet(9). Also, both from efficiency and security reasons, the cost of operations such as O(n^2) or O(n log n) is important, as more computation cost is equal to more possibility for denial-of-service vulnerabilities. Boundary conditions, such as when variable is 8 bits and the value is either 255 or 0, is also important. There is higher likelihood for overflow (or) underflow.

Open-source or closed-source, well, I have been trying very hard to spend more time on open-source projects so I'm not too sure. The principle should be the same. With closed-source you just have fewer eyes to look for holes, that's all.

Today the world is switching from "knowledge domination" to "knowledge sharing" -- see all activities coming out from blog and YouTube. If you open up some of (or all of) your ideas, more people will get interested and we all can have some very good outcome. In computer industry, BSD, Linux, Apache, Mozilla, and other free software projects have already made it very clear.