On Tue, Oct 3, 2023 at 1:31 AM Christian Huitema <huitema@xxxxxxxxxxx> wrote:
+1. As Phill says, we can trace many big concentrations effects to
defects in our specification, and specially to security issues.
Phill mentions the relation between spam and email concentration. I
believe that he is right, and in fact the DINRG workshop on
concentration in the Internet outlined the same issues
(https://datatracker.ietf.org/meeting/114/materials/slides-114-dinrg-a-quick-summary-of-dinrg-workshop-on-centralization-in-the-internet-june-3-2021-01).
We see the same kind of concentration happening in CDN servers because
it is too hard to defend against DDOS just by yourself, and it is
starting to happen in the concentration of DNS servers for similar
reasons. Lesson: if the IETF is not ready to address issues, big
companies will.
Big companies are not much into thinking about the issues either. It falls to academics and a small number of individuals with private means to think about the big picture. And the type of work needed isn't exactly the sort of thing that impresses tenure committees.
DDoS is an example of a situation where the IETF can't deliver a solution because there is no solution in the pure end-to-end model. If people talked to Dave Clark, or actually read rather than merely talk about the paper he wrote 40 years ago, they might appreciate that end-to-end vs intelligence in the network was not a binary choice.
I now have 960 Mbs service to my home and so do many other folk. And that is a vast amount of DDoS power sitting out there in the hands of people who simply don't have the tools to mitigate DDoS attacks coming from inside their home network. We might have to rethink a few things if we want stuff to work right in future because at some point, even the likes of Akamai and Cloudflare aren't going to be able to provide the necessary mitigation
One of the questions that is rarely asked in IETF is 'how much information does a middlebox need to perform all the functions we require of it'. The closest we get being 'how can we make these horrid middleboxes cause the least amount of problems before they are made obsolete by IPv6'.
We need to return to the original model of the Inter-Network in which the Internet was the glue between the networks. I have over 100 devices with IP addresses assigned in my home network. Some of those devices run unsafe code. I am not on call 24x7 to manage the home network. So what happens if some North Korean ransomware gang compromises the cat's Internet connected poop machine?
Firewalls are far from perfect, they do very little in terms of security unless configured and managed right, in which case they get in the way. But one thing they (can) do pretty well is to block TCP/IP based DDoS attack.
Situation we have now is, most home users don't have a firewall, they have NAT which merely blocks inbound connections without some sort of config setup. So machines inside the network can SYN flood external targets. And now we are moving to QUIC so even stateful inspection is going to fail.
I have sat in multiple meetings with the FBI discussing network breaches by a state sponsored actor so that is my baseline for attack. Many of the DDoS attacks we see are using machines compromised in home networks as part of extortion schemes or to suppress speech. State actors fund the development of networks to perform the second and tolerate the first provided that it is directed at external targets.
It is futile to expect home networks to have an administrator, ergo, the systems must be 'secure by default'. The cat's litterbox does not need to saturate the network with SYN traffic. In fact, it doesn't actually need to do anything more than post status messages updating the cat's weight etc, alerting the staff to the need to empty it, etc. etc.
What we need is an architecture for IoT devices that allows them to plug into a home network without creating a security threat.
IETF has built some components that would be relevant to such an architecture, SDN for example. But there is no overall architectural model.
