Re: [DNSOP] Application level DNS message fragmentation

[David Dagon <[e-mail]>]

On Mon, Dec 08, 2014 at 02:02:12PM +0530, Mukund Sivaraman wrote:

> 3. An additional RR (plain DNS) or pseudo RR (inside OPT) called
> FRAGMENT is present in every datagram with 2 16-bit fields containing
> the count of fragments, and current fragment. (Though a DNS message is
> limited to 1<<16 octets and a DNS datagram can be at least 512 octets
> long, 16-bit fields are better for fragment count as the datagrams can
> be of different sizes.)

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.
     (I'd be curious what legitimate fragmentation problems require a
     large max-frag value?)

  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.
      
  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.
      
  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.

  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.

You might well dismiss all of these concerns as implementation details
for the recursives or small problems found in existing risks.  But I'd
be very curious to hear your thoughts.  

I'm particularly interested in learning the needs for legitimate
frag'd lookups, and the impact of a small cap on max-frag packets.

-- 
David Dagon
[e-mail]
D970 6D9E E500 E877 B1E3  D3F8 5937 48DC 0FDC E717