[dns-operations] dns-operations Digest, Vol 92, Issue 13

Mon Sep 9 11:47:44 UTC 2013

regrettably, the author of RFC 2671 knew the dangers and limitations of
fragmented IP, but specified it anyway.

see especially: http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-87-3.html

(where the authors of WRL-87-3 were two early mentors of the later
author of RFC 2671, who not only ought to have, but did, know better.)

vixie

re:

Haya Shulman wrote:
> Yasuhiro-san :-)
>
> Nice find, thanks for sharing!!
> I will add reference to it in our works.
>
> On Sun, Sep 8, 2013 at 3:00 PM,
> <dns-operations-request at lists.dns-oarc.net
> <mailto:dns-operations-request at lists.dns-oarc.net>> wrote:
>
>
>
>     Message: 6
>     Date: Sun, 08 Sep 2013 <tel:2013> 17:30:57 +0900 (JST)
>     From: Yasuhiro Orange Morishita / ????  <yasuhiro at jprs.co.jp
>     <mailto:yasuhiro at jprs.co.jp>>
>     To: aaron at arbor.net <mailto:aaron at arbor.net>
>     Cc: dns-operations at mail.dns-oarc.net
>     <mailto:dns-operations at mail.dns-oarc.net>, edmonds at mycre.ws
>     <mailto:edmonds at mycre.ws>
>     Subject: Re: [dns-operations] DNS Attack over UDP fragmentation
>     Message-ID: <20130908.173057.37558842.yasuhiro at jprs.co.jp
>     <mailto:20130908.173057.37558842.yasuhiro at jprs.co.jp>>
>     Content-Type: Text/Plain; charset=utf-8
>
>     Aaron-san, Haya-san, and folks,
>
>     I've found the following RFC, it's published in 2007 <tel:2007>.
>
>       RFC 4963 <tel:4963> - IPv4 Reassembly Errors at High Data Rates
>       <http://tools.ietf.org/html/rfc4963>
>
>     And I've cited "Security Considerations" of this RFC as below:
>
>     BTW, When the RFC was I-D, it's titled "IPv4 Fragmentation Considered
>     Very Harmful".
>
>       <http://tools.ietf.org/html/draft-heffner-frag-harmful-03>
>
>     So, we should have been discussing this issue before DNSSEC
>     deployment.
>
>     -- Orange
>
>     ---
>     7. Security Considerations
>
>        If a malicious entity knows that a pair of hosts are communicating
>        using a fragmented stream, it may be presented with an
>     opportunity to
>        corrupt the flow.  By sending "high" fragments (those with offset
>        greater than zero) with a forged source address, the attacker can
>        deliberately cause corruption as described above.  Exploiting this
>        vulnerability requires only knowledge of the source and destination
>        addresses of the flow, its protocol number, and fragment
>     boundaries.
>        It does not require knowledge of port or sequence numbers.
>
>        If the attacker has visibility of packets on the path, the attack
>        profile is similar to injecting full segments.  Using this attack
>        makes blind disruptions easier and might possibly be used to cause
>        degradation of service.  We believe only streams using IPv4
>        fragmentation are likely vulnerable.  Because of the nature of the
>        problems outlined in this document, the use of IPv4
>     fragmentation for
>        critical applications may not be advisable, regardless of security
>        concerns.
>     ---
>
>
>     From: Aaron Campbell <aaron at arbor.net <mailto:aaron at arbor.net>>
>     Date: Sat, 7 Sep 2013 <tel:2013> 08:27:47 -0300
>
>     > On 2013-09-06, at 1:42 PM, Robert Edmonds <edmonds at mycre.ws
>     <mailto:edmonds at mycre.ws>> wrote:
>     >
>     > > Aaron Campbell wrote:
>     > >> Here is a thought, but I will defer to the protocol experts
>     on plausibility.  The resolver knows the size of each DNS message
>     it parses.  What if it didn't trust glue records contained within
>     large (i.e., > 1400 bytes or so) responses?  In these cases, the
>     resolver sends a separate query to resolve the dangling authority
>     NS records.  This introduces overhead, but only for large replies.
>      It also makes a few assumptions, namely that the fragmentation
>     point is something around 1500 bytes (and not something lower),
>     and that the attack is only practical against the glue records,
>     not the authority section.  May be able to play games with name
>     compression there though? perhaps it is as least worth discussing
>     as an additional barrier.
>     > >
>     > > this sounds vaguely similar to unbound's
>     "harden-referral-path" option,
>     > > though it applies to all lookups.
>     >
>     >
>     > I researched this, and found that it was first described here:
>     >
>     >
>     http://tools.ietf.org/html/draft-wijngaards-dnsext-resolver-side-mitigation-01#section-3.3
>     >
>     > The option is currently marked "experimental" due to not being
>     RFC standard, and performance concerns.  If the option were
>     applied only to large responses (specifically to mitigate this
>     type of attack), that would reduce the performance impact.
>     >
>     > -Aaron
>     > _______________________________________________
>     > dns-operations mailing list
>     > dns-operations at lists.dns-oarc.net
>     <mailto:dns-operations at lists.dns-oarc.net>
>     > https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>     > dns-jobs mailing list
>     > https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
>     >
>
>     ------------------------------
>
>     _______________________________________________
>     dns-operations mailing list
>     dns-operations at lists.dns-oarc.net
>     <mailto:dns-operations at lists.dns-oarc.net>
>     https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>
>
>     End of dns-operations Digest, Vol 92, Issue 13
>     **********************************************
>
>
>
>
> -- 
> Best Regards,
> S.H.
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-jobs mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20130909/4a45e77b/attachment.html>