IPv6 readyNote: This archive passes through spamassassin. Every mail marked with the subject "*****SPAM*****" has exceed a certain threshold of spam-like behaviour.

[Users] Re: OE bootstrapping

From: Karl O . Pinc (kop_at_meme.com)
Date: Thu Jun 13 2002 - 19:58:16 CEST


On 2002.06.12 21:46 Sam Sgro wrote:
> -----BEGIN PGP SIGNED MESSAGE-----

> lists.freeswan.org Email Summary for Tuesday, June
> 11th,2002
> ==============================================================================
> by Sam Sgro
> sam_at_freeswan.org

>
> 4. OE and bootstrapping DNS
> ========================
> 7 posts, June 9-11
> http://lists.freeswan.org/pipermail/design/2002-June/002737.html
> http://lists.freeswan.org/pipermail/design/2002-June/002781.html
>
>
> When authenticating an IPSec connection using RSA keys, FreeS/WAN only
> needs to know one public key: that of its peer. It does not need to know
> its own public key.
>
> However, for opportunistic encryption, both public keys are currently
> fetched by default from DNS, as Pluto has no way yet of distinguishing
> which
> side of the connection is ours. The lookup happens when an OE connection
> is
> added - even when no host has tried to connect to the FreeS/WAN box,
> using
> that connection - and results in a useless DNS (self) query.
>
> Why is this important? We consider IPsec a critical network component,
> that
> should be started before the network itself is inititated. Thus, that
> initial, useless DNS query that cannot succeed could prompt a failure as
> we start IPSec.
>
> We need some mechanism to prevent this lookup. DHR suggested:
>
> - we could easily add "%none" for *rsasigkey to suppress loading the
> key. This is necessary because specifying leftrsasigkey="" has the
> same effect as saying "use the default". If the default is %dns,
> then this cannot be overridden by a null operand.
>
> - we could easily add a rule that says: don't load the key if the
> other side has %any or %opportunistic. This rule would probably
> only overried %dns; any other *rsasigkey would stand.
>
> We're definitely looking for some additional suggestion on how we might
> best prevent this query from compromising IPSec.

I'm a know-nothing here, but... Has _not_ suppressing the initial lookup
been considered. You could have what amounts to an /etc/hosts file that's
examined before dns is done. If the local public key is stored in a
standard
location, it might even just look right at this file.

Karl <kop_at_meme.com>

_______________________________________________
Users mailing list
Users_at_lists.freeswan.org
http://lists.freeswan.org/mailman/listinfo/users



This archive was generated by hypermail 2.1.3 : Mon Jul 29 2002 - 05:20:14 CEST