Subject: [anonsec] BTNS and NAT-traversal

From: mcr at sandelman.ottawa.on.ca (Michael Richardson)
Date: Fri, 07 Apr 2006 15:41:20 -0700

>>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at sun.com> writes:
    Nicolas> So, I envisioned NFSv4 use of BTNS (w/ channel bindings) as a
    Nicolas> way to push session crypto down the stack for performance wins
    Nicolas> that I expect to be primarily useful in intranet environments.

  Critical there. 

    Nicolas> HOWEVER, I can certainly see that running NFSv4 over
    Nicolas> TLS/SSHv2/whatever across NATs will be important, so I think
    Nicolas> this should stay in scope.
  
  The client has no problem doing the TLS/TCP talking to one server.
  The NAS has problems dealing with the multiple-thousands of sessions, and
you get into TCP and SSL offload, and lots of pain because you try to do load
balancing at the wrong point in the stack (where it stateful) rather than
doing it where it is easy (where it is mostly stateless).

    Nicolas> I remember conversations about how HIP and BTNS were working on
    Nicolas> 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.

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

  I think that shim6-boot-strap-to-HIP still needs a bunch of things that we
would want to do for BTNS.

- -- 
]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] mcr at xelerance.com      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [