Re: AH (without ESP) on a secure gateway
Steven Bellovin <smb@research.att.com> Thu, 05 December 1996 02:24 UTC
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA28028 for ipsec-outgoing; Wed, 4 Dec 1996 21:24:50 -0500 (EST)
Message-Id: <199612050223.VAA02436@raptor.research.att.com>
To: Michael Richardson <mcr@sandelman.ottawa.on.ca>
cc: ipsec@tis.com
Subject: Re: AH (without ESP) on a secure gateway
Date: Wed, 04 Dec 1996 21:23:56 -0500
From: Steven Bellovin <smb@research.att.com>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
[this may be a repeat. Emacs crashed.] -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Steven" == Steven Bellovin <smb@research.att.com> writes: Steven> mode. To do otherwise is inviting trouble. In fact, I Steven> had thought that was what was done -- no other possibility Steven> had occurred to me. Are you suggesting we need specific wording in the drafts? If people are trying to do AH at the firewall, without an intervening IP header -- yes, we should prohibit that. Steven> There's a second issue that has come up here -- how does Steven> one know which the right firewall is? This is one of the I favour a firewall discovery system. ICMP Admin denied messages can provide the right info. I am not certain if this is workable, since I haven't been able to prototype it all. (And no longer have the funding to even try.) We need some mechanism -- but I'm not convinced I know the right answer. Certainly, firewall discovery is part of it, but we also need some sort of authentication mechanism, so that you know you've heard from a legitimate firewall. Steven> points I raised at the last IETF meeting; in my opinion, Steven> it's very closely related to the naming issue and the Steven> certificate issue, and we haven't really tackled either of I am retrieving your slides. [how do you get the AT&T logo inside of slidex? Cool.] The problem I see is that there may be different firewalls involved. Both firewalls in parallel and firewalls in series. While this doesn't sound very likely very soon with most current application layer firewalls, Checkpoint has announced state-sharing facilities. It could be a different firewall that is involved each time! Should the encryption state be shared too? Maybe. Maybe not. Firewalls in series are more interesting. I expect to see this. I am seeing this. [I use latex for my slides, and once upon a time, someone wrote a Metafont definition for the Death Star logo. So to latex, it's just another character.] We certainly will see many combinations of firewalls. That's part of the fun... The best system I can imagine is one where an end node is provided with a certificate, signed by its intended destination stating that "firewall X is a legitimate firewall for me". The local node will also need to be able to recognize a certificate from a local authority saying "firewall Y is a legitimate firewall to get to 0.0.0.0/0" Something like that, though wildcard DNS-like records might be needed as well. (local node)-------- Y --------- X ------- (end node) The SPKI groups' proposal has the notion of cache certificate that could reduce a series of statements into single self-signed certificat e. All of these are reasonable ideas. Now we need concrete proposals and implementations....
- 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