[anonsec] BTNS and NAT-traversal
Nicolas.Williams at sun.com
Tue Mar 21 15:03:32 PST 2006
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
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...
> 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.
More information about the ANONSEC