The case study that we describe next is based on our own recent experiences in working on IPSec, a set of secure protocols standardized by the Internet Engineering Task Force (IETF). IPSec is used for building virtual private networks to provide secure communications over untrusted networks. Today it is widely deployed in operating systems and networking hardware. Unfortunately, the IPSec standards are notoriously complex with many, many configuration options possible. In the Information Security Group (ISG) at Royal Holloway, we found attacks against the Linux kernel implementation of IPSec in a particular configuration, widely known as “encryption-only”. Our attacks showed this mode to be completely insecure in the Linux implementation. And these were not just “attacks on paper”: we wrote an attack client and demonstrated the attacks in the laboratory with a realistic network set-up and operating conditions.

Naturally, we then asked ourselves the questions: What is the real-world impact of our attacks, and how should we spread the news? Even answering the question of whether the encryption-only mode was in wide use or not was not simple. The IETF standards clearly advise against using it, and yet the same standards mandate that this mode be supported by implementations! We found several on-line configuration guides for IPSec that showed how to configure IPSec in encryption-only mode in a step-by-step manner. Industry contacts also suggested that this mode might well be in fairly widespread use. However, it was not even clear at that point (in early 2005) whether our attacks would work against other implementations.

Given our uncertainty about the true impact of our research, we felt that headline grabbing would have been easy but irresponsible. Our solution was to contact staff at the UK’s National Infrastructure Security Co-ordination Centre (NISCC) and invite them to Royal Holloway for a demonstration of our attacks and a discussion about the best way forward. That meeting took place in mid-April 2005. We immediately began work with NISCC's vulnerability team to write a vulnerability announcement; this was released by NISCC to the vendor and user communities in late April and generated enquiries from around a dozen companies, large and small. We worked with NISCC to assess the impact of our research for each of these companies on an individual basis.


Then, on May 9th 2005, NISCC made a High Severity Vulnerability Announcement about our IPSec work. This announcement was relayed by US-CERT, Aus-CERT, and other agencies, and picked up by the likes of zdnet, eweek, The Register, and cnet news. It then went on to generate plenty of speculation and conspiracy theory on slashdot and other on-line discussion sites. Also on May 9th, a research paper describing our attacks was circulated to selected researchers and submitted to a major international conference. A revised version of the research paper was later posted on the web; this improved version incorporated significant feedback from vendors, standards writers and the academic community.

From our perspective, working through NISCC gave us an improved understanding of the impact of our research. It also acted as a valuable relationship building exercise for us, both with NISCC and the Information Security industry. For vendors and users, our choice to work with NISCC ensured they had prior knowledge of the IPSec vulnerabilities before any public announcement was made, and gave them a head start in assessing the impact on their IPSec products and deployments.