Re: Re[2]: AH (without ESP) on a secure gateway

Stephen Kent <kent@bbn.com> Thu, 05 December 1996 04:23 UTC

Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA28071 for ipsec-outgoing; Wed, 4 Dec 1996 23:23:16 -0500 (EST)
X-Sender: kent@po1.bbn.com
Message-Id: <v0300780aaecbfc706a1d@[128.33.229.243]>
In-Reply-To: <199612041911.LAA02222@cornpuffs.cisco.com>
References: <v03007802aec93e33ca30@[128.33.229.245]> <9611028495.AA849549400@netx.nei.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 04 Dec 1996 23:18:46 -0500
To: Ran Atkinson <rja@cisco.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: Re[2]: AH (without ESP) on a secure gateway
Cc: ipsec@tis.com
Sender: owner-ipsec@ex.tis.com
Precedence: bulk

Ran,

	I'll comment on your suggestion that we retain mandatory use of
encryption in ESP.  I feel that AH is an awkward way to provide
authentication for a payload, due to the selective inclusion of IP header
fields.  The computation of the integrity check value will be slower than a
corresponding computation for ESP, because of the selectivity of the
computation.  AH does offer a different function from ESP, even if ESP is
offered in a version that provides integrity and autenticity without
encryption.  ESP, if allowed to be used without encryption, provides a
clean way to integrity protect just encapsulated data, if that is what is
wanted.  I suspect that this latter capability will often be appropriate, a
the recent firewall discussion has shown.

	I agree that the original distinction between AH and ESP was one in
which the encryption vs. integrity/authenticity was the primary motivation.
However, the other major difference is the scope of the protection, with AH
and ESP differing noticeably in that regard as well.  As ESP added more
features, I think it makes more sense to allow for it to be more modular,
and to reserve the use of AH for exactly the circumstances where it's
coverage of the IP header is appropriate.

	The notion of tunnel mode for AH has not been a very strong one in
the documents, though it certainly can be added.  However, I suggest we
consider the better documented tunnel mode notion of ESP, combined with the
new notion of an encryptionless use of ESP, as a candidate for many
instances where one might have used tunneled AH.  Unless the protection of
the "outer" IP header is necessary e.g., to bind a security label to the
outer packet, tunneled AH would appear to offer no advantages relative to
this mode of use of ESP.

Steve