Re: letting traffic flow through a SG by default

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


On Mon, 10 Mar 2003, D. Hugh Redelmeier wrote:

> | 1b Packets from nodes behind the SG will not get out because
> |    (i) we've installed a default route to direct all packets from
> |        the SG through ipsec0, and
> |    (ii) there is no eroute for packets from behind the SG
> |    The result is that the default policy will apply: %drop.
> 
> Management has decided that the behaviour Sam dislikes is a mistake.

   (Caveat: If I make an erroneous assumption about OE's method of 
negotiation, please correct me.)

   Defaulting to packetdefault=pass just seems as if would cause more security
concerns than it would solve.

   Imagine this scenario: I've got a gateway running FreeS/WAN, configured
with a few VPN conns. If that gateway were configured to do OE only for
itself, a malicious hacker could negotiate an OE connection with it, and then
pass packets intended for the subnet behind down the tunnel.

   With packetdefault=pass, those packets would be readily passed to the
subnet behind.  You could have packets with any source or destination address
flying back and forth; ipsec.conf's man page even mentions you shouldn't have
packetdefault=pass "unless you really know what you are doing". 

   I believe the security concerns raised in employing packetdefault=pass by
default nix this as a solution.

   Instead of addressing the problem at 1b(ii), I'd prefer to do so at 1b(i).


Solution 1: iproute2

   For OE, we have chosen to direct *all* packets, regardless of source or
destination, through ipsec0. One solution would involve re-thinking this
logic.

   It seems safest for us to predict that we will attempt to do host based
routing. Let's talk about this: I put forward the theory that when we talk
about configuration-file absent OE behavior, we (currently) assume we will do
OE for IPs on the machine FreeS/WAN is installed on, but nothing further than
that.

   The TXT record specifies who is authorized to encrypt on your behalf. Since
this is still dependent on having a KEY record, simplying pointing a TXT
record at a non-OE gateway won't prompt a negotiation. If another person on
the net were to generate a TXT record that referred to my gateway with my
(published) public key, the negotiation would ultimately fail since no
preconfigured OE / Policy Group conn is in place.

   So, we are aiming (currently) to do host-based OE out of the box, with no
configuration file. As such, we're assuing %defaultroute, so only one IP 
address will be of interest, and it's already known by this stage of FreeS/WAN 
startup.

   So, let's conclude: we currently capture all packets exiting the public
interface; this does not represent the minimal set of packets that we could
actually do useful work with. It can be reduced further to be all packets 
originating from the IP address bound to ipsec0.

   Most modern kernels have the "iproute2" suite of routing tools available,
which allow for greater precision in defining routes. Updating our _updown
script to take advantage of these features would allow us to redirect all
packets originating from ipsec0's IP to ipsec0 (and into our machinery). The
%pass eroute would not be necessary because those packets from the protected
subnet would never be captured, and would thus escape unscathed.

   We have been in the midst of exploring iproute2 as it pertains to
FreeS/WAN, and this would seem an ideal time to employ its feature set to help
solve this problem.


Solution 2: Don't enable OE unless we can do it

   There is no such thing as "enabling OE by default" by simply turning on the
Policy Group conns; that is the only one necessary component.  Without KEY/TXT
records created and input into DNS, the machinery in place can perform no
useful function.

   Ultimately, our users are experiencing breakage because we try to do
something which, for most VPN users' default install, CANNOT work. Not all the
requirements for successful OE have been met and, not surprisingly, things
break. 

   The solution I prefer by far is not to enable any Policy Group or
Opportunistic based connection unless KEY data for our own side exists. In
short, we need to evaluate ourselves as a potential OE client. If we fail this
evaluation, no packets need be captured. In short, don't --add, or at least
don't --route, the policy group conns when no KEY/TXT data can be found.

   If you've already committed to OE on your SG, then breakage may be okay.
it's not difficult to ensure %pass eroutes get created for the subnet behind
you, as a previous mail of yours had outlined, or employ iproute2, or any
number of other changes needed to accomodate both OE and a SG setup. (And
AFAIK, we're planning on implementing features that will make this even
easier.)  Anyone who hasn't gone through the effort to configure DNS records
for OE (ie, VPN users) won't be bit by this.

   Solution 2 has its own concerns - a malicious user could insert KEY/TXT
records for the public IP of their gateway, and magically turn it on,
theoretically allowing for privileged access to the gateway (and the gateway
only). This may be something we need to think on further.

- -- 
Sam Sgro
[email protected]


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

iQCVAwUBPm3bv0OSC4btEQUtAQExFwQA2pnHEElh50ifMoqqPocgoNSTvofCeIt1
XYBnYL9sgjJjAzYXdrxki6ixn+o2FMNbz+dARDpyCkqebHeLq9Ynq3gt7W9077eO
GNF4P94NV8t5PiPl2dhBgF4b0NWzkld8dKO15+0Wbl7irs0mBhRtep/ZVjNZgDn4
OxWQHgSU5jU=
=fYwo
-----END PGP SIGNATURE-----