Re: VPN Touch doc

[Rob Austein <sra@hactrn.net>]

i'm probably gonna regret sticking my oar in here, but as someone who
has messed around with esp tunnel mode with both freebsd (kame) and
linux (freeswan), i delude myself that i understood some of this.

kame setkey spdadd is indeed somewhat "firewall-like".

bill's comment "Perhaps all working ipsec tunnels on BSD-based
operating systems use virtual interfaces" is overstating the case at
least slightly.  tunnel mode does work with kame without any sort of
virtual interfaces.  but i haven't tried it with dynamic routing.

taking a step back, the real problem here, as far as i can tell, is
that overlay networks are confusing when a single ip engine with a
single ip forwarding table has to operate in both the overlay
network(s) and the base network.  ie, the fundamental problem is not
ipsec per se at all.

freeswan does (or did, i haven't used it recently) take the virtual
interface approach, but they then had to add a second routing table to
control where the encrypted packets go, because they've already used
the "real" routing table to control what goes into the tunnels.  kame
uses rules in the spd, which does indeed look like a pain for any sort
of dynamic routing of the overlay network, but kame at least avoids
the mess that freeswan made at the base network layer (and at least
kame -has- an spd -- freeswan uses the routing table and the ip packet
filtering code).  if there's an implementation that doesn't get into
this swamp, i haven't found it yet.

it was not obvious to me from (quickly) reading the touch draft why
the ipip tunneling mechanism would somehow be imune to these layering
confusion problems.  as far as i can tell, they go along with tunnels,
whether those tunnels be encrypted or no.  which makes me suspec that
some of what the touch draft is on about may be implementation issues
rather than anything fundamental about ipsec tunnel mode.

the one thing that this iiptran thing proposal does seem to do is to
pry the tunneling part away from ipsec.  this might conceivably be
easier to deal with in some implementations.  eg, one could run
multiple routing engines (that somehow avoid stepping on each other's
toes in the forwarding table) without having to worry about the ipsec
interactions in the tunnel setup.  but the comments about needing
additional checking to make sure that policy rules are being followed
worried me a bit, and sounds like an as yet unexplored (and
potentially large) can of worms.

dunno if any of this helps.