Subject: [dnsext] EDNS Page Option draft updated

From: "George Barwood" <[email-masked]>
Date: Tue, 18 Aug 2009 21:51:50 +0100

I have updated my internet draft :

Abstract

   Describes an EDNS option to allow large DNS responses to be sent
   using small UDP packets.

http://www.ietf.org/id/draft-barwood-dnsext-edns-page-option-01.txt

Summary of changes:

- Support for proxies that truncate at 512 bytes.
- Follow-up requests may be sent in parallel, so total response time is 2 x 
RTT.
- The MAC has gone.

As before, your comments are appreciated.
Regards,
George

---

From: "George Barwood" <[email-masked]>
Date: Thu, 20 Aug 2009 10:30:13 +0100

At the suggestion of Wouter Wijngaards, I have updated my draft again:

http://www.ietf.org/id/draft-barwood-dnsext-edns-page-option-02.txt

Changes:

Option for all pages to be sent immediately ( so response time is 1 x RTT ).
Cookie support optional.
UDP payload size is independent of EDNS UDP payload size.
Page size limited to 4095 bytes.
Reserved areas added.
Compatibility section added ( oops, just realised I forgot to update the 
index ).

Many thanks to those who have contributed, as always, your feedback is 
appreciated.

George

----- Original Message ----- 
From: "George Barwood" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, August 18, 2009 9:51 PM
Subject: [dnsext] EDNS Page Option draft updated

> - Follow-up requests may be sent in parallel, so total response time is 2 
> x RTT.
> - The MAC has gone.
>

---

From: Alex Bligh <[email-masked]>
Date: Thu, 20 Aug 2009 11:29:25 +0100

George,

> http://www.ietf.org/id/draft-barwood-dnsext-edns-page-option-02.txt

Three comments.

1. Please rename the "secret key" as a "nonce". It isn't a secret
   if it is sent in the clear. Equally, I think your security statement
   is overblowing the problem. As far as I can see, the risks are
   that if the client (a) does not use sufficient randomness in
   generating the nonce, or (b) the nonce is snooped upon, the client
   may end up with forged responses. If every response was a DNSSEC
   signed response, this wouldn't matter much except as a DoS vector.

2. The draft does not seem to define the data structure within the pages.
   I am taking it that the pages, if byte-wise concatenated, would form
   a single large DNS packet. My worry about this is that various
   middleboxes appear to silently pry into DNS packets and drop packets
   that are not in proper form (Nicholas Weaver and I discovered that
   Cisco IOS NAT does this even when DNS NAT is turned off). Hence you
   might find that packets containing pages other than the first get
   dropped, because they don't look like DNS packets.

   An alternative would be to make each page of variable size and
   look like a genuine answer to the original query, but containing
   a subset of the RRs that would be returned. The client would
   then concatenate all the RRs (eliminating duplicates if any).
   This would have more chance of passing through hostile middleboxes.

