<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small">Pulling together various threads here.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Tero and Christian identify the poor-man's firewall aspect of NAT as the bigger issue than NAT itself. But the reason residential users have ended up with poor firewalls is largely because of the same IETF obsession with 'end-to-end' purity. Which is really weird if you have talked to the originators of the end to end model.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Einar Stefferud used to give a really clear presentation on this. The Inter-network is a network of networks and it has different properties to any of the component networks. It has no central administrator. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The original Internet design was a bridge between LANs. The notion of end-to-end IP came much later. When it did, the notion that the network and the inter-network were of entirely different character was lost. Had we insisted on maintaining that distinction the role of Firewalls and NAT would have been obvious: They are there to patrol the border between the network and the Inter-Network.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">People can argue about the effectiveness of NAT and Firewalls. But the ideas were never really given a proper chance. The notion that the MIT network boundary was a distinct entity was emphatically rejected. Those of us that suggested the relationship of one machine on the MIT network to another machine on the same network might be very different to the relationship to a machine on an unknown network were treated with contempt. UNCLEAN! UNCLEAN!</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">IPsec is a pig in a poke as a result of the resulting confusion. There are three different modes of IPsec deployment:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">A) End-to-End</div><div class="gmail_default" style="font-size:small">B) End-to-Network (VPN / dialup / remote access)</div><div class="gmail_default" style="font-size:small">C) Network-Network</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Rather than face the fact that the majority of actual deployments would be types B and C, the group was only allowed to discuss A. And we had the old IETF trick of biasing the whole discussion to a particular architecture by ruling out all requirements that would drive a different one 'Oh lets not do that now, let's do the simple thing first'. I think that's how the NSA troll managed to sabotage DANE and DPRIV. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Putting the TCP checksum inside the ESP encrypted payload was a bad mistake. There is absolutely no reason not to reveal the checksum of ciphertext that is already available to an attacker, it reveals no additional information. There is however a very good reason not to insert a checksum of the plaintext into the ciphertext: it provides the attacker with a crib.</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">We are finally getting to the notion that application executables should be signed and bound to a set of specific privileges. The old model where every program Alice runs with full Alice privileges is emphatically rejected on Android and iOS. We need to get to a model where Alice's grant of privileges extends out to the network edge with a default deny posture.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So the idea is that Alice's phone can send and receive packets on arbitrary ports and protocols to the outside world on the Enterprise network because it is appropriately privileged. But that in turn means that device cannot connect to certain internal resources due to policy (cf separation of roles, if you have the HSM you cannot have the key).</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">We are nowhere close to being able to realize my plan with existing systems but I do have a plan to get there</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">1) Provision and credential every device with non-expiring keypairs (preferably, device bound)</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">2) Internal network WiFi/Ethernet hubs and switches all become access controlled switches. Devices must authenticate and their network traffic must conform to policy.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">3) External border maps private Internet addresses (10.x.x.x or IPv6 LAR) to/from routable addresses.</div><div class="gmail_default" style="font-size:small"></div></div></div>