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

Ran Atkinson <rja@cisco.com> Wed, 04 December 1996 19:25 UTC

Received: from cnri by ietf.org id aa22599; 4 Dec 96 14:25 EST
Received: from portal.ex.tis.com by CNRI.Reston.VA.US id aa17817; 4 Dec 96 14:25 EST
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA27384 for ipsec-outgoing; Wed, 4 Dec 1996 14:09:15 -0500 (EST)
Date: Wed, 04 Dec 1996 11:11:35 -0800
From: Ran Atkinson <rja@cisco.com>
Message-Id: <199612041911.LAA02222@cornpuffs.cisco.com>
To: ipsec@tis.com
Subject: Re: Re[2]: AH (without ESP) on a secure gateway
In-Reply-To: <v03007802aec93e33ca30@[128.33.229.245]>
References: <9611028495.AA849549400@netx.nei.com>
Organization: cisco Systems
Cc: rja@cisco.com
Sender: owner-ipsec@ex.tis.com
Precedence: bulk

	I believe that ESP should continue to always imply that encryption is
in use.  The presence/absence of encryption is the primary reason that AH is
separate from ESP.  Were it not for the political realities of regulation of
encryption in various locales, AH and ESP would not have been separate
protocols in the first place.  I am aware of cases where in practice more than
one government regulatory authority has been persuaded to handle AH export/use
licensing with significantly less hassle BECAUSE the AH spec does not support
encryption.

	I am aware that many implementers of AH have in fact implemented a
"tunnel-mode AH" (which looks like this: [ip:r1->r2][ah][ip:h1->h2][ulp],
where r1,r2 are security gateways and h1,h2 are end nodes).  I believe that
the best approach is to simply add a definition of this tunnel-mode AH into
the AH base specification.  This also has the virtue of having the least
amount of negative impact on interoperability of existing AH implementations.

Comments ?

Ran
rja@cisco.com