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

[Haya Shulman]

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>wrote:

>
>
> Message: 6
> Date: Sun, 08 Sep 2013 17:30:57 +0900 (JST)
> From: Yasuhiro Orange Morishita / ????  <
> yasuhiro at jprs.co.jp>
> To: aaron at arbor.net
> Cc: dns-operations at mail.dns-oarc.net, edmonds at mycre.ws
> Subject: Re: [dns-operations] DNS Attack over UDP fragmentation
> Message-ID: <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.
>
>   RFC 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>
> Date: Sat, 7 Sep 2013 08:27:47 -0300
>
> > On 2013-09-06, at 1:42 PM, Robert Edmonds <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
> > 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
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>
>
> End of dns-operations Digest, Vol 92, Issue 13
> **********************************************
>



-- 
Best Regards,
S.H.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20130909/dd2bd26e/attachment.html>