Subject: Re: [dnsext] Support for EDSN0 PING

From: Mark Andrews <[email-masked]>
Date: Mon, 01 Jun 2009 10:57:46 +1000

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

In message <[email-masked]>, Paul Vixie writes:
> > From: Mark Andrews <[email-masked]>
> > Date: Mon, 01 Jun 2009 10:04:24 +1000
> > 
> > > >   * extended RCODEs (but I'm not sure about that)
> > 
> > 	extended RCODEs were badly done.  We should have had a basic
> > 	rcode which indicated that there was a extended rcode in the
> > 	OPT record.  Concatentating the bits was a bad idea.
> 
> agreed, but i don't think we'll see a change to this in EDNS1 (or ever.)
> 
> > > > What does not work:
> > > > 
> > > >   * the official fallback algorithm (section 5.3)
> > 
> > 	It actually works quite well 99.999% of the time.  It doesn't
> > 	work when you talk to non RFC 1034 compliant servers or you
> > 	have firewalls that interfere with DNS UDP messages.
> > 
> > 	To work around non-compliant servers and firewalls a second
> > 	fallback algorithm is needed to take into account timeouts.
> 
> maybe a BCP on this would be of general interest to the community?

Perhaps. There is still a open question of whether to fall all
the way back to plain DNS or not.

Fallling back from EDNS@UDP/4096 to EDNS@UDP/512 is relatively
uncontroversial and lets EDNS (and DNSSEC) work with firewalls which
block IP fragments or DNS UDP messages > 512 bytes.

There is still a open question of whether to fall back to plain DNS
or not on timeout as it breaks DNSSEC validation.  If you don't
fallback to plain DNS you break comunication through firewalls that
block all EDNS and you block communication to servers that fail to
respond to EDNS queries which I believe is non RFC 1034 compliant
behaviour.
 
> > > >   * large responses (interoperability problems, DoS amplification)
> > 
> > 	Moving to SCTP won't get rid of the DoS amplification problem
> > 	as we can never stop servicing UDP/53 queries.  BCP 38
> > 	deployment is the best way to stop DoS amplifications.
> 
> BCP38 is even less likely than universal switchover from UDP/53 to SCTP,
> so let's take a fresh look.  SCTP isn't spoofable in the way UDP/53 is,
> so the thing you can get DoS-amp'd with is SCTP setup packets, which are
> small and which could potentially be handled by a hardware front end far
> upstream of protection-worthy servers.
> 
> in other words SCTP is my hope for making secure robust reliable DNS
> connectivity possible for cooperating on-the-ball up-to-date operators,
> because otherwise we've just got UDP/53 (with or without EDNS) and
> TCP/53, neither of which can be made robust or reliable (ever, period).

I'm not objecting to SCTP.  Just the arguement that it will stop
DoS amplification.  It would require a deadline to be published and
enforced for when to cease using UDP for iterative queries.  I'm
assuming that DoS due to recursive queries can be mostly mitigated
via acls, tsig or other methods as I don't believe it is feasible
to replace all the stub resolvers in the next 20 years.  By 2038
we may be able to do it if we can link the replacement with Y2038
compliance.

Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Paul Vixie <[email-masked]>
Date: Mon, 01 Jun 2009 15:13:26 +0000

> Date: Mon, 01 Jun 2009 10:57:46 +1000
> ...
> Perhaps. There is still a open question of whether to fall all the way
> back to plain DNS or not.
> 
> There is still a open question of whether to fall back to plain DNS or
> not on timeout as it breaks DNSSEC validation.  If you don't fallback to
> plain DNS you break comunication through firewalls that block all EDNS
> and you block communication to servers that fail to respond to EDNS
> queries which I believe is non RFC 1034 compliant behaviour.

it is now long past time to address, dare i say close, these open
questions, and move on.  we need more deployment, and we need all of
the deployers to have all of the protocol intelligence that exists,
and so let's see the knowledge of the early/present deployers shared.

RFC2671bis is on the docket, let's add a whole section about fallback
experiences and recommendations, peer reviewed by this working group
so as to keep out whacky or creative or new ideas, and focus only on
what's been shown/known to work well.

> I'm not objecting to SCTP.  Just the arguement that it will stop DoS
> amplification.  It would require a deadline to be published and enforced
> for when to cease using UDP for iterative queries.  I'm assuming that DoS
> due to recursive queries can be mostly mitigated via acls, tsig or other
> methods as I don't believe it is feasible to replace all the stub
> resolvers in the next 20 years.  By 2038 we may be able to do it if we
> can link the replacement with Y2038 compliance.

what i expect will happen is that hardware-assisted forwarding boxes far
upstream of the nameservers will do UDP/53 ingress traffic shaping, like
"no more than 10K QPS per destination IP if it's UDP/53" and that a DoS
against this path will absolutely wipe out UDP/53 just as it does today;
however, cooperating up-to-date operators who have deployed SCTP will be
able to continue exchanging traffic with others who have done so.

SCTP can still be DoS'd, because internet links can still be DoS'd, and
there is no fix for a flood so strong it fills up the only links you've got
between you and everybody else.  but SCTP itself is less fragile than UDP,
and it ought to require a completely swamped link to keep it from working,
unlike UDP/53 or TCP/53 for which a perfectly effective DoS flow can be
created with far less than full link bandwidth.

so i'm not arguing that SCTP will stop DoS amplification, only that it will
raise the costs for attackers and provide more control points for defenders,
and that neither UDP/53 nor TCP/53 can offer anything similar to it, no
matter how we alter or improve EDNS.