3. If "Send All Pages" is set by the client and respected by the
   server, why does the server need to generate a cookie? (i.e. why
   can't it set No Cookie).

4. I wonder if the "Send All Pages" bit falls between two stools. You
   say its implementation on the server is optional. However, when/how
   would the client know how to set it? At the very least, a server
   not supporting it should behave as if Send All Pages was set to zero
   (making it "Please Send All Pages" bit).

   But another way of doing this would simply be to make it *ALWAYS*
   send all pages, then delete all the stuff about the cookie and
   so forth; this is no less secure / DoS prone than the existing draft if
   "Send All Pages" is set and respected, but is far, far, far
   simpler.

   I can't help but think you are trying to solve several problems here:
   transmission of large responses, forged response attacks, and
   amplification attacks. If introduce SendAllPages as an option, you
   have already removed resistance to amplification attacks. Moreover,
   the very same amplification attack could be carried out simply by
   not specifying the EDNS Page Option, in which case the large packet
   would arrive as fragments. I would be tempted to drop this. If you had
   a very simple protocol whereby sending a single query (with a nonce)
   resulted in more than one UDP packet coming back filled with answers
   (possibly split bytewise, possibly by RR), I suspect the merits
   of simplicity would override the loss in functionality.

-- 
Alex Bligh

---

From: "George Barwood" <[email-masked]>
Date: Thu, 20 Aug 2009 13:20:55 +0100

----- Original Message ----- 
From: "Alex Bligh" <[email-masked]>
To: "George Barwood" <[email-masked]>; 
<[email-masked]>
Cc: "W.C.A. Wijngaards" <[email-masked]>; "Alex Bligh" 
<[email-masked]>
Sent: Thursday, August 20, 2009 11:29 AM
Subject: Re: [dnsext] EDNS Page Option draft updated

>   signed response, this wouldn't matter much except as a DoS vector.

It is secret, in that an attacker that can snoop or guess it can forge
responses. Of course this means that it only protects against out-of-path
attacks. These do matter - DNS is very vulnerable to spoofing,
as you say, for DNSSEC this can cause denial of service.

>   a single large DNS packet.

That's correct, I think the draft does describe it, by

" The client allocates an assembly buffer, and copies the Page data
   into it, at offset (Page number) x (Page Size)."

and

"When the client has received all of the pages, the complete assembled
 response is then processed normally."

but possibly I could improve this.

> My worry about this is that various

To be clear :  the response does have the normal DNS format, since the
data is carried in the EDNS option record. Existing servers sometimes
do not copy the question back (when there is an error), and in other 
respects,
the packet looks like a NoData response with an EDNS option.
The middlebox would have to inspect the EDNS Option record and reject
it for, say, having an unknown EDNS option. I don't think that's going
to be common at all, most middleboxes are quite dumb. On the other
hand proxies that truncate at 512 bytes are almost universal.

>   server, why does the server need to generate a cookie? (i.e. why

To allow lost packets to be retried without sending the whole response.

>   would the client know how to set it?

The client should not set it if there may be a proxy that doesn't understand
the EDNS Page option ( i.e. all proxies in practice ). Otherwise the client
should set it. Note that non-recursive requests are never proxied, so it
is always set in this case.

>   At the very least, a server

The bit is indeed a "Please Send All Pages" bit.

>   "Send All Pages" is set and respected, but is far, far, far

This doesn't work with proxies that truncate at 512 bytes, since they will
also not proxy multiple responses for a single request.

>   amplification attacks.

Yes, that's correct. You left other problems out, especially the proxies,
and fragmentation problems.

>  If introduce SendAllPages as an option, you
>  have already removed resistance to amplification attacks.

No, because servers don't have to honour it, provided they implement 
cookies.
A server under amplification attack will probably ignore SendAllPages = 1.

>   Moreover,
>   would arrive as fragments.

Servers that are under amplification attack may choose to not respond to 
queries
that don't have an EDNS Page option.

Best wishes,
George

>   I would be tempted to drop this. If you had

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 20 Aug 2009 05:35:48 -0700

>  This would have more chance of passing through hostile middleboxes.

Agreed: I think this is absolutely, 100%, totally essential.  IT may  
add one packet (which will hurt reliability), but there are far too  
many processes that will block "non DNS on port 53", which means it is  
essential that any user-level fragmentation produce fragments that are  
semantically DNS packets on their own.

Thats as if not more endemic than "Block fragments"

>  of simplicity would override the loss in functionality.

Agreed.  That describs what we need:  An application layer fragmented  
response which

a)  Each fragment still parses as valid DNS.  (fools middleboxes)

b)  All fragments are sent instantly.  (doesn't add latency, doesn't  
require state)

The amplification factor is low, the protocol is simple, but the  
utility is high.  The ONLY thing it might screw it up is some stupid  
statetful things which will go "the second response doesn't match the  
first, same transaction ID, different payload", but even THOSE devices  
could be fooled with a tweak where the sender recognizes that this  
happens and sends one request and a burst of pseudo-requests, with the  
fragments being responses to the pseudo-request.

