Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop

[Havard Eidnes <[e-mail]>]

Hi,

I would like to pick up on section 2.2 in the draft, named
"Impact on Applications".  As far as I've seen so far in the
discussion, there has been almost no discussion of this part of
the draft.  I also find the analysis and explanation of the
issues faced by DNS in general and DNSSEC in particular to be
... somewhat weak.

>   DNS is one application that may be vulnerable when fragment
>   dropping occurs.

"Vulnerable" is not a word I would use in this context, since it
rings of "security issue".  "Affected" is perhaps a better word.

Secondly, who gets affected, and what is the effect?  That's not
mentioned, and it probably should be.

Even though EDNS0 and DNSSEC is mentioned in the draft, the
implications are not spelled out.  It may come as a surprise to
some that all currently supported versions of BIND and Unbound,
as well as all Windows name servers from 2008R2 onwards, all in
the role as recursive resolver by default send DNS queries with
EDNS0 buffer size set at around 4096 bytes *and* set the "send
DNSSEC information, if available" flag, *even if the recursive
resolver is not configured to do DNSSEC validation*.

In practice, this means that even if you don't use DNSSEC, unless
you take steps to prevent it, your recursive resolver will
increasingly need to be able to receive fragmented packets in order
to work satisfactorily.

>   The current choices open to the operators of DNS servers in
>   this situation are to defer deployment of DNSSEC, fragment
>   responses, or use TCP if there are cases where the rrset
>   would be expected to exceed the MTU.

This part of the draft is at best unclear.  If I'm an authoritative
name server, serving a zone which is DNSSEC signed, which results in
large (>1500 bytes) responses to a given query received over UDP,
where the querier asks for DNSSEC info and specifies a large buffer
size with EDNS0, I have no choice but to respond using UDP, and if
the resulting datagram is largish, I have to use fragmentation.  In
particular, the authoritative name server has no option to "use
TCP", that initiative has to come from the recursive resolver who
initiated the query in the first place.  The various recursive
resolver implementations have various different strategies for
dealing with situations where queries sent with DO=1 and EDNS0
bufsize=<large> doesn't make it back, among them dropping down the
bufsize, dropping EDNS0 (and DO=1) entirely, or resorting to TCP.
Meanwhile time is ticking away, since the recursive resolver
typically needs to experience multiple query timeouts before
engaging in alternative behaviour.

Who's affected by this?  Those using the recursive resolver who
happily announces that it wants large packets, but which has also
implemented non-initial fragment dropping in the infrastructure
around its recursive resolver.  "You make your bed, now you lie in
it." might be a valid response.

To my mind deferring DNSSEC deployment until each and every corner
on the Internet won't have issues with reception of fragments is a
total non-starter.  I predict that there will always be a fresh
supply of overly paranoid firewall administrators who insist on
breaking parts of the protocols, either through ignorance, fear, or
for other reasons.  If we wait until this supply dries up, we will
be waiting forever.

The draft goes on to say:

>   The use of fallback to TCP will impose a major resource and
>   performance hit and increases vulnerability to denial of service
>   attacks.

Here I will at least partially agree.  I think RIPE Labs recently
did a measurement which ended up indicating that a query over TCP
takes 2 to 3 times as long as a query over UDP to complete.  In
addition, TCP imposes increased state load on the publishing DNS
servers.  "Increased vulnerability to denial of service attacks" I'm
not so sure of.  It's always been a requirement that publishing DNS
name servers be reachable over TCP, so that should make it "the
same".  (Yes, I'll concede that this latter point is probably widely
ignored...)

So...

With the steadily increasing deployment of DNSSEC and with
fragmented UDP packets going with that, I think we should clearly
document to avoid problems caused by both running recursive
resolvers with the default configuration and at the same time
configure their infrastructure surrounding their recursive resolvers
to drop non-initial fragments, and that this advice is valid even if
they themselves don't use DNSSEC.  (Yes, that's an overly
complicated senctence, but I have to dash...)

Regards,

- Håvard