Re: VPN Touch doc

[Bill Fenner <fenner@research.att.com>]

Steve,

  One of us is missing something fundamental.  I think this document
makes a lot of sense.


>2.3: First, the example doesn't make sense; no one builds VPNs that
>way.

This approach solves a scaling problem with a central VPN server with
a star or mesh to "client sites", allowing you to treat the VPN links
much more like the links you would have in a private network and actually
run a routing protocol across them.  All of the routers in the topology
could still be under the PN's control (imagine each of these routers is
a customer security gateway).

>Besides, specifying the security policies becomes unmanageable.

Not if you have a security policy per virtual link (i.e. they're only
unmanagable if you do it the non-draft-touch way).

>More seriously, the whole business of "firewall-like matching"
>doesn't make sense.  If the packet is decrypted at A, the full packet
>header -- including Y's address -- is visible, so there's no problem.

The problem is actual implementations vs. dynamic routing.  If you
have one table which is your routing table, and one table which is
your SADB which will decide the actual destination of a given packet,
you have to teach your routing daemons how to dynamically manage the
SADB as well as the routing table.  If you use the draft-touch
method, you can
a) run a routing protocol on the virtual interface without modification, and
b) use the routing table to determine both the route and the tunnel.

>More precisely, the SA table does not mandate
>a particular path, regardless of implementation; it identifies a
>peer tunnel endpoint, and leaves it to IP to figure out how to get there.

But since it specifies a peer tunnel endpoint, the VPN's routing daemon
has to manage the SADB as well as the routing table.  You've described
the exact problem that this draft is trying to address.

>2.4 is equally problematic.  If X is both a host and an endpoint of
>a VPN -- the common case today is a laptop connecting back to a corporate
>net -- there is indeed a question of source address selection.  I agree
>that a very naive IPsec implementation might do the wrong thing, and it
>might be worth adding a paragraph to 2401bis to mention this.

The KAME IPsec implementation is this naive.  My impression is that
at least on BSD, it would be quite uncommon to see source address
selection occurring using anything other than the routing table.
(Neither FreeBSD nor OpenBSD uses anything other than the routing
table during source address selection in in_pcbconnect().)

Yes, I know that means that such implementations won't work in
the virtual-interface-free model.  Perhaps all working ipsec
tunnels on BSD-based operating systems use virtual interfaces.
Huh.

>IIPtran suggests using an outer IP header for constructing the SA (Section
>3.1).  But that precludes fine-grained SAs based on port numbers.  Or
>rather, it can, but only by peeking past an extra IP header.

This is a limitation; would you be happier if this was spelled out?


I think this
a) solves real existing problems for today's implementations (source
   address selection on BSD)
b) solves the dynamic routing problem which perhaps nobody is doing
   today but is an awfully nice capability

and although I agree that it doesn't fit the view of the world that
the IPsec working group has traditionally held, I don't see that as
a bad thing.  I've never been able to understand that world view,
while the one in draft-touch seems trivially correct.

  Bill