Subject: [anonsec] BTNS and Tunnels

From: Black_David at emc.com ([email-masked])
Date: Mon, 31 Oct 2005 15:30:26 -0500

Catching up on an old thread ...

> Pekka Nikander writes:
> > > usage scenarios. Is there some potential usage that we
> > > are preventing if we don't allow tunnel mode?
> > 
> > IIRC, someone (David Black?) mentioned at the Paris meeting that some  
> > IP storage solutions currently require tunnel mode.  Therefore our  
> > f2f decision was to include tunnel mode where the inner and outer  
> > addresses are equal.
> 
> Also NAT-T is simplier if done on tunnel mode, no need to mess around
> with original IP-addresses and updating checksums. In NAT-T case the
> inner and outer addresses are not equal, as outer address is the
> NAT-boxeses address, and inner address is the endpoints address. I do
> not think if the NAT-T is relevant to the btns...

Yes, IP Storage use of IPsec (see RFC 3723) requires tunnel mode.  This
is not precisely self-tunnel, as there's no requirement that the IP
addresses match (although it's obviously easier to deal with if they
do), but the intention is that the tunnel be end-to-end (e.g., a final
dedicated forwarding hop out of the tunnel over an internal link to the
iSCSI node is ok, having that hop be over an external shared network is
probably not).  Channel binding to tunnel mode SAs is definitely needed.

I support Tero's comments on NAT-T - getting that into IPsec took enough
work that we should avoid damaging or breaking it - it's entirely too
useful ;-).

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david at emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------