PaulOn Friday, October 16, 2015 11:47:54 Hoffman wrote: > On 16 Oct 2015, at 11:30, Paul Vixie wrote: > > > i don't want tcp tried first, ever. i understand that tcp would be > > tried > > first, for new-fangled clients who want to try to negotiate persistent > > tcp. > > but that should not include the priming query, because root name > > servers are > > expected to have a large number of rdns servers to serve, and tcpcb's > > will > > always be finite. > > Are you arguing for a special case of "TCP to authoritative servers is > fine, but not for the root servers"? If so, that's an interesting > discussion for draft-ietf-dnsop-5966bis, which is still in WG Last Call.
no. as i wrote above, i just don't want tcp tried first for priming, no matter what tcp session persistency specifications may evolve separately. therefore the text in the current version of the draft is fine by me. > > >>> Given that using TCP for priming helps > >>> mitigate an injection attack, > > > > given that tcp is often blocked by firewalls since udp mostly just > > works and > > has always been tried first, i think that leaning on tcp to help with > > a > > priming injection attack has a low success likelihood. > > If a recursive resolver is behind a firewall that blocks TCP, the > priming query will time out and they will use UDP. well, sure. but there's no reason to risk that timeout. we know udp is going to work, and, we know we have to secure udp against insertion attacks using something other than source port randomization. dns cookies are a given, from the point of view that this priming rfc will live in. so there's no need for tcp in priming, and definitely no cause to risk a timeout or to create even a temporary state burden on the root name servers during priming. > > > let's get the injection > > attack solved in other ways, for example, using dns cookies. > > If you believe that the extra CPU required for a root server to support > https://tools.ietf.org/html/draft-ietf-dnsop-cookies-05 is less of a > threat to the operations of the root server than that of persistent TCP > connections, it would be great to see a write-up on that. i hadn't mentioned cpu load. i'm talking about state load. cpu is very easy to upgrade, whereas tcp state blob storage, not so easy. > The > intelligent use of state for TCP seems to be similar to that for > cookies, but comes with some major advantages. If rootops as a group > support cookies instead of TCP, that's valuable information, but we > haven't heard that yet. the rootops as a whole don't, and won't, take a position on matters of this sort. this would be a matter for the rssac caucus to discuss and address. (the rootops are members of the rssac caucus, along with a lot of other people.) -- Paul
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
