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
[email protected]
D970 6D9E E500 E877 B1E3 D3F8 5937 48DC 0FDC E717
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
