<div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 7, 2022 at 1:03 AM Christian Huitema <<a href="mailto:huitema@huitema.net">huitema@huitema.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>On 1/6/2022 6:31 PM, Peter Gutmann wrote:<br>
</p>
<blockquote type="cite">
<pre>Phillip Hallam-Baker <a href="mailto:phill@hallambaker.com" target="_blank"><phill@hallambaker.com></a> writes:
</pre>
<blockquote type="cite" style="color:rgb(0,124,255)">
<pre>I remember sitting in an IPSEC meeting at the Dallas IETF and hearing the AD
call this 'a feature'.
</pre>
</blockquote>
<pre>Yup, I remember that too (not at the Dallas IETF but elsewhere). The thinking
was "IPsec will be bigger than NAT so if we make sure it breaks NAT, NAT will
go away".
This anti-NAT crusade within the IETF persisted for a long, long time. Look
at RFC 3424 for example, which invented a childish backronym "UNSAF" to refer
to NAT-transversal mechanisms so it can talk about UNSAF clients and UNSAF
servers throughout. Section 4 is particular amusing, describing the various
levels of self-flagellation that any UNSAF mechanism is required by the IAB to
subject itself to.</pre>
</blockquote>
<p>... which is why I had to write something like 19 iterations of
the Teredo draft in order to jump through the UNSAF loops.
Standardizing STUN also took a long time. Yes, that was silly. But
the argument that I heard then was not that "IPsec will be bigger
than NAT". Yes, there was the anti-NAT argument that IPv6 will
make all that complexity go away, but there was also the pro-NAT
argument about NAT providing a firewall service to users, so don't
you dare break through that firewall, even if it is required for
video conferences or video games.</p></div></blockquote><div><div class="gmail_default" style="font-size:small">One of the big problems in IETF is that the IAB was originally intended to be the DARPA program managers paying for the work. As the IETF expanded, they devised a politburo system to maintain control which turned into the NOMCON scheme. All the rough consensus and running code guff really boils down to a bunch of unelected, unaccountable people taking random decisions with little recourse. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The anti-NAT jihad continued because the NOMCON by design selects people who 'will work well together'. They (usually) make sure nobody will rock the boat. I burned a lot of political capital by pointing out that NAT was going to be widely deployed and used regardless of IAB distaste and more importantly, there was no way to deploy any IPvNext without an address translation layer.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I agree that NAT does have some value as a poor-man's firewall. But it is not a very good firewall and nor are the devices sold as firewalls. And again IETF ideology has hurt, not helped. IETF had a jihad against firewalls before NAT was a thing.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">What IETF should have done is to identify the network-internet boundary as a control point that the network owner is responsible for policing. They should have pushed for NAT and a good firewall.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So going back to cryptography, how am I going to fix things in the Mesh?</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Well first off, my short term plan is to package the Mesh as a podcast course on information security showing that the current state of affairs is not inevitable. There are other design choices that could have been taken.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Secondly, I believe in permissionless innovation, I post to the IETF list to let them know what I am doing. I am not asking for permission, no accountability means no authority in my book. Being told that the system cannot possibly work is of course an essential part in the foundation myth of every new invention. The New York Times and Washington Post etc. love the idea of a lone inventor contra mundum. Which is exactly what I am giving them.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">At the technical level, we have to make security policy work. The Mesh is designed to provide a path to default deny security in which every device connects to the network with minimum privileges and those privileges are enforced in the network itself.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">This is going to require every bit of the network stack to be touched eventually. I am starting at the application layer and working down. Part of the Mesh is the Device Catalog. Provisioning a device to a user's personal Mesh is simple, it can be achieved through a simple QR code interaction. So take the device out of the box, scan a QR code, turn it on and the device is now connected to your personal Mesh.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">[And why yes, I do have running code for all of this except for the bit about acquiring the network parameters]</div><br></div><div><div class="gmail_default" style="font-size:small">So if I win, after a short while, IoT devices will start appearing with a 'Mesh Ready' sticker on them to tell the customer that all they need to do is scan the device with an app and it just works as part of their personal Mesh without any further configuration. And the only reason I might not win is that someone else has beaten me to it with a scheme that has the same properties.</div><br></div><div><div class="gmail_default" style="font-size:small">So at this point Alice buys a network hub that has the Mesh ready sticker on it as well. And this enforces a security policy that is derived from the device profile established when the device was connected to the personal Mesh. The coffee pot can talk to the home automation dashboard devices and nothing else, it can't send email. A laptop or a desktop has much broader privileges. A dedicated server is constrained to its functions, yadda, yadda. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Security policy can only work if the policy is being automatically generated and maintained. If a network admin has to configure security policy separately from administering the hosts, it will always be inconsistent and out-of-date.<br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Yes, I know that there are bits and bobs that are kinda sorta part of such a scheme floating around IETF and IEEE but they don't really work because none of them is designed to realize an over-arching vision and so none of the roads actually meet up. They are tightly focused, point solutions that are more concerned about not treading on another group's turf than delivering a seamless user experience. WiFi UI has been crap for over 25 years and it is still crap. We could make it un-crap in a few weeks if we could get the right engineers in a room together with the right attitude.</div><br></div><div><div class="gmail_default" style="font-size:small">All WiFi has atrocious security because consumer security is password based with a single password per network. There are other options available in theory for corporate environments at greater cost but they have withered away because the consumer approach is the only approach every device supports. So the attempt to establish a premium market failed and the engineers are convinced that the reason is the technology failed rather than their marketing was greedy and stupid.</div></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">To fix WiFi, begin with one simple principle: No passwords.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Devices should be able to authenticate to a WiFi network without the use of a password ever.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Anyway, the pain has dulled enough for me to begin writing some code today so I will.</div><div><br></div></div></div></div>