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

From: Patrik Fältström <[email-masked]>
Date: Tue, 16 Jun 2009 04:00:56 +0200

On 16 jun 2009, at 00.47, George Barwood wrote:

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

I must say that implementing application layer "features" to solve a  
problem when IP layer is not behaving properly (can not handle  
fragmentation) is a layering violation in the architecture. If we do  
have problems with fragmented packets not being reassembled, then I  
think we have other problems as well in our networks.

    Patrik

> (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.
>
> I therefore propose an EDNS Page option that allows large responses  
> to be sent in smaller IP packets.
>
> Requirements:
> (a) Should allow client to re-request specific packets that are lost.
> (b) Should allow server to limit size of response to a single query  
> ( to limit amplification attacks ).
> (c) Should be stateless.
>
> General idea:
> The response is divided into pages of equal size. Pages are numbered  
> 0,1,2,3....  The client request has a Page option to
> indicate support. If the response would otherwise be truncated  
> (including truncation of the additional section), the server
> responds with a copy of the question and a single OPT record  
> containing a Page option, and possibly other options ( e.g. Ping ).
>
> Client request option data:
> Page size (16 bits).  Page number (16 bits - zero for initial  
> request).
>
> Server response option data:
> Page size (16 bits). Page number (16 bits). Total response size (16  
> bits). Version number (32 bits). Page Data (variable length).
>
> Description:
> The page size is negotiated. The client initially indicates a  
> maximum page size (typically 1400 bytes, no less than 200 bytes).
> The server responds with either the requested page size, or a  
> smaller page size (no less than 200 bytes), and the data for the first
> page. The client then allocates a buffer for the whole response, and  
> sends a seperate request for each subsequent page, using the
> negotiated page size. The client will need to keep track of  
> outstanding requests, and repeat any requests that receive no response
> after a timeout period. The Version number sent by the server may  
> either be the Zone version (as in the SOA record),  or a number
> more specific to the query. If the response Version number or Page  
> size changes on subsequent pages, the client restarts the whole
> process, in order to obtain a consistent set of pages. When the  
> assembly process is complete, the client processes the complete
> assembled response in the normal way.
>
> If there is any indication of support, I am willing to submit this  
> as an ID.
>
> George Barwood
> --
> 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: Mark Andrews <[email-masked]>
Date: Tue, 16 Jun 2009 12:58:19 +1000

In message <DC49CF133C054F64BAAFFCB4C97D662E@localhost>, "George Barwood" write
s:
> 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.
> 
> implement a means of disabling DNSSEC, which is a security issue.
> There is also the issue of amplification attacks.
> 

	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.

; <<>> DiG 9.6.1 <<>> dnskey se +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16083
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;se.				IN	DNSKEY

;; ANSWER SECTION:
se.			3110	IN	DNSKEY	256 3 5 AwEAAcZN0OVaokJAtEiVGan/g3J3gOeYx7BCLTX1RuaWPHmPKROR7nfU a2Hc7Glpdtofk/uk5Aeiq9BKAAavke7Abr35cPXxOIdxdX65K4se1Iqe YpX+oW66xsn87WV89t1yPS67/nqFP5tcHnRnqA3lXGDlcfkjEsMQwY/M flQSVIkl
se.			3110	IN	DNSKEY	256 3 5 AwEAAc9B2MqxtXW/bQUYBV5zHf1z8e8MRSVWleDlQ3XZaOMlki4g4qdX hJ2rHN69ZzmvMj2DjTvLd8lMTN54NiHntofBIg0ZJ9pi0pcDemeeVQ7B h7T1OYzaM2rnId7xfSaoXBdX+6tMhkB/3CXM/cgqgar33emkhzdPUDdS 8FYNBGuL
se.			3110	IN	DNSKEY	257 3 5 AwEAAdKc1sGsbv5jjeJ141IxNSTdR+nbtFn+JKQpvFZETaY5iMutoyWH a+jCp0TBBAzB2trGHzdi7E55FFzbeG0r+G6SJbJ4DXYSpiiELPiu0i+j Pp3C3kNwiqpPpQHWaYDS9MTQMu/QZHR/sFPbUnsK30fuQbKKkKgnADms 0aXalYUuCgDyVMjdxRLz5yzLoaSO9m5ii5cI0dQNCjexvj9M4ec6woi6 +N8v1pOmQAQ9at5Fd8A6tAxZI8tdlEUnXYgNwb8eVZEWsgXtBhoyAru7 Tzw+F6ToYq6hmKhfsT+fIhFXsYso7L4nYUqTnM4VOZgNhcTv+qVQkHfO OeJKUkNB8Qc=
se.			3110	IN	DNSKEY	257 3 5 AwEAAeeGE5unuosN3c8tBcj1/q4TQEwzfNY0GK6kxMVZ1wcTkypSExLC BPMS0wWkrA1n7t5hcM86VD94L8oEd9jnHdjxreguOZYEBWkckajU0tBW wEPMoEwepknpB14la1wy3xR95PMt9zWceiqaYOLEujFAqe6F3tQ14lP6 FdFL9wyCflV06K1ww+gQxYRDo6h+Wejguvpeg33KRzFtlwvbF3AapH2G XCi4Ok2+PO2ckzfKoikIe9ZOXfrCbG9ml2iQrRNSM4q3zGhuly4NrF/t 9s9jakbWzd4PM1Q551XIEphRGyqcbA2JTU3/mcUVKfgrH7nxaPz5DoUB 7TKYyQgsTlc=
se.			3110	IN	DNSKEY	256 3 5 AwEAAa03g6eUym7QeFGEt0wx88nUcQmqnRRoUos95ICScmAgXimeiIhA pAOTWUrrybMyCOVgeFH8oovLoR8UR3YmScloECOU/EZQ4gLXGtL74HlO X8hw0HhlkOXNfSlxWZBTOOQn2Rf9yS3xWZ+ciLTqgj9SFxKr4n0AT6sy rWYFt4jJ
se.			3110	IN	RRSIG	DNSKEY 5 1 3600 20090620150322 20090613161805 19200 se. UhSsGzYoKJK+8slaT9Dml89T5wi5t0gpVJzumrbzEep1lmEt4zl18g2V Mqez0r7wUenNzyAh9H14fC+mCEDPT6sxJ98BE9fukDgsYr6XrQUJCUrR 7Ep4QwqGMlEyLo/YXew6mmckJ9PzCTMv/IAFg+S5zjYlXyzKZxljLNBl SSA=
se.			3110	IN	RRSIG	DNSKEY 5 1 3600 20090714000000 20090603082815 8779 se. I27BwrRsb8C35yXXk/flZGWdPTiVP5ROxoW2oQI/refXunge+hfrdsd+ y/1CyyaUxYgCDvCXGh684I9QZyczUET1gSAfuPxwR+6v1PzxNarNz25z YKfc+erRiSQMNb5flaFSdytpotnLaWfKkYfvTxgt+HSLfrsi2RmMhyDT 4PdqCrcHvYgIrYyUBfKkrQvE1WGBlhLHu3mgWUwEEaJC2n7W5IF7bk4Z c0JIV3F4/1f0fE4zbS/gW35Bf+cLQTH/jQgfhR7QI1Z+FlpC60PHEUBf 9jKovhOUxa5pV9xdLDbB8r28LFlbr2XW0oxc4ohHuhRI7npKEFH/oFvQ U+f29A==
se.			3110	IN	RRSIG	DNSKEY 5 1 3600 20090714000000 20090603082815 49678 se. WdATLxWZ7rBa13It4lH/v6vlL2UrdoMStxg4TC4x8e+otRQRBaaAHsmI DWh1cei9m2pAesgCqxYvsKmNvXw7WifBOamr8IV/82jJC593BAwVAQkD T05FhnfQ+i1LQZFUAz5s15dC7fee133qym0mjWNPEJStqE35cToCnl/R 2mGp8+juXcqE4Wm3DtYxqDIDaUqFmfXqvhL6w4nWw3tuBL8oC5kIjZ9k 4/ztzGjs27HwHofFAbJ4t6rglDaz0rpc+bcCWe1gvXExJ1rUWQBCxdYX FC3qfgWAw1ZRyIgTNL2yeHXofGmNmNtZ5HE8c2PCeq88KIJxTX8mFKUR mq6GXw==

;; Query time: 10 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Jun 16 12:54:45 2009
;; MSG SIZE  rcvd: 1769

> Requirements: (a) Should allow client to re-request specific packets
> that are lost.  (b) Should allow server to limit size of response
> to a single query ( to limit amplification attacks ).  (c) Should
> be stateless.
> 
> General idea: The response is divided into pages of equal size.
> Pages are numbered 0,1,2,3....  The client request has a Page option
> to indicate support. If the response would otherwise be truncated
> (including truncation of the additional section), the server responds
> with a copy of the question and a single OPT record containing a
> Page option, and possibly other options ( e.g. Ping ).
> 
> Client request option data: Page size (16 bits).  Page number (16
> bits - zero for initial request).
> 
> Server response option data: Page size (16 bits). Page number (16
> bits). Total response size (16 bits). Version number (32 bits).
> Page Data (variable length).
> 
> Description: The page size is negotiated. The client initially
> indicates a maximum page size (typically 1400 bytes, no less than
> 200 bytes).  The server responds with either the requested page
> size, or a smaller page size (no less than 200 bytes), and the data
> for the first page. The client then allocates a buffer for the whole
> response, and sends a seperate request for each subsequent page,
> using the negotiated page size. The client will need to keep track
> of outstanding requests, and repeat any requests that receive no
> response after a timeout period. The Version number sent by the
> server may either be the Zone version (as in the SOA record),  or
> a number more specific to the query. If the response Version number
> or Page size changes on subsequent pages, the client restarts the
> whole process, in order to obtain a consistent set of pages. When
> the assembly process is complete, the client processes the complete

-- 
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: Mark Andrews <[email-masked]>
Date: Tue, 16 Jun 2009 15:53:32 +1000

In message <2952105F69714941AA49EE6CA6EC1F02@localhost>, "George Barwood" writes:
> 
> ----- Original Message ----- From: "Patrik Fltstrm" <[email-masked]>
> To: "George Barwood" <[email-masked]> Cc:
> <[email-masked]> Sent: Tuesday, June 16, 2009 3:00 AM
> Subject: Re: [dnsext] EDNS Page Option to handle large responses
> 
> Yes. However doing nothing implies that DNSSEC can never be described
> as hardened or secure in my opinion.
> 
> Moving to something other than UDP is the other alternative, but
> that usually seems to involve servers retaining state information,
> which seems undesirable.
> 
> EDNS is a layering violation in any case, but if we are to have it,
> I think we need a layering violation that works :)

