Re: Protection of port 500

Francis Dupont <Francis.Dupont@enst-bretagne.fr> Tue, 16 January 2001 12:20 UTC

Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA23426; Tue, 16 Jan 2001 04:20:01 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA20984 Tue, 16 Jan 2001 05:46:52 -0500 (EST)
Message-Id: <200101161048.f0GAmlO97519@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: Dan McDonald <Dan.McDonald@Eng.Sun.COM>
cc: Matthew Franz <mfranz@cisco.com>, ipsec@lists.tislabs.com
Subject: Re: Protection of port 500
In-reply-to: Your message of Mon, 15 Jan 2001 23:06:23 PST. <200101160706.f0G76NA23868@kebe.Eng.Sun.COM>
Date: Tue, 16 Jan 2001 11:48:47 +0100
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk

 In your previous mail you wrote:

   > I'd want at least the option of some lower layer policy enforcement (ACLs,
   > filters, etc.) in additon to whatever the app layer provides.
   
   For such paranoia, a good implementation should allow that.  We allow
   node-wide policy to disallow even the root-restricted bypass privilege we
   normally allow.  We do not default to that, so that we can make our IKE
   daemon do per-socket bypass, as well as allow future versions of diagnostic
   tools (e.g. traceroute) to potentially bypass policy on a per-invocation
   basis.
   
=> FreeBSD 4.2 (and all BSDs with KAME based IPsec support) has a ping[6]
with a policy option. I have just tried with a remote site configured
with required ESP for everything and it works at you believe (ie. a ping
with no policy or the default output policy (out entrust) triggers IKE
exchanges and works after a small delay, the same with "out bypass" fails
because the peer rejects unprotected echo requests).
This is exactly what you have just described using your proposed API
(draft-mcdonald-simple-ipsec-api-01.txt) ideas...

Thanks

Francis.Dupont@enst-bretagne.fr