[anonsec] BTNS and NAT-traversal

[mcr at sandelman.ottawa.on.ca (Michael Richardson)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at sun.com> writes:
    >> (%) Yes, there are some systems that let transport mode change
    >> TCP (or SCTP) connections into UDP connections... they are
    >> broken. Openswan KLIPS was such a system until recently.

    Nicolas> Yes, I see now (actually, I saw yesterday :)

  Sorry... I wrote that on airplane, but it didn't go out until I
noticed it pushed. I'm a newbie to using GNUS+agent to read gmane.org.

    Nicolas> Now, we could leave NAT out of scope :) or we could do what
    Nicolas> you suggested yesterday, namely, to use connection latching
    Nicolas> as part of the packet inbound dispatch/outbound SA/tunnel
    Nicolas> (or NAT address) selection process.

    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.  

    >> 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.

    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.

- -- 
]       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"); [

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBRCBkyoCLcPvd0N1lAQJ8BQf/dqA0dVznQCT3mGwKXFkZrI1A2F9W13n7
HnEokThEtaw9a60mlfDHwcgLk0Gi2zCzrFEIcDas4/Imii+xzO/k1APUp9aIqUk3
lgRHONeD3sTglidXR4PnuVSHptAlKAewVqjtdy7xq8PBRpi0jN0shEgqXklYQ80D
JVxQW+aK3VPHKl9A1FPKJ3wnf8it+33YcEthBLP8kutjDJHAY1qycbu7Xjv7sA/b
yIxGYFihsaQl831KVGG1ldcYMKgR7i5Kde7ahrKTgz2JmYEuOdGleTAb551ujhbG
lKvf3no6n7ghYpJ+cn3SXxC7THZsaA/RWjzbqM/oOwSycJ5Yh3uENQ==
=FYOZ
-----END PGP SIGNATURE-----