---

From: Alex Bligh <[email-masked]>
Date: Thu, 20 Aug 2009 13:41:08 +0100

George,

> data is carried in the EDNS option record.

Yes, I'd totally missed that; that addresses the concern completely.
You could clarify by adding that the response to a followup request
is in the same format as 2.2, and that the format of the "page data"
is the complete response packet (presumably without the UDP headers) -
currently you just say it is "processed as normal".

I note this will break some NATs which rely on rewriting DNS A and PTR
records as they pass through the NAT, unless they are modified to
also do their rewrites within the EDNS page data. I also note that
(a) this might be considered an advantage of the proposal, and
(b) DNSSEC would break this behaviour too.

> To allow lost packets to be retried without sending the whole response.

Sure. That's why you may want to have a cookie. But why are you
preventing "No Cookie" from being set if the server wants to
(so it doesn't have to retain state at all, but can just send
all the packets at once).

> The client should not set it if there may be a proxy that doesn't
> understand the EDNS Page option ( i.e. all proxies in practice ).
> Otherwise the client should set it.

And the stub resolver client, presumably, needs to discover this somehow?

> also not proxy multiple responses for a single request.

Really? Have you tested that? I would have thought they might just
treat it as a retransmission. I appreciate they /might/ do this,
but then they might also strip unknown OPT RRs (e.g. in an attempt
to stop covert communication channels).

-- 
Alex Bligh

---

From: [email-masked]
Date: Thu, 20 Aug 2009 15:42:51 +0200

> to stop covert communication channels).

I'm not in a position to test this myself at the moment but IMHO it's 
extremely likely that any proxy style middlebox will barf on multiple 
responses received for the same request.

Whilst the proxies are generally pretty dumb, they often at least create 
their own transaction ID.  I would expect that any proxy as soon as it 
receives the (initial) response for any given request will immediately 
remove any local state associated with that particular transaction.

Ray

---

From: "George Barwood" <[email-masked]>
Date: Thu, 20 Aug 2009 15:13:05 +0100

----- Original Message ----- 
From: "Alex Bligh" <[email-masked]>
To: "George Barwood" <[email-masked]>; 
<[email-masked]>
Cc: "Alex Bligh" <[email-masked]>
Sent: Thursday, August 20, 2009 1:41 PM
Subject: Re: [dnsext] EDNS Page Option draft updated

[snip]

> And the stub resolver client, presumably, needs to discover this somehow?

It can do this by setting the bit, and then observing that only 1 packet is 
received,
even though the server has set All Pages Sent on a multi-page response.
After this has happened a few times, it's reasonable to conclude that there
is a proxy in path that will not pass multiple responses.

> Really? Have you tested that?

No, I haven't. But that is the natural way for a proxy to proceed, IMO.
Once it has got the response, why would it retain the state required to
forward a second response?

> I would have thought they might just treat it as a retransmission. I 
> appreciate they /might/ do this,

I hadn't considered that - it's possible, where the ISP is trying to stop
DNS tunnelling at a public access points.  But home and small business
users should be fine. I guess DNSSEC records can be used for tunnelling
in any case, so it would strip those as well, so DNSSEC is in that case
impossible I think.

George

---

From: Doug Otis <[email-masked]>
Date: Thu, 20 Aug 2009 15:07:17 -0700

> Option for all pages to be sent immediately ( so response time is 1 x RTT ).

This change _greatly_ increases network amplification risks!

> UDP payload size is independent of EDNS UDP payload size.

Perhaps this should be described as the Path MTU, since it is not 
describing a payload reassembly size, which can be noted independently.

> Page size limited to 4095 bytes.

Why not constrain the page size to fit within the Ethernet MTU?  This 
would limit this option to a maximum of 1460 or less.

Such limit would better retain Ethernet CRC error detection performance, 
where the IEEE CRC Hamming Distance for small packets drops from 7 to 3, 
(detects two bits in error instead of six).  The reduction in error 
detection performance occurs while greater amounts of data is being 
exchanged.  DNSSEC helps retrain data integrity, but not everything 
exchanged will have been signed.

As it is now, the maximum exchange this might cause would be
  255 x 4095 = 1,044,225.

If limited to 1460, the maximum would be
  255 x 1460 = 372,300.

A 50 byte query might then result in a 20,000 : 1 or 7,500 : 1 
amplification.

Perhaps the page number should be limited to 2 bits, instead of 8 with 
the payload limited to 1460.

-Doug

---

From: Matthew Dempsky <[email-masked]>
Date: Thu, 20 Aug 2009 15:48:32 -0700

> Option for all pages to be sent immediately ( so response time is 1 x RTT ).

Adding EDNS options like this stands in opposition to
draft-ietf-dnsext-dnsproxy-06, which currently recommends that DNS
proxies should copy OPT records blindly.  If a DNS proxy unaware of
the Page option blindly copies a request with the Send All Pages flag
set, it won't know to forward the subsequent response packets.

People have expressed concerns about the Send All Pages flag, but I
don't see anyone arguing a priori that EDNS options cannot alter the
response format this way.  If no one feels that way, then I think the
dnsproxy draft should be updated to require DNS proxies to strip
unknown option codes.

The EDNS RFC says EDNS options are defined for hop-to-hop purposes,
and I think it's a mistake to try to handwave a DNS proxy as not
counting as a hop.

The HTTP RFCs go to some effort distinguishing which header fields are
hop-to-hop versus client-to-origin, so that HTTP proxies and caches
know how to handle them.  I think it would be a good idea to
standardize a way for DNS proxies to know whether or not an
unrecognized option can be handled opaquely.

---

From: "George Barwood" <[email-masked]>
Date: Fri, 21 Aug 2009 08:22:51 +0100

----- Original Message ----- 
From: "Matthew Dempsky" <[email-masked]>
To: "George Barwood" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, August 20, 2009 11:48 PM
Subject: Re: [dnsext] EDNS Page Option draft updated

> dnsproxy draft should be updated to require DNS proxies to strip

Better I think would be to define a standard that allows the client
of a proxy to cleanly determine it's capabilities, instead of resorting
to trial and error. But that's a bit pie in the sky for me.

> The EDNS RFC says EDNS options are defined for hop-to-hop purposes,

Well yes, the wording is

"OPT RRs shall never be cached, forwarded,  or stored in or loaded from 
master files."

That actually seems rather unrealistic, given that all proxies do actually 
forward verbatim.

> and I think it's a mistake to try to handwave a DNS proxy as not

Maybe, but on the other hand this is what proxies do.

I think trying to establish a standard that is in opposition to a what is
currently deployed is likely to be futile.

I think the best thing would be to encourage proxies to limit the UDP
response size to the MTU, rather than 512 bytes. Some proxies already
do this, and it seems realistic. Besides, proxying DNS over TCP should
probably be deprecated, since that's clearly a hopeless thing to wish for,
even if it is the offical standard.

At any rate, I want to see a standard that allows DNSSEC to work
using the existing deployed middleboxes, simply by users installing
a validating stub resolver.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 21 Aug 2009 18:23:46 +1000

> even if it is the offical standard.

Proxying DNS over TCP is easier than UDP.  You don't have to do
anything at all to the data stream.  Once you have succeeded in
connecting to a upstream you just shuffle bits from one socket to
the other.  When either end closes you pass that on using shutdown(2).
When both sides have said they have no more to send you close(2)
the sockets.

> > unrecognized option can be handled opaquely.

The problem with proxies is that they don't actually pass the
responses they receive back.  If they did there would be almost no
problem.  If you are going to pass queries through verbatim you
need to pass the responses back verbatim.  The still won't help
with a request that generates multiple responses but we wouldn't
need such options if they did the right thing in the first place.

Mark

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

