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

Yasuhiro Orange Morishita / 森下泰宏 yasuhiro at jprs.co.jp
Mon Sep 9 13:43:25 UTC 2013


Paul-san, and folks,

Now we (including me) have known the dangers and limitations,
so should we set max-udp-size to 1220 on every authoritative servers?

-- Orange

From: Paul Vixie <paul at redbarn.org>
Date: Mon, 09 Sep 2013 04:47:44 -0700

> 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



More information about the dns-operations mailing list