Why do you think EDNS is a layering violation?  All it signals is
that you can receive larger responses at the application layer.

EDNS works fine between end points that actually talk DNS.  It fails
when you add firewalls that think they know what the DNS protocol
is but are 10 years behind the time or you have firewalls that think
fragmentation should not occur or you have devices that pretend to
talk DNS but don't actually talk DNS.

There are also a few devices which fail to correctly re-assemble
packet or fail to correctly translate packets but they are rare.

Mark
-
Mark Andrews, ISC

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 16 Jun 2009 09:49:58 +0200

> as hardened or secure in my opinion.

Can you expand on this? Because of the fact fragments can be spoofed  
that you said in a different mail? Or because there are so many nodes  
deployed on the net that do not handle fragmentation correctly?

I.e. I try to understand whether you see this as a generic security  
problem, or a deployment problem.

> I think
> we need a layering violation that works :)

It might have been a layering violation to define that DNS packets  
should stay below 512 bytes, but given that is part of the DNS  
standard, there is not much we can do. And, EDNS0 is also, as we all  
know, a more generic extension mechanism and not only for size  
negotiations.

YMMV.

    Patrik

---

From: [email-masked]
Date: Tue, 16 Jun 2009 10:14:11 +0000

> talk DNS but don't actually talk DNS.

	this is where you have to ask yourself, why do you think
	it is wise to continue to accomodate such behaviours?

