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

RE: comments on VPN framework document


Hi Frank,

The VPN framework lists some of the problems, but my main problem with a
plain 'IPSEC-tunnel' is that it is not a tunnel at all, really - just a
security encapsulation scheme.  If you encrypt the original IP header, what
alternative have you got but to add another one.

For LAN-to-LAN, I want to have a virtual IP interface to play with. An IP
interface I can run routing over. For example:

   Virtual IP interface (16.36.16.200, RIP enabled)
   IP Tunnel (peer tunnel address 192.23.45.67) - a 'data-link' to the
Virtual IP interface. 
   IPSEC-transport-mode

With IPSEC, there is no mechanism to define an 'Virtual IP interface' that
can be managed as any other IP interface - routing/cost/filtering/.... 

Perhaps this is just the way that I (and others) have implemented it -
following the basic model in the IPSEC architecture, i.e. the SPD model.

Maybe the solution for LAN-to_LAN is to model IPSEC as a tunnel 'datalink'
and have no SPD at all (or a single policy one):

   Virtual IP Interface (16.36.16.200, RIP enabled) 
   IPSEC Tunnel 'data-link' (peer tunnel address 192.23.45.67, ESP/3DES
tunnel)

Now, if the IPSEC tunnel device could gain some of the features used in
L2TP, we would have something for LAN-to-LAN.

In the meantime, I'm thinking that L2TP+Transport-mode-IPSEC is as close as
we can get today.

Cheers, Steve.


 





> -----Original Message-----
> From: Frank O'Dwyer [mailto:fod@brd.ie]
> Sent: Saturday, October 10, 1998 3:01 AM
> To: Stephen Waters
> Cc: bgleeson@shastanets.com; ipsec@tis.com; l2tp@zendo.com
> Subject: Re: comments on VPN framework document
> 
> 
> Stephen Waters wrote:
> > 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. 
> 
> Could you summarise the problem with IPSEC-tunnel for LAN-LAN use?
> 
> Cheers,
> Frank O'Dwyer.
>
Follow-Ups: