The following text is copyright 1995 by Network World, permission is hearby given for reproduction, as long as attribution is given and this notice is included.
The value of sure and obscure packets.
By: Scott Bradner
Two weeks ago Patrick Bird wrote an article for this paper about the use of packet-level encryption (*Packet encryption may bury security concerns* - nw Nov. 27 pp45) but did not happen to mention the work of the Internet Engineering Task Force (IETF) in this area.
In August the IETF published five security related Proposed Standards (the first step in the IETF standards process) as RFCs. These documents are products of the IP Security Working Group in the IETF. They provide an overview of a security architecture for the Internet Protocol (RFC-1825), and descriptions of a packet authentication extension to IP (RFC-1826), a specific authentication mechanism (RFC-1828), a packet encryption extension to IP (RFC-1827), and a specific encryption mechanism (RFC-1829). Support for these security features is mandatory in implementations of the next generation of IP (IPv6) which claims to be standards-compliant. They are optional for the current version of IP (IPv4) in use on the Internet and in private IP networks.
Authentication is used to ensure that the receiver of information transferred across a network knows that the origin of the information has not been forged and that the information itself has not been modified during its travels. There are many applications in which confidentiality is not required, yet it is quite important to be able to verify that the data is legitimate. An example of this is the routing updates within the Internet. The information being carried (the location of individual networks attached to the Internet) is not secret but it could be quite disruptive if someone were to deliberately insert false information.
At other times the information itself should be kept hidden for example, when transferring credit card numbers from a buyer to a merchant. The encryption extension is used in these cases.
Some people would claim that performing these types of security functions at the packet level is wrong since application level security is far more efficient than packet level. It is clearly better in terms of the amount of data transferred if an application can support authentication and/or encryption on its own, but the presence of packet level security permits the use of security-ignorant applications in a secure way.
One area that requires additional effort is key management. In order to use security of any kind both ends of an electronic conversation must agree on the security methods and the encryption keys to use for a particular interaction. Frequently the key exchange is the weak link in the security system. The IETF IP Security Working Group is currently working on key exchange systems and expects to propose one quite soon.
The IETF security functions can be done using separate external devices, as in Patrick's description, by the network filewalls increasingly used by corporations when connecting to the Internet, or by using software installed on the end systems themselves.
A number of prototype implementations are running now and IETF security features should be soon available in commercial products.
The widespread availability of the ability to support authenticated and confidential exchanges over private data networks and over the Internet is critical to the future growth of electronic commerce. Packet level security will be a key enabler in this area.
RFCs can be retrieved by using anonymous ftp from ds.internic.net in the directory rfc. The filename for RFC-1825 would be "rfc1825.txt". A URL for the RFCs is http://www.internic.net/ds/dspg1intdoc.html
Disclaimer: While many of the people at Harvard are quite sure of themselves, they are not so sure about others, so authentication could be useful, but these are my own opinions.