> Mark

--bill

---

From: Paul Vixie <[email-masked]>
Date: Tue, 16 Jun 2009 14:21:31 +0000

> From: "George Barwood" <[email-masked]>
> Date: Tue, 16 Jun 2009 06:11:02 +0100
> ...
> EDNS is a layering violation in any case, ...

please explain further?

---

From: Paul Vixie <[email-masked]>
Date: Tue, 16 Jun 2009 14:19:56 +0000

> From: Patrik Fältström <[email-masked]>
> Date: Tue, 16 Jun 2009 04:00:56 +0200
> 
> > 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.
> 
> fragmentation) is a layering violation in the architecture. If we do have
> problems with fragmented packets not being reassembled, then I think we
> have other problems as well in our networks.
> 
>    Patrik

agreed.  all forms of multipacket require that state be maintained, and as
a matter of architectural principle, multipacket state should be in the
network stack and not in the application.  (thus my recent interest in SCTP.)

(which is one reason why EDNS's original MD option bit was removed before
standardization.)

---

From: David Conrad <[email-masked]>
Date: Tue, 16 Jun 2009 08:17:35 -0700

On Jun 15, 2009, at 7:00 PM, Patrik Fältström wrote:
> fragmentation) is a layering violation in the architecture.

It just means that you (typically) need to replicate logic found in  
connection oriented transport protocols.  See (original) NFS for an  
example.  I guess you could call it a layering violation, but if so,  
allowing applications to choose between connection-oriented and  
connectionless would be the same sort of layering violation.

> If we do have problems with fragmented packets not being  
> reassembled, then I think we have other problems as well in our  
> networks.

?

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.37.5308
http://tools.ietf.org/html/draft-heffner-frag-harmful-05
The whole point behind RFC 1191
Etc.

Regards,
-drc

---

