Security Architecture for the Internet Protocol

Course: CS125
Name: Daniel Meredith
Commentary Due Date: 02-02-00
Submit Date: 02-02-00
Journal Ref: IETF RFC1825 & IETF RFC1828

As the internet grows the need for security on a protocol level increases. The practice of encrypting a message (email, etc) is really to only way to protect the data contained in a packet. The road map laid out in RFC 1825 will insure that the the next version of IP will include some form of internal security. RFC 1828 is simply an extension of that document and defines the algorithm that will be used, along with highlighting some areas that could be problems in the implementation.

Currently in IPv4 data transmission is sent un-encrypted and insecure on the IP protocol level. There are methods to encrypt data before transmission (PGP, etc) and protocols to insure a secure connection with a host before transmission (SSL, PCT, TLS) but IP does nothing to insure the security of its payload. With the upcoming release of IPv6 that will all change. The specifications laid out in the security architecture road map insist that every network using IPv6 to implement encryption security at the IP level.

Security starts at the head of the packet. The use of two main headers: IP Authentication Header (AH) and IP Encapsulating Security Payload (ESP). The main draw back to AH is that it does not provide confidentiality to the IP datagram of a packet. This is a security fault, but it will allow this header type to be widely used on the internet, including regions with restrictions placed on the import or export of strong encryption techniques.

The most likely use of AH is between trusted networks. For example a company with multiple sites around the world would like to securely network all of these sites. Instead of implementing AH at every host, it would be simpler to setup security gateways between all the sites and only encrypt the outgoing traffic. This saves resources behind the gateway and protect the inter-network traffic. AH has been designed to work from host to host, gateway to gateway, host to gateway and vice verse. Thus it is a very flexible security protocol.

ESP is another header type that could be used. It is also designed to work from gateway to gateway, but there is also the built-in feature of variable security levels. When an ESP gateway receives a packet bound for a trusted host, it takes the security level of that host into consideration when deciding what level of security to use on that particular packet of data. ESP does have the ability to allow simple host to host communication by only encrypting the user data (TCP or UDP).

One of the keys to both AH and ESP is the concept of Security Association. This simply means that a set of security protocols must be followed before a machine to machine connection is considered secure. Which include:

the use of Authentication Header
the use of certain key types with AH
Encryption algorithm, algorithm mode and transforms must be used with ESP
certain key types must be used with ESP
limited lifetime of the encryption keys or a time for a key change
limited lifetime of the Security Association

As the document continues defining the specifics of the security features of IPv6 and the allowances they have made for the future of secure internet transmissions it is made quite clear that "the primary objective of the RFC is to insure that IPv4 and IPv6 will have solid cryptographic security mechanisms available to users who desire security." (page 6) It would seem that the RFC is meant to lay a foundation on which security can be based, but I feel it is much more likely that it is setting a minimum standard by which private IP implementations will have to adhere. This would seem to be setting a "low bar" for the security of the internet. The guidelines laid out for IPv6 and the security entailed seem to be very tough for 1995 when it was written. But in a time where the processing power of a machine is great enough to encrypt every packet it sends out, how far are we from machines that can break that encryption in real time?

The performance aspect of the security architecture is another point which is hardly covered in the RFC. The authors admit that the increase in security will reduce network performance on the the local machine. The new protocols will not reduce the performance of intermediate routers and switches as much, but there will be an overall increase in latency on the internet. They even go so far as to suggest a hardware implementation of the encryption algorithms in order to minimize the performance hit to the local machine. At the time of writing (1996) the average machine was about 90 MHz. Today with the clock speeds of the newer machines pushing the 1 GHz limit the clock cycle to encrypt each packet are a non-factor in the everyday use of the protocols.

The presentation of the architecture was fairly dry, but this is too be expected in a technical document. The RFC format is very standardized and therefore the paper was easy to navigate and follow. One thing I did notice about this document compared to other RFC, is the inclusion of example real world implementations.

Basically this means that there is no reason not to implement the full security on any machine where security is a concern. The increased security is not only a small blessing to corporations or governments worried about inter-network traffic, but it is a god send to the new e-business movement on the internet. IPsec and IPv6 will allow truly secure connections to e-commerce sites. This new security may be able to convince those worried about the safety of their credit card numbers and other information to begin shopping on the internet. The influx of capital could be quite large, if the public was informed of the new "safer" internet. I could even imagine sites advertising their IPsec compliance to attract paranoid e-shoppers.