2 ms·

Do you hold that reasoning true every protocol, or is DNS somehow special? Should we immediately halt all work on securing BGP, for example, as misconfiguration

• tptacek 12y ago
  No, it's not true of every protocol. That's my point. Some protocols are well-situated to make security policy decisions, and some aren't. This is an obvious engineering point: however you secure BGP, you're going to have TCP delivering records. Should we then secure TCP, so that we can ensure availability and prevent attackers from exploiting it to introduce byzantine routing failures? And, if we create TCPSEC, some form of unencrypted IP traffic will be used to deliver those segments to end stations. Should we then secure IP? And then ARP? And then Ethernet headers? Secure BGP makes a lot of sense. BGP is already more of a policy expression framework than a routing protocol (the routing algorithms used by BGP are basic, and virtually all of the complexity comes from two decades worth of hacks designed to express policy). Fully every single router running defaultless BGP is managed by a team of people engaged intimately with BGP security policy. DNS, however, runs on every single Internet user's computer, often in different places, and at a layer that isn't fully exposed by APIs, because those APIs were designed with the assumption that DNS fails only due to connectivity failures. DNS is a terrible place to enforce policy.
  • xorcist 12y ago
    BGP _is_ a policy framework, and what you said was "In a sane design, a transient policy failure should produce a warning light or a browser popup; something that applications can use to sensibly convey what happened, in some form, to users.". That will, for obvious reasons, never be the case with BGP. Because it is far too low a layer. Hence my question.
    • yuhong 12y ago
      BGP's clients are mostly routers though, and routers are typically managed by professional admins who monitor for such failures.