Re: VPN Touch doc

["Steven M. Bellovin" <smb@research.att.com>]

Here are my (belated) notes on draft-touch-ipsec-vpn-06.txt.  They boil 
down to the impression that Touch et al. have constructed a straw man
and then designed a mechanism to solve their "problems".


---
Nit: Fig 3 (and text in 2.2): line 3 goes to B; link 4 goes to C

2.3: First, the example doesn't make sense; no one builds VPNs that
way.  It's simply a security problem -- you don't want the unprotected
packets to exist in the middle of the net.  Besides, specifying the
security policies becomes unmanageable.  But that's a minor point.

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.
If the packet isn't decrypted (or otherwise stripped of the IPsec
encapsulation), the outer IP header's destination address is going
to point to the destination gateway, and normal IP routing will get
it there efficiently.  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.

Furthermore, the "firewall-like matching" is required by 2401 precisely
to permit the overlapping VPNs described in Section 1.  That will be
true regardless of whether or not a virtual interface is modeled.
If it is, in fact, modeled, the sending host must apply some sort of
policy routing.

Maybe it's just a wording issue, but I fail to see how this makes
any sense at all.

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.  But it's
unlikely to happen in practice, because it won't work.  Section 5.2
of 2401 notes that on packet receipt, the inbound packet must be matched
against the security policy database; if there's no policy that permits
traffic on some SA that has a base network address, the packet will be
discarded.  So yes, there could be a problem if the sending implementation
is stupid -- but such an implementation won't interoperate with a
standard-conforming receiver.

If the gateway and the host are disjoint, there's no problem at all,
since the sending host has only one source address.

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.


		--Steve Bellovin, http://www.research.att.com/~smb