From: David Conrad <[email-masked]>
Date: Tue, 16 Jun 2009 08:36:52 -0700

On Jun 16, 2009, at 7:19 AM, Paul Vixie wrote:
> all forms of multipacket require that state be maintained, and as
> network stack and not in the application.

If the size of a 'normal' DNS response is going to result in  
fragmentation, we have four choices:

a) hope IP fragmentation works
b) fall back to TCP
c) implement multipacket state over UDP in the application
d) use a new protocol, e.g.:

> (thus my recent interest in SCTP.)

Historically, (a) has been problematic and is likely to remain so in  
the future (although maybe PMTUD will help).  Option (b) puts the  
burden on the server which doesn't scale particularly well, but has  
worked to date.  Option (c) properly done would put the burden on the  
application and would thus scale better, but would require additional  
complexity in the DNS and redeployment of all DNS servers.  Option (d)  
would probably scale well (depending on the protocol) and wouldn't  
likely add significant additional complexity to the DNS, but would not  
only require redeployment of all DNS servers, but also require the  
deployment of infrastructure capable of supporting the new protocol.

I suspect a better option is to not make the 'normal' DNS response  
require fragmentation.  Too bad we're going the opposite direction.

Regards,
-drc

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 16 Jun 2009 08:49:03 -0700

On Jun 16, 2009, at 7:19 AM, Paul Vixie wrote:

>>> problems

Unfortunately, the Internet is one giant layering violation in this  
respect.

We don't have final numbers (heck, we're still collecting data, let  
alone analyzing it), but the number of resolvers which can't handle an  
1800B DNS response even though they advertise EDNS support is  
shockingly large, as is the number of end hosts which can't directly  
request an 1800B DNS response.

For the purposes of DNS, you NEED a valid story that takes into  
account this issue, unless you view not working for a significant  
percentage of the Internet not a problem.

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 16 Jun 2009 09:33:41 -0700

On Jun 16, 2009, at 9:08 AM, Michael Graff wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Nicholas Weaver wrote:
>
>> shockingly
>> large, as is the number of end hosts which can't directly request an
>> 1800B DNS response.
>
> Careful there.  What specifically cannot handle it?  The resolver
> itself?  Or some device between it and the authority?

The test in question:

The response generated to edns_large. 
{anything}.netalyzr.icsi.berkeley.edu is ~1800B, padded by a number of  
irrelevant CNAMEs in the additional section (the CNAME block is  
actually located between the A records for the two listed  
"authorities").

It does not validate EDNS requested size, (but that is captured in  
another test), so it may exceed the advertised EDNS capacity of the  
server for this particular test.

The response is generated from a standard ethernet interface without  
jumbo frame enabled, so it is being fragmented by the sender.

Since the response padding is garbage, unrelated CNAMEs in the  
additional section, we would not except most recursive resolvers to  
include them in a response.

For the purposes of testing the user's resolver:

The path between ICSI and the user's recursive resolver, or the user's  
recursive resolver itself, is unable to either properly reassemble the  
fragmented response when it needs to, interpret the DNS response (but  
all others worked), or is unable to fragment further if the ethernet  
1500B MTU is too large.

For the purposes of testing the user's local connection:

The path between Amazon EC2 and the user's local connection, or the  
user's own computer, is unable to either properly reassemble the  
fragmented response when it needs to, an in-path device was unable to  
interpret the DNS response when it attempted (but was able to  
interpret a request for entropy.netalyzr...), or is unable to fragment  
further if the ethernet 1500 MTU is too large.

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 16 Jun 2009 10:01:22 -0700

On Jun 16, 2009, at 9:45 AM, Michael Graff wrote:

> So if someone advertises a 1000 byte packet size you still blast them
> with 1800, and are surprised they cannot handle it?
>
> I was more worried about your comments about the "resolvers cannot
> handle" which I found to be inaccurate.  Your test as stated means you
> are intentionally flooding them with more data and ignoring the EDNS
> advertised size, unless I misread what you said.
>
> Also, saying that the "resolver cannot handle" implies the resolver  
> code
> is broken, when I suspect it is often times a firewall external to the
> resolving software.  That is, "a resolver does not receive fragmented
> packets" is perhaps accurate, but "a resolver cannot handle" is  
> probably
> not.
>
> I'm not picking on you, just wanting to make clear where the problem  
> is,
> and if your tools can do that awesome.  I like what you've done so  
> far,
> and am glad that my home connection as rated as close to perfect as I
> can get it!

We do a second test where we check and capture what the advertised MTU  
size is, so we can exclude those cases where our response exceeds the  
advertised MTU size.

ONLY looking at those where we capture the advertised MTU as well  
(capturing the MTU requires the user to trust the applet), and the  
advertised MTU is >1900 bytes, the number of cases which fail to  
resolve this name is high.

We do NOT however check whether it does a successful fallback, redoing  
the request with a lower EDNS MTU and whether that succeeds: the point  
is to check whether the large ADVERTISED MTU can be used.

---

From: Florian Weimer <[email-masked]>
Date: Tue, 16 Jun 2009 20:24:03 +0200

* Paul Vixie:

> agreed.  all forms of multipacket require that state be maintained,
> and as a matter of architectural principle, multipacket state should
> be in the network stack and not in the application.  (thus my recent
> interest in SCTP.)

I think this is simply wrong, especially if you strive for resilience
against protocol-specific denial-of-service attacks.  If you hide
state in the stack, you lose control over it, and you end up with
resource exhaustion attacks.  I think this is the essence of your
dislike towards TCP (and admittedly, it's practically impossible to
work around that if all you've got is the BSD sockets API).
Unfortunately, SCTP is just more of the same.

By the way, cryptography enables the server to securely carry state
from packet to packet, keeping it in the client or in network buffers
(the latter similar to delay line memory).  The client only has to
pass back blobs it has received from the server.  There are probably
some web frameworks which use this to carry state.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 16 Jun 2009 19:00:16 +0000

> From: David Conrad <[email-masked]>
> Date: Tue, 16 Jun 2009 08:36:52 -0700
> 
> > all forms of multipacket require that state be maintained, and as a
> > matter of architectural principle, multipacket state should be in the

yes.

> Historically, (a) has been problematic and is likely to remain so in the
> future (although maybe PMTUD will help).  Option (b) puts the burden on
> the server which doesn't scale particularly well, but has worked to date.
> Option (c) properly done would put the burden on the application and
> would thus scale better, but would require additional complexity in the
> DNS and redeployment of all DNS servers.  Option (d) would probably scale
> well (depending on the protocol) and wouldn't likely add significant
> additional complexity to the DNS, but would not only require redeployment
> of all DNS servers, but also require the deployment of infrastructure
> capable of supporting the new protocol.

my reason for preferring to keep multipacket state in the network stack vs.
the application is that i've always been able to do a better job resisting
DDoS in the kernel, firewalls, routers, or upstream cleanerboxes, than by
delivering all traffic to the server and then context switching in user mode
(where capabilities like virtual memory and file systems are irrelevant.)

> require fragmentation.  Too bad we're going the opposite direction.

that's an argument for using smaller crypto.  people who know crypto tell me
that the bernstein curve is both good, fast, and cheap.  don't let dnscurve's
use of nameserver names as public keys and the fact that it protects links in
the path rather than the data itself, keep us from considering the elliptic
curve as a potentially better crypto algo for dnssec.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 16 Jun 2009 19:01:51 +0000

> From: Nicholas Weaver <[email-masked]>
> Date: Tue, 16 Jun 2009 08:49:03 -0700
> ...
> For the purposes of DNS, you NEED a valid story that takes into account
> this issue, unless you view not working for a significant percentage of
> the Internet not a problem.

that's an argument for doing all future protocol development over HTTPS.

---

From: Matthew Dempsky <[email-masked]>
Date: Tue, 16 Jun 2009 12:28:18 -0700

> curve as a potentially better crypto algo for dnssec.

There are at least two reasonable approaches DNSSEC could take to
reduce packet size:

  1. Use Rabin-Williams signatures like Adam Langley's rwb0fuz1024
proposal last fall: Rabin-Williams signatures can be verified faster
than RSA, signatures can be compressed to 1/2 size, and public keys
can be compressed to 1/3 size.

  2. Use elliptic curve signatures: public keys and signatures are
smaller still; verification time for a single signature is slower, but
batch verification of signatures can help to compensate for this.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 16 Jun 2009 19:38:12 +0000

> Date: Tue, 16 Jun 2009 19:14:03 +0100
> 
> Ok, from RFC 2671
...
> We are programming a distributed database, and suddenly we are faced with
> network/transport layer complications.

if that's what you're calling a layering violation, then i refer you to
RFC 1035 4.2.1, which is RFC 2671's spiritual father.  if either of those
is a layering violation, than both are.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 16 Jun 2009 19:42:05 +0000

> From: Florian Weimer <[email-masked]>
> 
> * Paul Vixie:
> resource exhaustion attacks.

as i explained elsewhere on this thread, keeping it in the stack gives
me a lot more options on how i handle ddos.

> I think this is the essence of your dislike towards TCP ...

no.  syn flood protection works.  i worry about TCP because of the speed
of light and the distance between nodes and the number of round trips and
the total time that state has to be maintained on both sides and because
of the way RFC 1035 specifie sthat connection management be done in the
application.

> ...  Unfortunately, SCTP is just more of the same.

sctp has only one of the weaknesses i know of in tcp/53.  i'll say more
in an actual proposal.

---

From: Matt Larson <[email-masked]>
Date: Tue, 16 Jun 2009 17:12:01 -0400

On Tue, 16 Jun 2009, Nicholas Weaver wrote:
> [Discussion of lack of large response size support deleted.]
>

Of all the TLDs signed to date, I would bet that .org is the most
popular, where popular is narrowly defined here as having the most
iterative resolvers query its name servers.  Now that .org is signed,
its responses have grown dramatically larger.  For example, a query
for www.<my-personal-domain>.org with +DO yields a 642-byte referral
(up from 149 bytes without DO).  Likewise, a query for
www.nxdomain2.org with +DO generates 1003 bytes in response vs. 109
bytes without DO.  The large response size situation with .gov is even
worse, considering that zone is using two 2048-bit RSA keys and NSEC3:
a +DO NXDOMAIN from .gov almost always tops 1500 bytes.

It has been several weeks since .org was signed (and even longer for
.gov) and the Internet has not melted.  That doesn't mean there aren't
pockets with issues, but we have not seen widespread problems
resulting from these significantly-larger responses.

I therefore maintain that if there were big problems, we would have
heard about them by now.  This makes me feel better about the root,
too: every day that goes by with more TLDs signed and no significant
problems makes me that less worried about significant damage when the
root is signed.

Matt

---

From: Mark Andrews <[email-masked]>
Date: Wed, 17 Jun 2009 09:57:12 +1000

In message <87F59E476ECB43B2B2E981D255B1E7F4@localhost>, "George Barwood" write
s:
> 
> ----- Original Message ----- 
> From: "Paul Vixie" <[email-masked]>
> To: <[email-masked]>
> Sent: Tuesday, June 16, 2009 3:21 PM
> <<
> 4.5. The sender's UDP payload size (which OPT stores in the RR CLASS
>      field) is the number of octets of the largest UDP payload that can
>      be reassembled and delivered in the sender's network stack.  Note
>      that path MTU, with or without fragmentation, may be smaller than
>      this.
> 
> 4.5.1. Note that a 512-octet UDP payload requires a 576-octet IP
>        reassembly buffer.  Choosing 1280 on an Ethernet connected
>        requestor would be reasonable.  The consequence of choosing too
>        large a value may be an ICMP message from an intermediate
>        gateway, or even a silent drop of the response message.

