Making FreeS/WAN harder to use, INTENTIONALLY.

-----BEGIN PGP SIGNED MESSAGE-----

  Thought that Subject line would get your attention, now happily into
the fray!


  We are literally right on the cusp of letting FreeS/WAN 2.00 out the
door, and now there is a debate over the basic functionality of
automatic OE (Opportunistic Encryption) in 2.00.

  Here are the two things you need to know for the debate, first is
that 2.00 ships with OE enabled by default, such that once it is
installed and running on your HOST it will try to do OE (depending on
the environment, RTFM).  In the future it will try even harder (what
we call "dogged determinism") to make sure you ALWAYS have OE if at
all possible.

  The second thing you need to know is that once 2.00 is run it will,
by default, block all communication to hosts 'behind' your gateway
machine...  UNLESS you configure it expressly otherwise.


  Here is a bit of the debate:

Says: [email protected]
"""
I just installed 2.0 (rc2) today and ran into an unexpected problem.
In 2.0, opportunistic encryption is enabled by default.  It's part of
the new Policy Groups feature.  As a result, FreeS/WAN will add an
extra default route making it impossible for machines behind your
FreeS/WAN gateway to get out.
"""

Says: Sam Sgro <[email protected]>
"""
Most of our users will have to shut off policygroups, as they can't even leave
it on innocuously... and we've specifically made it difficult to turn off to 
spite them.

This release should stay in Development until we get it right in 2.01, because 
is quite, quite wrong.
"""


  Now the questions before us is what to do about the upcoming 2.00
release and what is right in general.

  In the short term (2.00) there is a simple argument for the current
behavior, if your just a HOST then arguably 2.00 does the right thing,
it tries to run OE.  If your NOT a host, then your a GATEWAY, if your
a gateway with IPsec on it then your really trying to be a SECURITY
GATEWAY (SG) of some form (even if it's just securing access to the
SG.

  If your setting up an SG then you dam well have better looked
closely at your routing tables (ALL of them, and there are (sadly) a
LOT of them in the Linux networking mess) and made sure that only
exactly what you want gets though your SG in the way you want.

  (If you have _not_ done the above SG "due diligence" then you might
as well just stay off the net.  Seriously.  I don't want you
complaining that you don't like MY packets because of YOUR poor setup
and then trying to make 'laws' against me to protect you because your
a wimp.  It's a tough but free net out there.  Live with it not
against it.)

  In this case of setting up a SG we have created something along the
lines of the IP forwarding flag in RedHat's (poorly named)
/etc/sysctl.conf file, except that ours _is_ harder change to make in
that its more then a one word change.  This is the "policy groups"
files that consists of CIDR (dotted quad or if you can make your DNS
work at the right times DNS names).

  On the flip side I will argue that unlike the stupid sysctl.conf
file IP forwarding 'bit', our config is at lest CLEAR as to what it
means (hey, in the current phoebe they added a comment that almost
makes it clear!) in that it really does take many words to turn off OE
or just a few words (CIDR in a policy file) to make a subnet 'secure'.

  So now the question is, assuming that the current behavior is
reasonable, is the way to setup a SG clearly documented such that
folks _can_ setup a SG quickly?  Are we shipping a
example-SG-ipsec.conf file?  Do we tell folks at the right time (early
in the doc) which fork they are going to have to go down?


  The second question is in the long run, what is the _correct_ thing
to for OE vs. subnetworking configurations?  If the single bit that
sysctl.conf set is supposed to control subnetworking (IP forwarding)
then how can it ever be secured?  All someone has to do is flip that
single bit and 95% of the sysadmins out there will NOT notice that
packets are flowing to their subnets with out being considered by say
the eroute table.

  I think the teams explicit "Policy Group" design can handle this
situation more cleanly then the one bit policy of the current Linux
networking code.  Current policy groups are just for this host, it was
planed to rename the policies directory to host-policies such that it
would be clear that THAT set of policies was just for packets headed
to/from that host.

  If you have a subnet then you need a set of policies for this
subnet, something like "/etc/ipsec.d/net-10.0.0.0-policices/" or maybe
"/etc/ipsec.d/net-bldg10.example.com-polices" or what EVER name you
set in the /etc/ipsec.conf file.

  Another argument is that HOST policies should _only_ affect that
HOST (or even better, that host even if it's a virtual host).  This is
not really possible for FreeS/WAN built on the current Linux
networking base that it is built on, which stems from the days of
linux-2.0.3x something.  The plan is for FreeS/WAN 3.xx (already being
worked on!) to use the current Linux networking base, which is somewhat
improved and we should have no problems picking out just the host we
want etc.

  This 'other argument' then lets you set up OE on a host that is a
gateway and NOT secure 'flow through' (forwarded) IP traffic, not even
have to think about it.  Is that really the result we want?  It should
be trivial to do in FreeS/WAN 3.xx, but then the question is what _is_
the right way to setup subnetworking?

  The choices seem simple, "forward by flag" (the 'old' way) or
"forward by CIDR" (say FreeS/WAN Policy Groups), but are not.  Even
the current Linux networking code now has a "forward by flag" for not
just the whole system but each device, and no real good sysadmin
interfaces to it (there is a bit in Phoebe3 for IPv6...).

  I will state that in the long run security by device flag CAN NOT BE
SECURE, it's just to easy to setup say a laptop to bridge/route
between two devices, then quite reasonably move one of the devices and
now be sending packets in the clear on untrusted networks.

  It's all about crypto hygiene.  If you want to have a bright privacy
smile you you gotta brush your policy group teeth first.


  What we have now in the 2.00-rc2 is different and thus annoying.  So
were your parents when they forced you to brush your OWN teeth at the
age of three.  To quote the Eagles: Get over it.

		||ugh Daniel
		[email protected]

			Systems Testing & Project mis-Management
			The Linux FreeS/WAN Project
			http://www.freeswan.org

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv
Comment: For the matching public key, finger the Reply-To: address.

iQCVAwUBPmFvaFZpdJR7FBQRAQGFhwQAirGEntjKxnHYzEmAn/2bYKXbjDZkSBVl
TuTZ40A+P90aNGIkkQKqdHAYWt6HjgHbwnSc7w4xwJZNUcb6Q0xVeZ+BJ91PTRLd
em6LPQ0lSx7hk+Z4rKJUcHpPYxQ5azc1rVsjXuJMTOm2oFFhQkedoCS0AgwE7V/G
9h/HC+T2jFw=
=D/Vi
-----END PGP SIGNATURE-----