Re: [Users] Making FreeS/WAN harder to use, INTENTIONALLY.

Hugh Daniel wrote in part:

> FreeS/WAN will add an extra default route making it impossible for
> machines behind your FreeS/WAN gateway to get out.

1) Thanks, Hugh, for clarifying this issue.  This is
the sort of thing that really needs to be discussed.

2) It was good to notify the "users" list of the
issue, but I suggest that the rest of the discussion
should take place on the design list, without CCing
users.

3) Some observations and questions:

This discussion exposes some confusion in my mind
(and probably others) about some fundamental OE design
issues.

Suppose we want the FreeS/WAN box ("East") to act as
a security gateway for the boxes behind it (on the
"Sunrise subnet").  And suppose I want to talk to one
of those boxes (call it "Riser") on that private subnet.

A) How am I supposed to address Riser?  In what namespace
do I look it up?  A couple of years ago we discussed
various ways to attack this problem using ephiphytes
and whatnot.  Did anything ever come of that?

B) When I do manage to look up Riser, what do I get for
an IP address?  This in general can't be the wild-side
address of Riser, because as likely as not Sunrise-net
is using private addresses.  A couple of years ago we
discussed extemporizing some ad-hoc private-side address
for Riser;  did anything ever come of that?

There are some parts of this problem that I think can
be solved using IPv6 (and not solved very well using
IPv4).

C) And how am I supposed to trust this connection?  How
do I know East is the proper security GW for Riser?
Because some sysadmin on East made some self-serving
assertions?  That doesn't sound very secure.

(Also that seems to violate the spirit of OE;  I
thought the point of OE was to permit connections
without lots of per-gateway admin work.)

In general there needs to be some nontrivial interaction
between East's security policy and _my_ security policy.
In the OE scheme of things, I need some reason to _trust_
the keys that I got from DNS or wherever.  Any old key
will suffice to set up a conn that carries traffic and
provides a modicum of privacy against amateurish passive
eavesdropping.  But I need more than that, I need a
trusted key, if the conn is going to resist simple
impersonations, not to mention more sophisticated attacks.

It seems to me some sort of PGP-like web of trust (or
x.509-like hierarchy of trust) is called for.  Of course
PGP and x.509 are clumsy and widely disliked, and come
with their own administration hassles.... If somebody
has a better way of dealing with the trust issues I'd
certainly like to hear about it.


D) This raises some questions about where the boundary
of the FreeS/WAN project should be.  It is one thing
to provide bare-bones functionality.  It is another
thing to provide an easy-to-use admin interface.  So
far it appears that most of the work has gone into
functionality.  But there will come -- or has come --
a point where usability issues start cutting into
security and/or start cutting into customer acceptance.

One could imagine having a "configurator" script that
asks a few _high level_ questions, allowing the customer
to select from a smallish number of standard solutions
to common problems.  The configurator then implements
the chosen high-level policy in terms of low-level
router, netfilter, IPsec, and DNSSEC functions.

If the project goal is to have IPsec be widely used,
such a configurator might significantly advance that
goal.  The advantages (from the customer's point of
view) of a configurator over an intricate multi-step
error-prone manual process should be obvious.

The downside (from the project management point of
view) is that the complexity of such a configurator
is comparable to a small compiler.  It will take a some
leadership and some commitment to make this happen.