Re: [DNSOP] Closing out issues in draft-ietf-dnsop-resolver-priming

[Paul Vixie <[e-mail]>]

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