Re: [DNSOP] Application level DNS message fragmentation

[Mukund Sivaraman <[e-mail]>]

Hi David

Thank you for reviewing the idea, and thinking of all these
scenarios. It's much appreciated. I've started writing a draft for this
proposal, and I'll address these items in it.

On Tue, Dec 09, 2014 at 02:26:06PM -0500, David Dagon wrote:
> This is an interesting idea. I tried to consider abuse of this
> approach, though perhaps that's unfair since you've not had the chance
> to fully describe things.
> 
> Here are scenarios you might consider:
> 
>   a) An attacker could create a zone that fragments into {1...N}
>      packets for common MTUs, and start sending them, slowly using a
>      crafted authority.  There's a small delay, e.g.,
>      $DEFAULT_TIMEOUT-1, between packets, to keep the slot open as
>      long as possible.  If I recall djb dnscache is at the low end
>      with 100 slots (though often adjusted upwards), BIND is 1000 or
>      so.  Resource exhaustion seems likely.  Cf. the recent
>      multi-vendor disclosures.
> 
>      In the ideal average case, authority responses would be "one and
>      done"---either an answer or timeout, absent other delegations and
>      requeries, etc.  Your proposal contemplates keeping more state,
>      longer.
> 
>      Perhaps this is a chore for the recursive implementations, since
>      a good idea should not be rejected because it might be poorly
>      executed.  For example, the recursive outbound queue might be a
>      priority heap, and new iterative chases evict state held for
>      app-frag'd packets, for which there's already partial zone
>      information.
> 
>      Nonetheless, I wonder if your proposal would consider a maximum
>      number of fragments (else, try TCP) because of these scenarios.

For various reasons (congestion, probability of loss, etc.), a limit on
number of fragments are necessary. We'll discuss this when reviewing the
draft.

On the topic of keeping state, a resolver would not be worser than in
the case of TCP where it needs to wait for data to arrive in individual
TCP segments and have the event loop keep the message-received-so-far
over mutiple reads. Timeouts for the UDP case could be handled similarly
by an implementation.

>      (I'd be curious what legitimate fragmentation problems require a
>      large max-frag value?)

For many regular queries that currently result in truncation, I suppose
they could be served by a very small multiple of fragments (mind forces
me to throw some random number such as less than 4, but it would depend
on the payload size being used).

>   b) Further, depending on the recursive, the port must be kept open
>      and not recycled with a new set of source ports, if that's the
>      recursive strategy for SPR.  Conceivably, one could induce
>      queries for FRAGMENT-crafted authorities, forcing the recursive
>      to a fixed set of of SPR values.
> 
>      This seems like a speculative attack, but I do wonder if, in the
>      simplest case, attackers could enjoy a longer Kaminsky attack
>      window, if they identify a zone that tends to frag, since the
>      qid/spr pair must be held for the Nth fragment.  The strongest
>      strategy would be to spoof the last frag packet, which
>      (presumably) would be sent last).
> 
>      Perhaps your protocol would therefore call for a randomized order
>      of the RRs being fragmented, to pose a hazard for guessing about
>      the Nth fragment.  (Duplicate RRs should not occur, but sometimes
>      do; perhaps you'd give treatment to this in your proposal.)
> 
>      I believe the right answer here is: DNSSEC solves this, rather
>      than adding more state in intermediate packets, which might not
>      always arrive.

The same source port would be used to receive replies for that query as
before. Other queries aren't required to use the same port (although in
implementation, they might for some time, if a socket pool is used for
performance reasons).

This does increase the chance of a Kaminsky style attack slightly, so
adding a nonce (some bits of random) somewhere in the request will be
necessary.

>   c) It strikes me that this would make a very high bandwidth
>      (asymmetric) covert channel application---large data transfers
>      from the authority, without the client's inconvenience of sending
>      upstream queries for each partial fragment.  
> 
>      Some attackers currently stuff virus binaries into zones, using
>      TXT records, so the "malware drop site" is in a reputable public
>      recursive cache with long TTLs---the malicious NS having long
>      since been "self remediated" to SERVFAIL or REFUSED.  (I have
>      some examples if you're curious.)
> 
>      This is not very common, perhaps because the book keeping for
>      this type of attack is complex---lots of state on the victim side
>      to get each fragment of the virus over TXT records, requeries for
>      drops, etc.
> 
>      Beyond this misuse, there is some appeal to streaming content
>      from an authority, e.g.:
> 
>        dig -t TXT hollywood-movie.example.com | awk '{...}' | mplayer
> 
>      assuming the fragments monotonically increase in order, etc.  No
>      need for a for loop and demuxing.
> 
>      Still, this is not a wise use of DNS.  I'd be interested in your
>      thoughts on a max-frag, if only to discourage channel abuse, and
>      "novelty use", and whether such a limit would affect legitimate
>      zones.

UDP protocols especially attract all sorts of attacks. A rogue server
can send a large number of replies even with current DNS over UDP for a
single query.

Limit on number of fragments will be suggested for several reasons, and
also behavior in these cases. Checks in client implementation will be
necessary (such as checks done now) on whether it can trust reply
datagrams.

There is also the case of amplification attacks.

>   d) Related to that, this might give DNS DDoSing another increase in
>      yield.  Perhaps this is not a significant problem because: (1) The
>      increase is small for the repeated headers, and (2) DNS DDoS'ers
>      often already have more than enough resources; and (3) the common
>      case would require the DDoS attacker to craft a zone that nicely
>      frags over common MTUs, creating an artifact for later
>      attribution.

I don't understand the attack described here; please can you explain it?

>   e) Minor mechanical question: What if the recursive witnessing
>      FRAGMENT packets decides to start in TCP before the balance of
>      the frag set arrives?  This seems like something a recursive
>      implementation would handle, and not your proposal.  It would be
>      useful to know what portion of TC=1 answers are seemingly
>      "ignored" by recursives.

I don't understand this clearly too.

For various reasons, it now seems that request for FRAGMENT would have
to be signalled by the client.

What a resolver wants to do at any time is its wish. It can send a UDP
request, and not wait for a reply before it starts TCP, dropping the
corresponding UDP replies. Through the (IP, port, message ID) tuple, it
can match a DNS query and its corresponding replies.

It can even start another UDP request for the same, but with a different
message ID.

		Mukund