Re: letting traffic flow through a SG by default

On Tue, 11 Mar 2003, Sam Sgro wrote:

> 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.

On 03/12/2003 08:24 AM, Paul Wouters wrote:

 > Add to the manual: A security gateway is NOT A FIREWALL.
 > Use excessive large font.

How do you know a security gateway is not a firewall?

Please refer to http://www.ietf.org/rfc/rfc2401.txt
starting at section 4.4.1.  Any instance of IPsec must
provide a security policy database (SPD).  This SPD must
have considerable expressive power.  Who is to say
that I may not choose my security policy, as expressed
in the SPD, to implement firewall-like functions?

> This problem isn't different from any nonOE setup, eg an extruded 
> subnet, or a classic private space VPN tunnel.

Yes and no.
   1) In theory, the problem _shouldn't_ be any different
      in the two cases.
   2) The OE work over the last couple of years has
      developed some good ideas that support things
      that really matter, notably scalability.
   3) OTOH the OE implementation as it stands is
      severely limited.  I consider it "looking under
      the lamp-post", solving a certain subset of the
      problems not because that subset is the most
      important but because it is the easiest to solve.
      In particular it does not implement a sufficiently
      rich "trust model" or "trust policy".  I believe
      a fundamental re-think is required.

I believe that scalable ("OE"?) solutions that are robust
enough to handle trust models suitable for VPN usage
are possible -- but we haven't seen them yet.


> Perhaps we can add a section on why it is unwise to combine classic 
> VPN's and hostOE on the same box.

We agree on this, though possibly not for the same
reasons.

> After all, who do you want to knock at your firewall to begin with.

That's a very interesting question.  That is tantamount
to asking what is the content of the SPD.  IPsec must
provide a flexible, expressive SPD.  It must not dictate
what policy is expressed therein.

>> 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.

I agree with Sam, iproute2 is a Good Thing (tm).
I've been relying on it for years.
If somebody asked me to set up a fully-functional FreeS/WAN
system not using iproute2, I wouldn't know how to do it.
It would be difficult, maybe impossible.