[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: comments on VPN framework document

Stephen,
 
> 1) L2TP seemed to get the thumbs-up on all count except 
> security. If IPSEC
> is applied to the resulting
> L2TP UDP/IP packet in TRANSPORT mode, that does seem to solve 
> the problems.
> 
> I have never seen IPSEC-tunnel as being useful for LAN to 
> LAN.  It is fine
> for host-to-host,  and for host to security gateway, but not 
> LAN-LAN. Maybe
> it can be fixed, but in the meantime:

Restricting the applicability of IPSEC to scenarios where one
party is a host seems very limiting, and not necessary. Making
small modifications to IPSEC to allow wider applicability of 
its use in non-host contexts definitely seems something that 
should be pursued. 

> 
> L2TP tunnel packets protected with ESP encryption would add 
> as little as 9
> bytes of ESP overhead.
> The encryption algorithm used may add another 8 to 14bytes and the
> authentication option another
> 12 bytes.  However, these encryption/authentication overheads would be
> incurred whatever route you take, so it comes back to 9 bytes 
> per packet
> additional for ESP overhead.   Four bytes of this overhead is used to
> prevent replay attacks, and four bytes are used to multiplex. 
>  The four
> bytes of replay protection are a general requirement, so they 
> remain 5 bytes
> (multiplexing and next-hdr bytes) are the only true over head 
> of applying
> ESP transport mode.

While the extra bytes needed on the data plane may or may not
be viewed as significant (and there's the PPP and UDP overhead
also), there is the additional requirement of the L2TP signalling 
component, and its associated configuration. To me it just seems 
hard to justify why you need two of something, if one will do. 
I see the same motivation driving the idea of allowing a remote 
host's IP address and DNS server to be configured via ISAKMP, 
rather than requiring PPP-IPCP or DHCP as well. It also seems 
more pragmatic that requiring stacks that look like

    APP/TCP/IP/PPP/L2TP/UDP/IPSEC/IP/L2/L1

(I'm sure ISO-OSI would have been proud of that one :-)
 
> 2) VPRNs look very complicated.  The document is VERY 
> VPRN-heavy, I feel.  I
> am concerned that the VPRN model is both restrictive, 
> inflexible and relies
> on security being managed for you by the VPRN provider.  I 
> much prefer the
> VLL approach described - just so you know :)  

The main benefit of a VPRN is that it allows for very
simple CPE devices, in simple connectivity scenarios.
If the CPE device just has a single link to the ISP
you can configure it with a default route and you are
done. The VPRN section describes a number of different 
problems that need to be solved for any VPN (e.g. 
membership and reachability determination and 
dissemination). There are a number of ways to solve 
each one, but I would not say that VPRNs are inherently 
complicated. It is more a matter of where you place 
the functionality - CPE router or ISP router. Also for 
network based VPNs many of the same mechanisms are needed 
whether the connectivity service provided is at layer 3 
or layer 2 (VPLS).

There will never be a 'one size fits all' answer to
the level of trust a customer gives to a service
provider. The level of trust given to a provider
in the case of a VPRN is similar to that given to
a provider that provides an ATM PVC today. Packets
are switched inside the network, and sent to other
sites in the corporate network, and you assume that 
they don't go to your competitor sites. A customer
can always choose to do more security, transparently
to the service provider.

 
> 3) I am not convinced the 'Compulsory' tunneling for remote 
> access will be
> attractive (I'll get some heat for that one no doubt).  Again, it is
> inflexible, insecure on the outer PPP links, and relies on 
> the ISP providing
> authentication services.  To protect the LAC-LNS flow would 
> mean sharing
> ipsec security information with the ISP.  Besides, 
> 'Voluntary' sounds more
> friendly :).  I think a vanila IPSEC tunnel in valuntary mode 
> would do most
> folk - no L2TP.

This seems an argument for using IPSEC by itself as a tunneling
protocol, and not requiring L2TP. I agree!

Bryan