---

From: [email-masked]
Date: Fri, 21 Aug 2009 10:37:55 +0200

> proxies should copy OPT records blindly. 

That's not strictly true - what it does say that if you blindly copy the 
request you should be prepared to blindly copy the *whole* response.

Personally although I like the fact that sending all packets at once 
absolves the server of any need to keep state, it's fundamentally 
incompatible with the single-request -> single-response model used by DNS. 
 Proxies _do_ need to maintain state about any transactions going through 
them, hence going to a single-request -> multiple response model will 
inevitably break many things.

> If a DNS proxy unaware of

Indeed, although that's exactly what most current proxies would do.

> and I think it's a mistake to try to handwave a DNS proxy as not

The problem is that many of them behave as if they were transparent w.r.t. 
the request, but not to the response.
 
> unrecognized option can be handled opaquely.

It's not a bad idea, but there's no hope of it being implemented by 
middle-boxes whilst they're still ignoring everything I'm trying to get 
them to fix in draft-ietf-dnsext-dnsproxy.

Ray

---

From: "George Barwood" <[email-masked]>
Date: Fri, 21 Aug 2009 12:32:32 +0100

----- Original Message ----- 
From: [email-masked] 
To: Matthew Dempsky 
Cc: George Barwood ; [email-masked] ; [email-masked] 
Sent: Friday, August 21, 2009 9:37 AM
Subject: Re: [dnsext] EDNS Page Option draft updated

Ray > Personally although I like the fact that sending all packets at once absolves the server of any  need to keep state, it's fundamentally incompatible with the single-request -> single-response model used by DNS.  Proxies _do_ need to maintain state about any transactions going through them, hence going to a single-request -> multiple response model will inevitably break many things. 

It will break proxies ( that are unaware ), agreed.

But does it break anything else? What are the many things?

On server state : one simple model for authoritative servers is to support cookies most
of the time, but to turn them off during an update, e.g.

(1) Updates arrive
(2) Turn off cookies
(3) Wait 5 seconds ( or shorter time if no cookies issued recently )
(4) Do update
(5) Re-enable cookies ( cookie value increased, to catch any invalid cookies )

It's more difficult for caches, since updates are of course very frequent. 
I think the most practical solution there is to keep a list of response buffers. 
I don't think the rate of sending large responses should be very high, 
since DNSKEY RRsets should have long TTLs (hopefully), and 
other large responses (NXDOMAINs) should be infrequent. So should I think
it is entirely practical.

George

---

From: Matthew Dempsky <[email-masked]>
Date: Fri, 21 Aug 2009 15:26:04 -0700

> But does it break anything else? What are the many things?

I could imagine it breaking on firewalls that have to perform NAT.
E.g., if a firewall rule is setup to only allow one response packet
before discarding the NAT state.

On the other hand, such a setup is already a bad idea today because it
allows easier denial of service forgery attacks unless the NAT does
deeper packet inspection than just the UDP header.

---

From: Mark Andrews <[email-masked]>
Date: Sat, 22 Aug 2009 11:11:15 +1000

In message <74329874920E437B883BB0B23B38BD93@localhost>, "George Barwood" writes:
> Ray > Personally although I like the fact that sending all packets at
> once absolves the server of any  need to keep state, it's fundamentally
> incompatible with the single-request -> single-response model used by
> DNS.  Proxies _do_ need to maintain state about any transactions going
> through them, hence going to a single-request -> multiple response model
> will inevitably break many things.
> 

And you are designing this option to get DNS responses through
such proxies.

> But does it break anything else? What are the many things?

Since you are failing to meet the design goal it doesn't matter
if it breaks nothing else.
 
> it is entirely practical.

Again you are failing to think about why you are doing this in the
first place.  Large is > 512 bytes.  This just won't fly.

---

From: "George Barwood" <[email-masked]>
Date: Sun, 23 Aug 2009 06:36:47 +0100

( Reply follows some private correspondence between myself and Mark )