You ususally  get a ICMP from a intermediate when you set, or the
OS sets for you, DF.  I know of no nameserver that sets DF on its
UDP traffic.  We and I presume others try to ensure that it is
turned off if the OS defaults to turning it on.  The only OS were
we don't have that control and need it is Solaris and IPv4 UDP
traffic.

There may be some router out there which can't support link layer
MTU sized packets but they are extremely rare beasts.  I know of
no router that can't fragment a packet that they can fully receive.

You loose if you choose a size that you can't reassemble.  Most
boxes can re-assemble the packets we are talking about and if you
can't (think simple UDP stack in a embedded box) we shouldn't be
preventing DNSSEC being used by preventing fallback to EDNS@512.
Such boxes should be rare and the impact minimal.
 
> 4.5.2. Both requestors and responders are advised to take account of the
>        path's discovered MTU (if already known) when considering message
>        sizes.>>
> We are programming a distributed database, and suddenly we are
> faced with network/transport layer complications.

We have always looked at the underlying layers.  This is not new.
 
> Of course in DNS, because it uses UDP, there is considerable
> mixing of the various layers.

The DNS uses UDP when UDP's characteristics best fit the query
profile.  It uses TCP when the answer falls out of what UDP can
reasonably handle.

> But I don't want to get into theoretical arguments about
> software/network design.
> 
> We all know that for historical reasons DNS is a bit of a mess.
> 
> What's needed is to understand what exists, how it is insecure,
> and how it may practically be made secure and reliable.
> 
> George
> 
> > --

---

From: Michael Graff <[email-masked]>
Date: Tue, 16 Jun 2009 10:14:03 -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:

> Mark Andrews has argued that if client and server software is modified
> to avoid fragmentation, and administrators take care to stay within certain 
> limits, the existing specification allows secure operation. While that may
> be true, IMO security should not depend on how well educated administrators 
> are, or the software being written in a very particular way.

Actually, well educated administrators is one major security step
forward, and software being written in a very particular way is another.
 :)  Those are pretty much required for any security plan to work
meaningfully.  After all, if your admin write down passwords on post-it
notes and stick them to windows, what's the point?

- --Michael

---

