2.9 Secure Internet Protocol (IPsec)
Rather than putting extra load on client applications to diligently authenticate and validate the integrity of data they receive, a more appropriate technique may be to place all of the security and data integrity related functionality down into the network, or Internet Protocol (IP), layer.
The inherent problem at the moment is that the existing Internet Protocol (IPv4) was never designed with security in mind; IP is principally there to route datagrams over a network on a best effort basis, with the transport layer (TCP) ensuring reliable, but not secure, delivery.
An emerging protocol that attempts to correct this weakness and thus offer truly transparent IP delivery (in that higher-layers need not worry about data integrity) is Secure-IP, or IPsec.
The purpose of IPsec is to provide a standard mechanism for protecting all traffic on a network transparently, irrespective of the application. It can protect all traffic against unauthorized modification and eavesdropping and securely authenticate the parties that are communicating with each other. It renders most of the commonly used security attack methods ineffective. IPsec is a means by which secure VPNs can be offered over public network backbones.
However, IPsec is very much a retrospective “bolt-on” to the existing IP. This will change in the near future because IPv6, the next generation IP, has IPsec in its core specification. That is to say that all IPv6 capable devices must fully support the IPsec suite of protocols for authentication and encryption.
At the present time, it is not clear how readily IPsec as is could be deployed over JANET. It may be that JANET will have to wait until IPv6 comes to fruition. Whilst the core protocol specifications are well along the standards track, it is unlikely that IPv6 will be deployed commercially for several years yet.
Production IPv6 networks exist (notably the 6REN and WIDE projects) and production IPv6 stacks exist for the more popular operating systems and network hardware. However, there is currently little activity in the UK as most people are waiting for deployment success stories to be published before taking the risk of migrating to IPv6. At the time of writing, only the University of Southampton (the authors of this report) and Lancaster University are early adopters of IPv6 within JANET, and only Southampton have native IPv6 WAN links in use (to UUNET UK). The establishment of the European-led IPv6 Forum, which within a month of its launch already has 50 companies signed up to it, is a positive sign for future IPv6 growth.
2.10 Areas under Study by the IETF
The Internet Engineering Task Force (IETF) is the main body promoting new Internet standards (RFCs, or Requests for Comments). They have a number of Working Groups that drive forward activities in various areas. To appreciate the current hot topics in security, a good place to look is the list of IETF Security-related Working Groups:
An Open Specification for Pretty Good Privacy (openpgp)
Authenticated Firewall Traversal (aft)
Common Authentication Technology (cat)
Domain Name System Security (dnssec)
IP Security Protocol (ipsec)
Intrusion Detection Exchange Format (idwg)
One Time Password Authentication (otp)
Public-Key Infrastructure (X.509) (pkix)
S/MIME Mail Security (smime)
Secure Shell (secsh)
Simple Public Key Infrastructure (spki)
Transport Layer Security (tls)
Web Transaction Security (wts)
Which Groups are of relevance to this overview? In short, all of them, but there are two worth mentioning in particular. One is the Public-Key Infrastructure (X.509) Working Group (one chair of which is from Verisign). They promote X.509v3: “Many Internet protocols and applications which use the Internet employ public-key technology for security purposes and require a public-key infrastructure (PKI) to securely manage public keys for widely-distributed users or systems. The X.509 standard constitutes a widely-accepted basis for such an infrastructure, defining data formats and procedures related to distribution of public keys via certificates digitally signed by certification authorities (CAs).”
The other is the Transport Layer Security (TLS) Group. TLS was designed to supercede SSL3.0, and Version 1.0 made full RFC status in 1999. According to this RFC, the goals of the TLS Protocol include cryptographic security, interoperability (”independent programmers should be able to develop applications utilizing TLS that will then be able to successfully exchange cryptographic parameters without knowledge of one another’s code”) and extensibility (”TLS seeks to provide a framework into which new public key and bulk encryption methods can be incorporated as necessary”). TLS is currently public key oriented, and thus a set of Kerberos Cipher Suites is also being planned.
The IETF will continue to deliver solutions for security problems on the Internet through RFCs. It is very important to track their activities, and in-house solutions that ignore the IETF Draft and final RFCs risk becoming isolated. The development of the TLS is a good sign for interoperability, with at least one open source implementation (OpenSSL) already available.