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

Re: Remove tunnel mode from ipsec-tunnels-02?



On Sat, 9 Sep 2006, Fred Baker wrote:
On Sep 7, 2006, at 3:57 PM, Pekka Savola wrote:
On Wed, 6 Sep 2006, Fred Baker wrote:
given that there are significant networks that operate in tunnel mode, including both corporate VPNs and military networks that use tunnel mode between encryption devices with a specific view to hiding interior addressing and therefore military asset distribution from prying eyes, this proposal seem profoundly silly.

Our assumption has been that transport mode is applied to a tunnel interface (such as IPv6-in-IPv4, GRE etc). That hides the inner addresses from those observers that would have been on-path in the tunnel.

well, yes, that's one way that tunnel mode is often implemented. It's hardly the only way.
...

It seems you're using the term 'tunnel mode' to refer to any kind of IPsec protected session where there is a separate inner header that is protected by IPsec. AFAICS, in IPsec specifications 'tunnel mode' has a more constrained meaning. In particular, transport mode IPsec SA may or may not have an inner IP header, depending on what kind of traffic transport mode is applied to. So, transport mode can be used to build tunnels with the properties you seek.

The key difference when tunneling is whether IPsec itself performs the tunneling operation (i.e., tunnel mode SA), or whether IPsec is applied to a tunnel interface, resulting in an outer and inner IP header (ie., transport mode SA). In both cases the inner addresses are protected by IPsec.

For example, IPsec-protected GRE or L2TP tunnel is NOT typically a tunnel mode SA. Conversely, you can use IPsec transport mode to create a tunnel with inner and outer headers.

When IPsec tunnel mode is _NOT_ modelled as an interface, then this is OK though IMHO suboptimal because you cannot in practice run neighbor discovery, routing protocols, multicast etc. over such tunnels. Due to the link-local issues mentioned previously, tunnel mode is not something we can recommend when it's modelled as an interface.

I'm not entirely sure what the modeling question means to you. Are you objecting to the use of a tunnel header, or the configuration of an interface to do this?

'modelled as an interface' here referred to representation as an interface, because if you have an interface, the interface should also have link-local addresses and securing those is difficult with tunnel mode.

I think we're in full agreement about the fundamental issue: there should be an inner IP header that's protected by IPsec. The point is that it can be provided either by transport or tunnel mode, and based on our analysis 'tunnel mode' is a more constrained way of making such a tunnel and therefore less preferred.

--
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings