Subject: Re: [dnsext] EDNS Page Option to handle large responses

From: Mark Andrews <[email-masked]>
Date: Tue, 16 Jun 2009 16:46:04 +1000

In message <C50A1B0C117F417D95BB61A88810C349@localhost>, "George Barwood" write
s:
> ----- Original Message ----- 
> From: "Mark Andrews" <[email-masked]>
> To: "George Barwood" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Tuesday, June 16, 2009 3:58 AM
> Subject: Re: [dnsext] EDNS Page Option to handle large responses 
> 
> > In message <DC49CF133C054F64BAAFFCB4C97D662E@localhost>, "George Barwood" write
> > s:
> >> EDNS responses larger than ~1500 bytes currently suffer from 2
> >> problems due to IP fragmentation : (1) They may fail to arrive due
> >> to IP implementation or equipment configuration issues.  (2) They
> >> are vulnerable to spoofing.
> >> 
> >> (1) means that practical resolvers are likely to be forced to
> >> implement a means of disabling DNSSEC, which is a security issue.
> >> There is also the issue of amplification attacks.
> >> 
> >> It seems that large responses are definitely needed, typically for
> >> fetching the dnskey rrset, for example
> >>   dig dnskey se @a.ns.se +dnssec
> >> currently has a response size of 3958 bytes.
> > 
> > Which is easily reduced to 1769 bytes and could be reduced
> > further with different key management / signing policies. 
> > e.g. I don't see the need to 3 ZSKs.
> 
> Ok, so we could warn operators that responses of larger than ~1500 bytes 
> to "normal" queries should be avoided if fallback to TCP is to be avoided.
> As Paul Vixie has observed, fallback to TCP is not a realistic solution
> for a busy zone ( or even any zone ).

TCP fallback is fine for 999.9999% of zones though it will almost
never happen for signed end zones even with a 512 byte EDNS buffer.
The root and other infrastructure zones have very different query
and response profiles to end user zones which make up the vast
majority of zones.
 
> I also doubt this is a robust solution. What if more than one algorithm needs 
> to be supported?

Realistically you will only ever need to sign with one algorithm
at a time.  The use of two algorithms will be rare and transitional
(e.g. from NSEC only to NSEC3 capable algorithms, or from SHA1 to
sha256 based algorithms).  You generally won't make such transitions
until the majority of validators support the algorithm you are
moving to or you need a feature that is only supported by a particular
algorithm.

> It feels like placing yourself in a strait-jacket, and I doubt
> that thousands of zone administrators can ever be educated to understand the 
> issues and adopt key management policies to stay witnin such confining limits.

2 KSK's and 2 ZSK's won't result in fragmentation.  99.999% of zones
don't need to use RFC 5011 as they will only publish in the parent
by the use of DS/DLV records.

One will just teach how to do DNSSEC using this maximum number of
keys and the world will follow.

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: Tue, 16 Jun 2009 19:21:55 +0000

> From: "George Barwood" <[email-masked]>
> Date: Tue, 16 Jun 2009 18:41:11 +0100
> ...
> In any sane system, achieving security against out-of-path attacks should
> take place in a layer that is precisely specified to achieve this goal,
> and is guarunteed to work.
> 
> The IP protocol is unfortunately not up to the job, ...

i think you mean "UDP/IP by itself is not up to the job", since every
solution we're discussing (including page option and sctp) uses IP.

> so to achieve security (that is security from blind out-of-path DoS
> attacks) I think you have do some work in an EDNS layer ( or some other
> layer on top of basic UDP ). This is what I am proposing.

much of the lossage that hurts EDNS today is because of middleboxes that
insist on UDP/53 payloads being smaller than 513 octets, or not having
additional data sections, or not containing nxdomain.  more edns options
won't help in those cases.  sadly, those middleboxes are now part of the
installed base, so our choices are ignore them and be blamed for failures,
or to work within their limitations.

if we're going to ignore these middleboxes then we can stick to edns as it
is, which depends on ip fragmentation, which leads to failures, for which
we are being blamed already.

or if we're going to ignore these middleboxes then we should ask for what
we really want, which looks more and more to me like SCTP.  (reasons posted
separately, with an actual proposal coming soon.)

if we're not going to ignore these boxes, we should just define an HTTPS XML
schema for DNS transactions, and hide in encrypted streams that middleboxes
are already forced by the fortune 500 to tolerate.

---

From: Michael Graff <[email-masked]>
Date: Tue, 16 Jun 2009 10:10:32 -0500

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

George Barwood wrote:

> All Zone administrators still need to be aware that oversize responses 
> are vulnerable to Dos attack ( by fragment and then the TCP fallback ).

How are servers today not vulnerable to a DDoS over TCP?  That is, what
does a large response size actually change for this risk?

- --Michael

---

From: Michael Graff <[email-masked]>
Date: Tue, 16 Jun 2009 10:10:32 -0500

- --Michael