----- Original Message ----- 
From: "Mark Andrews" <[email-masked]>
To: "George Barwood" <[email-masked]>
Cc: "Matthew Dempsky" <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>
Sent: Saturday, August 22, 2009 2:11 AM
Subject: Re: [dnsext] EDNS Page Option draft updated

> And you are designing this option to get DNS responses through

Therefore "this option" (that is the "Send All Pages" option) cannot
be used when proxies are present, as described in the current draft.

It can normally be used for authoritative queries.

The exception is if there is a firewall which is stopping
multiple responses, either at the client or the server ( authoritative
queries are never proxied, AFAICS ).

I suspect this is very rare, but in such cases either the
firewall would need to be reconfigured, or the "Send All Pages"
option cannot be used. Provided cookies are implemented,
that's ok, it just implies latency of 2xRTT instead of 1xRTT.

If "Send All Pages" cannot be used due to a server firewall,
turning off cookies during updates as described below doesn't work.
Instead, during updates, the server could return SERVERFAIL
( i.e. "ask another server" ), or it could ignore the Page Option
( leading to fragmented UDP packets), or it could truncate the
response (leading to temporary TCP traffic ). Or of course
cookies can be implemented to work during updates, which
would be best.

..

Doug Otis has raised concerns about amplification attacks
on third parties using the "Send All Pages" option.
These could be hard for a server to notice if the
attacker is using a large number of authoritative servers
to conduct the attack. I plan to add a section roughly as follows:

(1) "Send All Pages" should not be honored for QTYPE=ANY.
(2) The NS RRset should not be sent when QTYPE=DNSKEY
( except in referrals of course ).
(3) Additional Section processing should be limited to so that
it does not contribute to the maximum response size.
(4) The minimum Page Size is 512 bytes.

This should mean that the amplification an attacker can
achieve (measured in packets) should not be more than ~4.

There is an inevitable compromise between seeking to
minimise latency, and mitigating amplification attacks.

George

---

From: "George Barwood" <[email-masked]>
Date: Sun, 23 Aug 2009 19:34:23 +0100

I have uploaded another revision

http://www.ietf.org/id/draft-barwood-dnsext-edns-page-option-03.txt

The protocol itself has not changed significantly.

Changes:

Spoofing of fragments added to introduction.
New section on amplification attacks in Security considerations.
Potential firewall problems addressed in compatibiulity section.
Packet formats described using the usual "boxes".
Various typos/nits fixed.

Thank you very much again for all your comments,
George

---

From: "George Barwood" <[email-masked]>
Date: Tue, 25 Aug 2009 13:12:16 +0100

And text added re downgrade attack in security section, and tidy up.

I finally figured the best URL to use seems to be

http://tools.ietf.org/html/draft-barwood-dnsext-edns-page-option

This appears to redirect to the latest version, and also has links to
to allow differences and old versions to be viewed.
Note: don't know what the "docs" link top left is meant to do,
but it seems to be bust, if anyone knows who to report this to.

George

---

From: Douglas Otis <[email-masked]>
Date: Tue, 25 Aug 2009 09:40:41 -0700

> http://tools.ietf.org/html/draft-barwood-dnsext-edns-page-option

This extension leaves congestion avoidance and network amplification 
considerations to the server.  As such, there should be strong 
recommendations to constrain these risks.  After all, this extension 
will otherwise increase network amplification above that of UDP jumbo 
frames.  This does not make the Internet safer.

The security consideration section does not consider the impact of there 
being no congestion avoidance with "Send All Pages" where there can be 
large responses (as big as 64KB) and, by using the recommended page size 
of 512B, 128 packets might be sent back to back.

The draft also indicates the server might refuse or partially refuse a 
request, but does not provide clear indications for the cause of the 
refusal.

Perhaps a 'P' flag for partial response (when something is omitted), and 
an 'R' flag for response refused.  When the response is refused, the 
cookie parameter and below could then contain extended error information.

-Doug