[Cryptography] Two quick questions about IPsec AH

[Phillip Hallam-Baker]

Pulling together various threads here.

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.

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.

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.

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!

IPsec is a pig in a poke as a result of the resulting confusion. There are
three different modes of IPsec deployment:

A) End-to-End
B) End-to-Network (VPN / dialup / remote access)
C) Network-Network

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.

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.


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.

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


We are nowhere close to being able to realize my plan with existing systems
but I do have a plan to get there

1) Provision and credential every device with non-expiring keypairs
(preferably, device bound)

2) Internal network WiFi/Ethernet hubs and switches all become access
controlled switches. Devices must authenticate and their network traffic
must conform to policy.

3) External border maps private Internet addresses (10.x.x.x or IPv6 LAR)
to/from routable addresses.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20220111/3a6d4fd9/attachment.htm>