Re: AH (without ESP) on a secure gateway
Stephen Kent <kent@bbn.com> Mon, 02 December 1996 15:04 UTC
Received: from cnri by ietf.org id aa03404; 2 Dec 96 10:04 EST
Received: from portal.ex.tis.com by CNRI.Reston.VA.US id aa05360; 2 Dec 96 10:04 EST
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id GAA20881 for ipsec-outgoing; Mon, 2 Dec 1996 06:58:37 -0500 (EST)
X-Sender: kent@po1.bbn.com (Unverified)
Message-Id: <v03007803aec7e1cffbfb@[128.33.229.236]>
In-Reply-To: <199611271802.NAA29680@carp.morningstar.com>
References: <96Nov26.191251est.30786-1@janus.border.com> <9610258489.AA848977264@netx.nei.com> <199611261929.OAA01715@thunk.orchard.medford.ma.us> <199611262230.RAA27739@carp.morningstar.com> <96Nov26.191251est.30786-1@janus.border.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sun, 01 Dec 1996 20:46:43 -0500
To: ipsec@tis.com
From: Stephen Kent <kent@bbn.com>
Subject: Re: AH (without ESP) on a secure gateway
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Folks, A general problem arises with the use of AH at gateways. AH is nominally a "transport" mode security protocol, using the terminlogy adopted for ESP in the IPSEC context. In this mode, AH cannot be used unambiguously by a pair of firewalls, because it conflicts with possible use of AH by subscriber hosts served by these firewalls. Since the choice of SPIs is totrally within the purview of the receiving systems, the firewalls have no way to control which SPIs are selected by hosts served by them. So, irrespective of the other points argued by contributors to this debate, the fundamental problem here is the potential conflict between end systems and intermediate system use of the same header and SPIs. One can address this problem by tunneling between the firewalls, and using AH in the exterior IP header. There is a very, very brief note on such tunneling in the AH spec that Ran published a while ago. It is mostly a cautionary note aimed at other concerns, so it does not really alert the reader to this aspect of the problem. One also can achieve a similar (though not identical) capability by using ESP in tunnel mode, but NOT electing to perform encryption. Since ESP is being revised to be general enough to NOT requre encryption, this would address the export or import concerns cited earlier. Also, I agree with several of the observations about source address filtering. This too is an area where we need agreement of what a compliant implementation supports. I tend to favor a receiving host or gateways checking the source IP address against the (possibly singleton) set of addresses that are associated with the SA. As we define different granularities for selecting traffoc to map to a single SA selector, it seems appropriate to be able to verify that the received traffic is consistent with the definitions established during SA establishment. If this technlogy is widely used, it will not be appropriate to claim that any source with which one establishes an IPSEC-secured connection will be "trusted." They will merely be well identified in most cases. This has been a useful discussion threat and it points out the need to define required, and permitted, configurations for AH and ESP in hosts and security gatewayas, as well as other processing requirements for compliant implementations. I don't think we included this detail in the recent revisions of the RFCs that have been completed, so we will need to go back and add this. I look forward to a discussion of this topic of appropriate combinations of AH and ESP atunneling in San Jose. Steve
- AH (without ESP) on a secure gateway Whelan, Bill
- Re: AH (without ESP) on a secure gateway Michael Richardson
- Re: AH (without ESP) on a secure gateway Michael Richardson
- Re: AH (without ESP) on a secure gateway pau
- Re: AH (without ESP) on a secure gateway Stephen Kent
- Re[2]: AH (without ESP) on a secure gateway Whelan, Bill
- Re: AH (without ESP) on a secure gateway William Allen Simpson
- Re: AH (without ESP) on a secure gateway Michael Richardson
- Re: AH (without ESP) on a secure gateway David P. Kemp
- Re: Re[2]: AH (without ESP) on a secure gateway Ran Atkinson
- Re: AH (without ESP) on a secure gateway Michael Richardson
- Re: AH (without ESP) on a secure gateway Daniel Harkins
- Re: AH (without ESP) on a secure gateway Hilarie Orman
- Re[2]: AH (without ESP) on a secure gateway Whelan, Bill
- Re: Re[2]: AH (without ESP) on a secure gateway Bill Sommerfeld
- Re[4]: AH (without ESP) on a secure gateway Whelan, Bill
- Re: Re[4]: AH (without ESP) on a secure gateway Bill Sommerfeld
- Re[4]: AH (without ESP) on a secure gateway Karl Fox
- Re[5]: AH (without ESP) on a secure gateway Whelan, Bill
- Re: AH (without ESP) on a secure gateway Stephen Kent
- Re[2]: AH (without ESP) on a secure gateway Stephen Kent
- Re: AH (without ESP) on a secure gateway Stephen Kent
- Re[5]: AH (without ESP) on a secure gateway Stephen Kent
- Re: AH (without ESP) on a secure gateway Michael Richardson
- Re: Re[5]: AH (without ESP) on a secure gateway Bob Monsour
- Re: AH (without ESP) on a secure gateway Stephen Kent
- Re: Re[5]: AH (without ESP) on a secure gateway Stephen Kent
- Re: AH (without ESP) on a secure gateway Steven Bellovin
- Re[2]: AH (without ESP) on a secure gateway Whelan, Bill
- Re: AH (without ESP) on a secure gateway Brian McKenney
- Re: AH (without ESP) on a secure gateway Perry E. Metzger
- Re[2]: AH (without ESP) on a secure gateway Stephen Kent
- Re[2]: AH (without ESP) on a secure gateway Brian McKenney
- Re: AH (without ESP) on a secure gateway Ran Atkinson
- Re: Re[5]: AH (without ESP) on a secure gateway Ran Atkinson
- Re: AH (without ESP) on a secure gateway Bill Sommerfeld
- Re: Re[2]: AH (without ESP) on a secure gateway Uri Blumenthal
- Re: AH (without ESP) on a secure gateway Daniel Harkins
- Re: Re[2]: AH (without ESP) on a secure gateway Naganand Doraswamy
- Re: AH (without ESP) on a secure gateway Steven Bellovin
- Re: AH (without ESP) on a secure gateway Steven Bellovin
- Re: Re[2]: AH (without ESP) on a secure gateway Stephen Kent
- Re: Re[2]: AH (without ESP) on a secure gateway Dan Frommer