[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