Re: AH (without ESP) on a secure gateway

Bill Sommerfeld <sommerfeld@apollo.hp.com> Wed, 04 December 1996 19:03 UTC

Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA27368 for ipsec-outgoing; Wed, 4 Dec 1996 14:03:11 -0500 (EST)
Message-Id: <199612041904.OAA01378@thunk.orchard.medford.ma.us>
X-Authentication-Warning: thunk.orchard.medford.ma.us: sommerfeld owned process doing -bs
To: mckenney@mitre.org
Cc: Steven Bellovin <smb@research.att.com>, ipsec@tis.com
Subject: Re: AH (without ESP) on a secure gateway
In-Reply-To: mckenney's message of Wed, 04 Dec 1996 09:02:40 -0500. <v01510101aecae55b0c59@[128.29.140.130]>
Date: Wed, 04 Dec 1996 14:04:35 -0500
From: Bill Sommerfeld <sommerfeld@apollo.hp.com>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk

> This is more an implementation issue rather than a standards issue.  If you
> have an IPSEC-compliant firewall, then ESP Transport Mode could be used for
> firewall-to-firewall encryption.  Vendors should note in their
> documentation about possible problems and issues with this mode for
> firewall-to-firewall communications.  

There may be a terminology clash here.  By "firewall", do you mean
"filtering border router" or "application-layer gateway" or what?

I know I'm repeating myself (and others), but I think we've
(re)established over the past few days that performing transport-mode
ESP or AH encapsulation/decapsulation in a router is problematic.

If the end systems are also using ESP and AH, both the receiving end
system and the receiving router could allocate the same numeric SPI
and there wouldn't be an unambiguous interpretation of each packet.

This would impede deployment of end-to-end ESP/AH, and I think that's
reason enough to specify that configuration as a "SHOULD NOT" or "MUST
NOT"..'

					- Bill