3 ms·
I don't see all of the criticisms for security, but there are some fair points. 0. Gating mechanisms should live at lower and higher levels in the stack. We ha
by 1letterunixname 3y ago
I don't see all of the criticisms for security, but there are some fair points.
0. Gating mechanisms should live at lower and higher levels in the stack. We have 801.1x for wifi/port security and TLS between client and server.
1. DHCPv4 (and conflation with BOOTP) is messy and doesn't have a trust model. There ought to be a mechanism to validate that the DHCP server authentic, its data is valid, and it's supposed to be there. (Rogue DHCP servers can be thwarted with participation by the network gear, but requires more engineering than client simply being able to ignore bogus DHCP servers. Networks still must police and shutdown rogue endpoints nonetheless.)
2. DHCPv6 (stateful -SLAAC, stateless +SLAAC, DHCPv6-PD), SLAAC, and M and O flags make it more painful to deploy than it ought to be.
3. DNS DNSSEC/DANE hasn't really caught on (yet?). DNS needs a top-down trust model or at least make it user-friendly enough (tools) to deploy.
4. EBGP security. (Let's not talk about that.)
In general:
i. Optional features don't get used.
ii. Complexity is a barrier to adoption and a source of security issues.
iii. Over-simplicity is another source of security issues and a source of lacking functionality.
- tptacek 3y agoOr, DNS doesn't need any security model at all, because the rest of the stack is designed to assume it's not secure, which is a model that has worked for the last 30 years.