[anonsec] BTNS and NAT-traversal

[Nicolas Williams]

On Tue, Mar 21, 2006 at 02:40:44PM -0600, Michael Richardson wrote:
>     Nicolas> I don't mind leaving NAT in scope because your solution
>     Nicolas> seems obvious enough and seems not to do too much violence
>     Nicolas> to IP/IPsec.  That said, I would insist on this being
>     Nicolas> optional, or even a separate document altogether.
> 
>   I don't see use cases for BTNS (particularly when it was an enabler
> for channel binding) that do not involve NAT-traversal. Except for
> securing BGP.......
>   We are talking to customers who want to build various kinds of NFSv4
> NAS things that live centrally and talk to widely distributed
> clients (naturally, NAT'ed out the wazoo). The load/power-considerations
> on the NAS device is such that they hardware acceleration is
> cost-effective, and this favours IPsec rather than GSSAPI for doing the
> encryption.  

So, I envisioned NFSv4 use of BTNS (w/ channel bindings) as a way to
push session crypto down the stack for performance wins that I expect to
be primarily useful in intranet environments.  HOWEVER, I can certainly
see that running NFSv4 over TLS/SSHv2/whatever across NATs will be
important, so I think this should stay in scope.

My only question is: what I-D should deal with the NAT issue?  I'm happy
with the connection latching I-D containing this, but I can also see it
as a separate I-D.

>     >> Now, if you have a', guess what... *A* is not UNIQUE. You REQUIRE
>     >> connection latching, and BITS and BITW just can't work easily.
>     >> 
>     >> If you have b), then guess what... *A* is not UNIQUE.  Note that
>     >> (b) is morally equivalent to gateway mode, from a policy point of
>     >> view.
> 
>     Nicolas> BTW, is there a potential argument here that connection
>     Nicolas> latching SHOULD or MUST be used with tunnel mode only
>     Nicolas> because it makes (I assume, for this argument)
>     Nicolas> implementation of this sort of NAT traversal easier?
> 
>   I'm not sure I agree.

OK, just checking :)

>     Nicolas> But not because of BTNS.  End-to-end IPsec NAT traversal
>     Nicolas> has this same problem, no?
> 
>   Yes. But like everything else, BTNS makes IPsec use more ubiquitous...

Indeed.

>     Nicolas> I remember conversations about how HIP and BTNS were
>     Nicolas> working on the same problem from different directions.
> 
>   Now that I understand shim6, I wonder if we are wasting our time, and
> should just switch to shim6-upgrade-to-hip.

Heh.  I don't understand shim6 yet -- I haven't looked at it.  It's
entirely possible that for some uses of BTNS we are wasting our time.
But for my original use case I think BTNS w/ connection latching and
channel binding is the simplest solution to implement and deploy.

Nico
--