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

Tue Sep 10 16:55:02 UTC 2013

Haya-san,

> Yasuhiro-san :-)

Please call me "Orange" frankly.  It's my nickname.

Just FYI and as you may know, Mark Andrews wrote the following I-D.
It's published the next day of your presentation at IETF saag
(and now updated to -01).

draft-andrews-6man-fragopt-01 -
IPv6 Stateless Fragmentation Identification Options
<http://tools.ietf.org/html/draft-andrews-6man-fragopt-01>

I think it is one of measures of the attack.  It adds the identication
on fragmented packet.  So, perhaps, you can refer it.

-- Orange

From: Haya Shulman <haya.shulman at gmail.com>
Date: Mon, 9 Sep 2013 14:30:49 +0300

> 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.