[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: comments on VPN framework document
Stephen Waters wrote:
> 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.
Stephen, thanks for clarifying this - use of a virtual interface does
sound more like a stack implementation issue than a protocol issue
though (i.e. not a limitation of IPSEC-tunnel mode itself?). Or would
something have to change on the wire protocol before you could implement
that? It seemed to me from reading the I-Ds that the wire protocol was
designed for host-host, host-gateway, gateway-gateway, and gateway-host
modes--assuming the implementation is configurable enough. Have I missed
something? Are any of these modes deprecated on security grounds (other
than the obvious limitations of using a security gateway instead of an
end-to-end protected connection)?
Cheers,
Frank O'Dwyer.
[...]
References: