(removing w3, as my comments aren't related to the web) On Jul 17, 2024, at 10:57 PM, Bernard Aboba <bernard.ab...@gmail.com> wrote: > > In RFC 5505, the IAB took on this question, separating basic IP configuration > (which has in practice proved difficult to secure) from application-layer > configuration (which can be postponed until later in the boot process when > security facilities are available to secure it).
IIRC we had some discussions about this in 2016. Since then, there have been related issues popping up: - CVE-2024-3661, a local DHCP server can spoof routes and get VPN traffic to bypass the VPN. The underlying issue has been known for decades. Paul Wouters has strong opinions here. - https://www.akamai.com/blog/security-research/spoofing-dns-by-abusing-dhcp - DHCP can request DDNS updates, leading to unauthenticated arbitrary DNS record overwrite - in contrast to DHCP, DNS has been updated with DNS over TLS and DNS over HTTPS. - Despite RFC 5505 Section 2.4 explicitly mentioning the separation of EAP and network configuration, we have EAP / 802.1X configuring keys for Wi-Fi, or MacSec (wired), so the separation of issues is not quite as strict as 5505 would make it seem. All this means that when my machine wants network access, it uses the latest super-duper post-quantum crypto algorithms, certs with huge keys, the latest digest algorithms, secure encryption from me to the next hop, and then... Nothing. Everything after that is unauthenticated, unproven, and untrustworthy, My local machine has no idea if it can trust the DHCP server. It has no way of knowing that the local link has been secured. There is no way even for the machine to know if it's running in the local coffee shop, or in the secure corporate network. i.e. even if the machine does full 802.1X auth to the local network, and then uses MacSec, everything after that is not only insecure, but completely uninformed about any security, and is unrelated to any strong security processes. The outcome is then that my only choice is to treat the local networks as a swamp, and perhaps use IPSec for everything. Even for the corporate network. I understand why RFC 5505 _requires_ that local networks be simple, and use simple protocols. My concern is that it implicitly _forbids_ local networks from taking any extra steps to increase their security. I'm not proposing that the local network prove the security of every potential device / switch / router to each edge machine. I'm hoping that there's a secure way for the local network to say to tell an edge device what security posture it should use for the local network. In the absence of any trusted claim, the edge device should treat the local network as untrusted. But it's not clear to me why it wouldn't be possible (or even useful) for the local network to make certain security claims. The outcome of the current situation (as seen above) is that applications on edge devices have to be aware of the insecurity of lower-layer protocols, and to take steps to work around them. In some cases, there is no work-around (DHCP spoofing DDNS updates), and the only solution is "Yup, that's how it works. Live with it". As these recent attacks show, there is a need for increased security at the edge. The question I have is how we increase security, not whether we want increased security. Alan DeKok. _______________________________________________ Int-area mailing list -- int-area@ietf.org To unsubscribe send an email to int-area-le...@ietf.org