From: Michael Graff <[email-masked]>
Date: Tue, 16 Jun 2009 11:45:54 -0500

Nicholas Weaver wrote:
>>> 1800B DNS response even though they advertise EDNS support is shockingly
..

Also, saying that the "resolver cannot handle" implies the resolver code
is broken, when I suspect it is often times a firewall external to the
resolving software.  That is, "a resolver does not receive fragmented
packets" is perhaps accurate, but "a resolver cannot handle" is probably
not.

I'm not picking on you, just wanting to make clear where the problem is,
and if your tools can do that awesome.  I like what you've done so far,
and am glad that my home connection as rated as close to perfect as I
can get it!

- --Michael

---

From: Michael Graff <[email-masked]>
Date: Tue, 16 Jun 2009 11:08:40 -0500

- --Michael

---

From: [email-masked]
Date: Wed, 17 Jun 2009 15:17:19 +0000

> packets" is perhaps accurate, but "a resolver cannot handle" is probably

	so - a question there abt the resolver behaviour.
	once it enters the fall back mode, does it do incremental
	fall back e.g.  4096, 2048, 1400, 512 or does it make one
	huge leap, e.g.   4096 - 512 directly?

	and under what condititions does it leave fall-back and 
	retry with "normal" buffsize?

--bill

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iEYEARECAAYFAko3zEIACgkQ+NNi0s9NRJ1ihQCfQpBOk8G/0kLsenhSRMDlAd1Z
> FM0AoIVjYgkCpXBYQCPjZPYHOb1I0+Xp
> =k9XY
> -----END PGP SIGNATURE-----
> 
> --

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 17 Jun 2009 17:43:27 +0200

> with 1800, and are surprised they cannot handle it?

I want us to be careful with words here. EDNS0 is not advertising  
packet size, but IP buffer reassembly size. I still do not understand  
what people are worried about, but can guess a few alternatives:

1. ICMPv6 packet-too-big is not generated, or filtered or something so  
that the sending host will not fragment the packets correctly

2. People do not think fragmented packets are handled correctly so UDP  
payload size have to be less than MTU size all the time

If you are worried about (1), then set MTU to 1280 in your DNS server,  
and it will fragment the packets.

If you are worried about (2), then announce 1280 in EDNS0 size.

What are we talking about? I hope we are not designing to as broken  
networks as (2), but I can understand (1) because many tunnel  
endpoints might not (today) do the right thing with ICMPv6, or ICMP is  
not handled correctly in firewalls etc.

    Patrik

---

From: David Conrad <[email-masked]>
Date: Wed, 17 Jun 2009 18:12:33 -0700

On Jun 16, 2009, at 2:12 PM, Matt Larson wrote:
> heard about them by now.

We (or at least I) have been surprised twice now, the DO=1, buffer  
size=512 thing and the recent TCP session spike after the signing  
of .ORG.  Both of those were not fatal, but I dislike surprises when  
it comes to critical Internet infrastructure.

> This makes me feel better about the root,

This topic is probably better addressed in DNSOP, but I will say that  
I continue to have concerns. The scope of the root zone is such that I  
am (perhaps overly) conservative when it comes to changes to that  
infrastructure. The fact that we have seen no significant damage as a  
result of signing some TLDs implying we will see no significant damage  
when we sign the root presupposes that the root is similar to those  
TLDs in all the ways that matter. I tend to agree that the lack of  
issues in signed TLDs is somewhat reassuring, but when you're dealing  
with infrastructure upon which national economies depend, I'd think  
we'd want to be sure rather than reassured.  I think it would be ...  
sub-optimal to sign the root, find out some non-trivial proportion of  
the Internet has issues, and as a result have to unsign the root.

(other bits about motherhood and apple pie deleted)

Regards,
-drc

---

From: Mark Andrews <[email-masked]>
Date: Thu, 18 Jun 2009 11:47:46 +1000

In message <[email-masked]>, David Conrad
> it comes to critical Internet infrastructure.

A jump in TCP traffic should always have been expected.  A look a
the EDNS query sizes even if you ignore those < 1024 would have shown
that there would be a jump in TCP traffic.

http://www.nanog.org/meetings/nanog46/presentations/Wednesday/wessels_light_N46.pdf

has relevant data to this debate.   ORG's TCP traffic levels are
much larger than they need to be as the had a ttl of zero on DNSKEY
reponses when this data was sampled.

---

From: David Conrad <[email-masked]>
Date: Wed, 17 Jun 2009 20:19:25 -0700

Mark,

On Jun 17, 2009, at 6:47 PM, Mark Andrews wrote:
> A jump in TCP traffic should always have been expected.

Yes, however a 600 fold increase is, at the very least, a bit  
surprising.

