Inline Keying within the ISAKMP Framework.
draft-ietf-ipsec-inline-isakmp-01

Document Type Expired Internet-Draft (ipsec WG)
Author Bill Sommerfeld 
Last updated 1997-03-26
Stream Internet Engineering Task Force (IETF)
Intended RFC status (None)
Formats
Expired & archived
pdf htmlized (tools) htmlized bibtex
Stream WG state WG Document
Document shepherd No shepherd assigned
IESG IESG state Expired
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft can be found at
https://www.ietf.org/archive/id/draft-ietf-ipsec-inline-isakmp-01.txt

Abstract

The current proposal for IP-layer key management [ISAKMP, OAKLEY, ISAOAK] has fairly high overhead. Before a security association can be established, at least one pair of messages need to be exchanged between the communicating peers. For efficiency, this suggests that ISAKMP setup should be infrequent. However, general principles of key management suggest that individual keys should be used as little as practical and changed as frequently as possible. Steve Bellovin has suggested that, ideally, different security associations should be used for each different transport-level connection[BADESP]. This document discusses a way of structuring a protocol to permit this to happen with minimal overhead, both in round-trip delay at connection setup, and in bandwidth once the connection is established. The general concept of inline or in-band keying here was inspired by SKIP[SKIP]. However, SKIP's approach is burdened by the addition of an extra intermediate header of perhaps 20 to 28 bytes to every protected packet, which doubles the bandwidth overhead of protected traffic compared with ESP with fixed keying. In order to minimise the per-packet overhead, an inline keying header

Authors

Bill Sommerfeld (sommerfeld@sun.com)

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)