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

RE: comments on VPN framework document



> -----Original Message-----
> From: Bryan Gleeson [mailto:BGleeson@shastanets.com]
> Sent: Friday, October 09, 1998 9:00 PM
> To: Stephen Waters; Bryan Gleeson
> Cc: ipsec@tis.com; l2tp@zendo.com
> Subject: 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.

Agreed, it needs fixing.
 
> 
> > 
> > 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 :-)

So the difference would be:

  [IP2][IPSEC][UDP][L2TP][PPP][IP1][TCP][APP]   now 

  [IP2][IPSEC][  New Headers   ][IP1][TCP][APP]   later.

  The 'Newheader' would need to cover PPP-like and L2TP-like features.


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

Yes, just like Frame Relay and ATM - but aren't folk 
nervous of those links now? I thought the FR forum were 
doing some security work...

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

For IP-only networks, yes. Others would still need L2TP 
or one day the 'New Headers' and IPSEC.

Thanks for the response Bryan.  One aspect I wanted to see 
some focus on (and didn't spot) was end-to-end QOS monitoring -
measuring dynamically how much of the 'guaranteed bandwidth'
I'm actually getting through a VPN.

Cheers, Steve.

> Bryan
> 
> 
>