As I said, the issue isn't that stuff broke, rather that the  
unexpected happened.  The Internet isn't a toy anymore, it is critical  
infrastructure.  In my view, when mucking about with critical  
infrastructure, unexpected things are very bad.

Regards,
-drc

---

From: Florian Weimer <[email-masked]>
Date: Thu, 18 Jun 2009 12:58:02 +0200

* David Conrad:

> infrastructure.

The signed root can reside on different IP addresses (and names), so
that recursors can opt in gradually.  The operator only has to install
another hints file when the trust anchor is configured.  This has been
attempted before with DO, but perhaps this time, it's possible to do
it right.

No other zone has this option.  It might not be politically feasible
for the root, either---I don't know.

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: Mark Andrews <[email-masked]>
Date: Thu, 18 Jun 2009 22:12:06 +1000

In message <[email-masked]>, David Conrad
> Yes, however a 600 fold increase is, at the very least, a bit  

	With a little tuning it will come down a lot.

---

From: Florian Weimer <[email-masked]>
Date: Thu, 18 Jun 2009 17:18:31 +0200

> Yes, however a 600 fold increase is, at the very least, a bit

Uh-oh.  Has it decreased after the DNSKEY TTL fix?

---

From: Olafur Gudmundsson <[email-masked]>
Date: Thu, 18 Jun 2009 11:58:11 -0400

>Uh-oh.  Has it decreased after the DNSKEY TTL fix?

Will not help a lot, There are more negative answers than retries by 
validators to get DNSKEY RRset.
Minimum negative answer is 999 bytes. (qname = 3.org)
I.e. all the 512 and DO=1 queries for bad name will get truncated answer.

The only TLD where min buff size of 12xx will not help is .gov
their minimum negative answer is almost 1500 bytes.

         Olafur

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 18 Jun 2009 09:01:25 -0700

> Uh-oh.  Has it decreased after the DNSKEY TTL fix?

The other thing: this could be done not as a flag day, but roulette:

Start with 1% of the responses which request DNSSEC getting the signed  
response.  Ramp this up.  This would allow understanding what the  
impact is going to be, without having an oh-crap moment.

---

From: Florian Weimer <[email-masked]>
Date: Thu, 18 Jun 2009 18:07:37 +0200

> impact is going to be, without having an oh-crap moment.

I don't think it's possible anymore to publish inconsistently signed
production zones without ill effects.  Deliberately returning
inconsistent data certainly doesn't help with debugging.

(Perhaps you actually wanted to send this in reply to
<[email-masked]>?)

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 18 Jun 2009 09:17:29 -0700

> inconsistent data certainly doesn't help with debugging.

It could be deterministic based on IP.

The thing is, a lot of resolvers request DNSSEC information without  
USING it, and once the root is signed, it will still be a while before  
the resolvers actually are able to use this information.

Thus randomization is probably better than a flag day: you test how  
the resolvers are going to behave in a ramp-up fashion that can be  
rolled back, and you take advantage of the observation that >1/2 the  
recursive resolvers are asking for DNSSEC records, but on the initial  
rollout, most will be unable to use it anyway.

---

From: Florian Weimer <[email-masked]>
Date: Thu, 18 Jun 2009 18:21:50 +0200

> It could be deterministic based on IP.

Currently it's not necessary that you flush your cache if your egress
IP address changes. 8-/

> the resolvers actually are able to use this information.

There's a better solution for that, see my other message: use distinct
hints (with distinct names and addresses for the root servers).

This only works for the root, of course.  Something like DLVNS could
work for others (and DLVNS would also be handy for implementing
Leyen-type DNS policies).

---

From: Florian Weimer <[email-masked]>
Date: Thu, 18 Jun 2009 18:40:19 +0200

> I.e. all the 512 and DO=1 queries for bad name will get truncated answer.

If the answer size is < 1200 bytes, I don't expect the
DO=1/bufsize=512 fallback to trigger at all.

---

From: David Conrad <[email-masked]>
Date: Thu, 18 Jun 2009 12:01:06 -0700

Mark,

Regards,
-drc

---

From: David Conrad <[email-masked]>
Date: Thu, 18 Jun 2009 12:17:02 -0700

On Jun 18, 2009, at 9:21 AM, Florian Weimer wrote:
>> USING it,

Yep, around 5000 queries per second with DO=1 or about 60% at "L"  
currently (up from 40% a few months back).

>> and once the root is signed, it will still be a while before

This might actually be a positive.  If we have to revert back to  
unsigned because of the unexpected, anyone who had actually configured  
the root trust anchor will all of a sudden get validation failures.

> hints (with distinct names and addresses for the root servers).

+1

Regards,
-drc