Subject: [dnsext] Working around proxies

From: "George Barwood" <[email-masked]>
Date: Tue, 25 Aug 2009 15:21:19 +0100

Has anyone considered a standard way to work around proxies that
prevent responses > 512 bytes being received?

I very tentatively suggest a new tld, say

localservers

could be defined. A query from a stub resolver to the proxy of

localservers A

would return the IP address of a fully functional local cache.

The idea being that it's not necessary to update the middlebox for this to work.

If this server failed, the query could be repeated to obtain an alternative.

Any good?

George

---

From: Mark Andrews <[email-masked]>
Date: Wed, 26 Aug 2009 10:40:07 +1000

In message <4CB0582F89044745BF1D1EBF09E549B6@localhost>, "George Barwood" write
> If this server failed, the query could be repeated to obtain an alternative.

If you are behind a firewall which blocks answers > 512 bytes there is
only one solution.  FIX THE FIREWALL.

If you are behind a NAT/firewall which drops IP fragments there is only
one solution.  Fix/replace the NAT/firewall.

If you are using a proxy which is unintentially breaking EDNS then
just stop using it.  There are lots of solutions already for this.
We don't need yet another one.

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

---

From: "George Barwood" <[email-masked]>
Date: Wed, 26 Aug 2009 02:37:03 +0100

> We don't need yet another one.

I'm not aware of any solution.

I know that my ISP's cache supports DNSSEC ( by sending a suitable query through the proxy ).

But I have no way of find it's IP address(es).

I don't want to use a remote open cache (for performance reasons), and using a local recursor is anti-social ( if everyone does 
this the load on TLD servers will increase considerably,
and my ISP might block the traffic in any case ).

I don't see why I or anyone else should be required to buy a new box simply because the DNSSEC standard has not foreseen this 
problem, which appears to be easy to fix. And even if I did buy a new box, the chances are it wouldn't help.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 25 Aug 2009 18:38:48 -0700

On 8/25/09 5:40 PM, Mark Andrews wrote:
>
> If you are behind a firewall which blocks answers >512 bytes there is

Jumbo frames themselves are fine, but after the source of a request has 
been confirmed.  Unfortunately, this is not how EDNS0 has been structured.

How does one prevent distributed UDP jumbo frame reflected attacks 
emitted from a range of authoritative DNS servers?  Is it really safe to 
promote the use of UDP jumbo frames, or will the Internet need 
protection from the malicious use of UDP jumbo frames?  With bot-nets, 
BCP38's protection is limited.

A small request returning a maximal response might produce upwards to an 
eighty to one network amplification.  This amplification also hides the 
source of an attack.  How would you view this problem?  This is not a 
problem solved by a Firewall, NAT, or Proxy.  Do you expect the Internet 
will also incorporate additional network and resource margins just to 
sustain potential abuse of EDNS0?

-Doug

---

From: Paul Vixie <[email-masked]>
Date: Wed, 26 Aug 2009 04:29:41 +0000

> From: "George Barwood" <[email-masked]>
> Date: Wed, 26 Aug 2009 02:37:03 +0100
> 
> ... and using a local recursor is anti-social ( if everyone does this the
> load on TLD servers will increase considerably, ...

bring it on.  we get way more queries from people who don't cache at all, or
from people who firewall our answers even though they fail to firewall their
own questions, then we would ever see from a change wherein every host on the
internet became its own caching recursive nameserver.  bring it on.  (really.)

---

From: Mark Andrews <[email-masked]>
Date: Wed, 26 Aug 2009 14:27:04 +1000

In message <A14FA9608EE94C8EA4543BA33510762B@localhost>, "George Barwood" write
> But I have no way of find it's IP address(es).

There is this thing called the phone if you can't look at the
diagnostics of your NAT to see what it is talking too.  The phone
is actually the best way to solve this if your ISP supplies the
offending CPE equipment.  They are in a much better position to
presure the CPE manufacturer to create a fix.
 
> I don't want to use a remote open cache (for performance reasons),
> and using a local recursor is anti-social ( if everyone does 

It's not anti-social.  No the load won't increase dramatically.  If
your ISP blocks the traffic get another ISP or forward the queries
to the ISP's servers.
 
> I don't see why I or anyone else should be required to buy a new box simply b
> ecause the DNSSEC standard has not foreseen this 

Buy a new box?  You can run a DNS server on just about anything.

If you are commenting on me saying replace the firewall then that
is the only solution.  Similarly NAT's which don't support fragments
when talking through them (not at them).  You won't be able to talk
to your ISP's servers if you don't fix the underlying problem.

There are somethings you and work around and others that you can't.

Mark

---

From: Mark Andrews <[email-masked]>
Date: Wed, 26 Aug 2009 14:38:33 +1000

> been confirmed.  Unfortunately, this is not how EDNS0 has been structured.

This is a IP problem, not a EDNS problem.
 
> BCP38's protection is limited.

A bot behind a link that is enforcing BCP38 can only directly attack
targets.  UDP jumbo frames are a non-issue as the replies can only
come back to the compromised machine.

> sustain potential abuse of EDNS0?

No.  I just expect ISP's to actually enforce BCP 38.  If they don't in
your jurisdiction talk to your local legislators.

---

From: "George Barwood" <[email-masked]>
Date: Wed, 26 Aug 2009 07:36:08 +0100

----- Original Message ----- 
From: "Mark Andrews" <[email-masked]>
To: "George Barwood" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, August 26, 2009 5:27 AM
Subject: Re: [dnsext] Working around proxies

> presure the CPE manufacturer to create a fix.

This is not a scalable solution. The idea that hundreds of millions
of consumers will update/upgrade these boxes to improve DNS security
is not going to work. I consider this completely unrealistic
and also unnecessary. These boxes are quite capable of routing
large DNS responses over UDP and TCP, as Ray Bellis has shown.

> Buy a new box?  You can run a DNS server on just about anything.

Problem with running a local recursor is that your non-DNSSEC traffic
becomes vulnerable, because port randomization may not work.

Well, as you probably know, I have a resolver that uses repetition
to overcome this, but it's not ( and probably never will be ) a
standard-conformant solution.

I don't think there are any servers that allow you to switch to
a forwarder for insecure zones ( this might be a useful feature though ).

> There are somethings you and work around and others that you can't.

Agreed. But this is something that is easily worked around, albeit
requiring standards action.

George

---

From: Mark Andrews <[email-masked]>
Date: Wed, 26 Aug 2009 17:49:29 +1000

In message <EEDE76D0B0164B97B9A6443EF7B3A1F5@localhost>, "George Barwood" write
> large DNS responses over UDP and TCP, as Ray Bellis has shown.

What's not scalable?  Looking at the NAT's diagnostics or ringing the ISP?
As far as I can tell they are both scaleable or you need a new ISP if
they can't answer their phones :-)
 
> >> problem, which appears to be easy to fix. And even if I did buy a new box,
>  th
> >> e chances are it wouldn't help.
> >

And that is not also a issue with stub resolvers talking to the
recursive server out on the net identified by your proposal?

---

From: "George Barwood" <[email-masked]>
Date: Wed, 26 Aug 2009 09:35:15 +0100

----- Original Message ----- 
From: "Mark Andrews" <[email-masked]>
To: "George Barwood" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, August 26, 2009 8:49 AM
Subject: Re: [dnsext] Working around proxies

> recursive server out on the net identified by your proposal?

It seems relatively hard to attack stub resolvers, although I haven't seen
much analysis on this.

Anyway, I only intended to raise the topic to see if anyone had
put much thought into it.

The thought experiment is "what if microsoft ship a recursive validating
cache with Windows 8" ?

What sort of TCP load does that create on the org servers?

I'm uneasy about abandoning ISP caches entirely, it seems like a retrograde step.

George

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 26 Aug 2009 05:21:29 -0700

> they can't answer their phones :-)

Do you wish to try explaining this to your mother?

Everything we do which touches end-users should pass the "Mother"  
test.  Can you explain, quickly and easily, how your mother should go  
about fixing/improving the problem?

---

From: "George Barwood" <[email-masked]>
Date: Wed, 26 Aug 2009 16:34:52 +0100

----- Original Message ----- 
From: "Nicholas Weaver" <[email-masked]>
To: "Mark Andrews" <[email-masked]>
Cc: "Nicholas Weaver" <[email-masked]>; "George Barwood" <[email-masked]>; <[email-masked]>
Sent: Wednesday, August 26, 2009 1:21 PM
Subject: Re: [dnsext] Working around proxies 

> about fixing/improving the problem?

+1

After further consideration, I think rather than a TLD, an EDNS option , quite similar to NSID (NSIP?) would be better.

It would return a type ( A or AAAA ) and the IP address the query was addressed to.

George

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 26 Aug 2009 08:37:53 -0700

On Aug 26, 2009, at 8:34 AM, George Barwood wrote:
> After further consideration, I think rather than a TLD, an EDNS  
> option , quite similar to NSID (NSIP?) would be better.
>

The address of the recursive resolver where the query comes from often  
does not equal the address where a query to the recursive resolver  
should be address to.

EG, for OpenDNS:  There are two addresses where recursive requests  
should be addressed TO, but >30 where queries to the authorities may  
come from.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 26 Aug 2009 12:23:25 -0700

On 8/25/09 9:38 PM, Mark Andrews wrote:
> In message<[email-masked]>, Douglas Otis writes:

Mark,

>> Jumbo frames themselves are fine, but after the source of a
>> request has been confirmed.  Unfortunately, this is not how EDNS0
>> has been structured.
>

Risks related to jumbo frames are fully dependent upon the protocol.
Protocols that establish connections or associations do not represent a
potential jumbo frame threat.  Jumbo frames represent a protocol
concern.  After all, 1,522 octets was (and is) the maximum Ethernet
tagged frame when UDP was established.

>> Is it really safe to promote the use of UDP jumbo frames, or will
>> the Internet need protection from the malicious use of UDP jumbo
>> frames?  With bot-nets, BCP38's protection is limited.
>

BCP38 restricts forged source IP addresses, but this does not protect
addresses within the source IP address filter CIDR, nor does it protect
from foreign networks that do not filter source IP addresses.  Since the
threat is reflective, three or more entities, networks, and regions
might be involved.  While good, BCP38 is not a complete solution.

>> Do you expect the Internet will also incorporate additional
>> network and resource margins just to sustain potential abuse of
>> EDNS0?
>
> No.  I just expect ISP's to actually enforce BCP 38.  If they don't
> in your jurisdiction talk to your local legislators.

Local legislators can not regulate foreign networks, or even thousands
of sources within local source egress filters.  Only protocols offer
comprehensive solutions.  As currently structured, abuse of EDNS0 may
allow attacks to be more severe.  Defending against attacks touches
everything, and represents a greater expense than what would be needed
to deploy safe protocols initially.

-Doug

---

From: Mark Andrews <[email-masked]>
Date: Thu, 27 Aug 2009 12:30:53 +1000

In message <[email-masked]>, Nicholas W
> about fixing/improving the problem?

We really don't need to fix this.  Truly.  Let natural attrition
take care of the existing bad boxes.  Let IPv6 deployment take care
of the existing bad boxes.  Most of them will be replaced within
the next 5 years due to the need to get IPv6 support.

There is no need to design a protocol to work around the current
crop of rubbish that is out there.  What we need to do is educate
the CPE and CGN developers that are currently working on the next
generation of products which support both IPv4 and IPv6 and make
sure they don't cut corners.

Mark

---

From: Mark Andrews <[email-masked]>
Date: Thu, 27 Aug 2009 12:53:26 +1000

In message <97E179C03BD54602B49D84BD7FDFBBFA@localhost>, "George Barwood" write
> It would return a type ( A or AAAA ) and the IP address the query

Which would then often be a NAT'd address because the ISP is running
a server farm for the cache.  This would require manual configuration
of the servers or more DPI in the NAT to reverse this.

This is work that does not need to be done and by the time the
client sides get deployed and the servers are upgraded, IPv6 will
be apon us and the boxes we are worried about will be being replaced.

Mark

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 26 Aug 2009 20:26:13 -0700

> sure they don't cut corners.

I wish I shared your optimism.

Right now, IPv6 adoption is pathetic.  Almost nobody is using it now,  
why would people use it later?

Rather, the lessons of the horribly painful digital cable transition  
the cable companies are going through to try to get more bandwidth  
makes me think that the ISPs will try to keep everyone on IPv4 as long  
as humanly possible, using carrier-grade NATs and similar devices to  
prevent address space exhaustion from becoming a problem.

Yes, they may begin to offer IPv6, but mostly as an option, not as a  
replacement, for the IPv4 service already present.

Look at it this way.  You are an ISP.  The cost of putting 1000  
customers behind a carrier grade NAT is what, $10K, so $10/customer.

The cost of providing/forcing a new NAT/AP device for every customer,  
including the cost of the service calls you will get trying to get  
someone like my great aunt to switch out to a new Linksys, is going to  
be an order of magnitude more per customer.

I don't think we should design protocols to specifically avoid the  
crap, but we should design the software to deal with it, and accept  
that the crap will still be here tomorrow.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 27 Aug 2009 13:44:43 +1000

> why would people use it later?

People wait to the last minute, so what? 

> prevent address space exhaustion from becoming a problem.

CGN requires CPE upgrades.  The traffic is carried over IPv6 between
the CPE and the CGN box operated by the ISP.

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 27 Aug 2009 14:28:22 +0900

> People wait to the last minute, so what? 

And being rescued.

> the CPE and the CGN box operated by the ISP.

It means most ISPs simply use legacy NAT.

Or, see draft-ohta-e2e-nat-00.txt. End to end NAT can be upper
compatible to legacy NAT box (perhaps as COE) and, if end hosts
are upgraded, offer complete end to end transparency without any
IPv6 tunneling.

A+P does not need IPv6 tunneling, either, though it also involves
COE upgrading (if COE does not already have port based routing
capability).

						Masataka Ohta

---

From: "George Barwood" <[email-masked]>
Date: Thu, 27 Aug 2009 08:42:02 +0100

----- Original Message ----- 
From: "Mark Andrews" <[email-masked]>
To: "George Barwood" <[email-masked]>
Cc: "Nicholas Weaver" <[email-masked]>; <[email-masked]>
Sent: Thursday, August 27, 2009 3:53 AM
Subject: Re: [dnsext] Working around proxies 

> of the servers or more DPI in the NAT to reverse this.

Agreed. But it's easier to have a relatively small number of ISPs doing some
configuration than millions of grannies.
 
> be apon us and the boxes we are worried about will be being replaced.

That may well be the case, but a NSIP option allows early adopter ISPs
to move forward without waiting for IPv6.

It may be 20 - 30 years before all the old boxes are retired.

Nobody knows.

It shopuld be viewed as a way of working around a problem with existing
equipment. ISPs are not required to deploy it ( in the same way that they are
not required to deploy DNSSEC caches ).

George

---

From: Doug Barton <[email-masked]>
Date: Sat, 29 Aug 2009 13:05:41 -0700

> I very tentatively suggest a new tld, say

For my money, anything involving a new TLD is a non-starter, but read on.

> would return the IP address of a fully functional local cache.

This sounds like an ideal use case for multicast DNS.

Doug

---

From: "George Barwood" <[email-masked]>
Date: Sun, 30 Aug 2009 05:16:41 +0100

----- Original Message ----- 
From: "Doug Barton" <[email-masked]>
To: "George Barwood" <[email-masked]>
Cc: <[email-masked]>
Sent: Saturday, August 29, 2009 9:05 PM
Subject: Re: [dnsext] Working around proxies

> For my money, anything involving a new TLD is a non-starter, but read on.

I'd be interested in reasons why you think a new TLD is a non-starter,
although I now think an EDNS option is probably a more suitable solution.
 
> This sounds like an ideal use case for multicast DNS.

Please explain : I don't see how multicast DNS can help here,
but maybe I'm missing something.

George

---

From: Doug Barton <[email-masked]>
Date: Sun, 30 Aug 2009 11:24:15 -0700

> I'd be interested in reasons why you think a new TLD is a non-starter,

There are only 2 ways to "get" a new TLD for this purpose. The first
is to go through the ICANN new TLD process. The complexity of this,
even if we could get ICANN to waive the fees associated, are daunting
to say the least, would take a very long time to complete, and it's
not likely to be approved in any case. The other way is for "us" to
appropriate one, either by starting to use it (ala .lan or .local)
which would be very bad manners; or by attempting some sort of IETF
process to "justify" it's use, which would lead to a turf war with
ICANN that there is no reason for.

Of course, I also think that your suggestion is a truly horrible idea,
so my opinion on all of the above may be biased, but I doubt it.

> but maybe I'm missing something.

Well then I guess my next question is, "How much do you know about
mDNS and how it operates?" A simple response to your question would be
that the end-user/client box that needs to know the addresses for its
local resolvers broadcasts the query, and the mDNS process(es) running
on the local resolver(s) sends out a response that says "Here I am!"

There is no need to create new functionality that would actually be
much more limited than the existing solution that mDNS already
provides. And to save you a response, yes, I realize that my solution
to the problem you're describing involves admins setting up something
new. But that's still a lot less person-hours than trying to redefine
the protocol in the way you describe, even if I thought you had a
valid problem statement which I don't think you do.

Additionally, you seem to be proposing a world in which there are none
of the other usual mechanisms for this like DHCP, although for the
life of me I can't figure out why.

Doug

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 31 Aug 2009 06:58:49 +0900

> on the local resolver(s) sends out a response that says "Here I am!"

If you are not talking about link local multicast (you should not,
because local resolvers are often located somewhere beyond local
routers), multicast routing requires a lot of configuration, which
is a lot more complex than DNS configuration, that mDNS is no
solution.

For example, if you use PIM-SM, you have to configure information
on an unicast address of rendez-vous point corresponding to a
multicast address.

In general it is a broken idea to use multicast for autoconfiguration.

Having a globally unique anycast addresses for default local resolvers
is a better solution.

							Masataka Ohta

---

From: Alex Bligh <[email-masked]>
Date: Mon, 31 Aug 2009 00:00:22 +0100

> ICANN that there is no reason for.

Technically speaking, a 3rd way to do an equivalent thing would be
a subdomain of .arpa. I am not suggesting this is necessarily
a good idea.

-- 
Alex Bligh

---

From: Mark Andrews <[email-masked]>
Date: Mon, 31 Aug 2009 11:53:30 +1000

> a subdomain of .arpa. I am not suggesting this is necessarily

The whole idea is bad.  You don't design protocol extension to work
around devices which are breaking the protocol.  You fix/replace
the broken devices.

If the working group wants to be productive the members should look
at the devices they have access to and publish which ones work
correctly and to what extent and which ones don't.  This will allow
consumers to buy boxes which work.  The report should include
hardware and firmware revision numbers so that manufactures can
reproduce the reported problems if desired.

Working should include those that will work after a firmware upgrade
along with the firmware revision required.

We should encourage manufactures to report products that they believe
work correctly.

Ray's report would be a useful starting point, if that is allowable.
Ray do you have the necessary details on the boxes you tested?

Mark

---

From: "George Barwood" <[email-masked]>
Date: Mon, 31 Aug 2009 07:21:26 +0100

----- Original Message ----- 
From: "Mark Andrews" <[email-masked]>
To: "Alex Bligh" <[email-masked]>
Cc: "Doug Barton" <[email-masked]>; "George Barwood" <[email-masked]>; <[email-masked]>
Sent: Monday, August 31, 2009 2:53 AM
Subject: Re: [dnsext] Working around proxies 

> around devices which are breaking the protocol.  You fix/replace

The devices are NOT broken. The protocol should have been designed
to be compatible with the existing installed base. I'm simply proposing
to fix the protocol, which is what is really broken.
 
> Ray do you have the necessary details on the boxes you tested?

This is wrong in principle. I am totally opposed to this approach.
It will also I predict be wholly futile.
You concept of the typical internet user is wholly at variance with reality.
They will never be able to configure these boxes, or install updates.
Nor should they have to, simply due to a badly designed protocol.

George

---

From: Alex Bligh <[email-masked]>
Date: Mon, 31 Aug 2009 08:57:58 +0100

--On 31 August 2009 07:21:26 +0100 George Barwood 
<[email-masked]> wrote:

> The devices are NOT broken

Sorry? Please explain how, for instance, a device that truncates and then
passes on an answer is not broken. Or a device that advertises a large
EDNS0 reply size but can't reassemble the UDP fragments necessary to
transmit it.

-- 
Alex Bligh

---

From: "George Barwood" <[email-masked]>
Date: Mon, 31 Aug 2009 09:25:55 +0100

----- Original Message ----- 
From: "Alex Bligh" <[email-masked]>
To: "George Barwood" <[email-masked]>; "Mark Andrews" <[email-masked]>
Cc: "Doug Barton" <[email-masked]>; <[email-masked]>; "Alex Bligh" <[email-masked]>
Sent: Monday, August 31, 2009 8:57 AM
Subject: Re: [dnsext] Working around proxies 

> EDNS0 reply size but can't reassemble the UDP fragments necessary to

The devices are fully compatible with the existing DNS standard, by which
I mean the widely deployed standard defined by RFC 1034 / RFC 1035.

Protocol extensions ( such as DNSSEC/EDNS ) must be designed to be fully
compatible with the earlier standard so that they may be easily deployed.

DNSSEC/EDNS is broken in this repect. EDNS is also anti-social in that it
enables denial of service attacks on third parties ( this is a seperate issue,
that should IMO also be fixed ).

George

---

From: Florian Weimer <[email-masked]>
Date: Mon, 31 Aug 2009 09:25:39 +0000

> The idea being that it's not necessary to update the middlebox for

You should use a different UDP if you want to bypass protocol-aware
middleboxes.

-- 
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: Mon, 31 Aug 2009 22:22:33 +1000

In message <1009805BA49B4D22BAD2E408B06FA87B@localhost>, "George Barwood" write
> to fix the protocol, which is what is really broken.

What installed base?  Consumer ADSL, wireless and cable data were
fledgling/non existant markets when EDNS was designed.  The world
was still mainly dialup to a single home PC.  A lot has happened
in the last decade.  Almost all, if not all, of the products that
are causing us problems now were designed after EDNS0 was published.

Please tell me which products we where supposed to have designed
for that had DNS proxies (just copied the QUERY) in them in the
1998/1999 time frame?

A recursive server was defined to be a piece of software that
generated its own iterative queries then put together a answer based
on what it had received.  There were recursive servers that made
made recursive queries to other recursive servers but they still
constructed their own queries.

We had forwarding of UPDATE packets defined.  TSIG in 2000 took the
changed qid into account.  UPDATE packets are also sent direct to
authoritative servers for the zone.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 31 Aug 2009 12:36:24 +0000

> Date: Mon, 31 Aug 2009 07:21:26 +0100
> 
> [Mark Andrews]
> > around devices which are breaking the protocol.  You fix/replace the
> > broken devices.
> 
> The devices are NOT broken. The protocol should have been designed to be
> compatible with the existing installed base. I'm simply proposing to fix
> the protocol, which is what is really broken.

by that reasoning, which is wrong, microsoft should not have implemented
AXFR with more than one answer per message, since BIND did not tolerate it.
fortunately, everyone knew that BIND was being stupid, so we fixed the
installed base and apologized to microsoft.

i agree with mark that the installed base is wrong.  i don't know if it can
be fixed, mind you.  the reason EDNS should probably not have depended upon
ip fragmentation is that mogul and kent explained why ip fragmentation was
a bad idea (google for WRL-87-3 to see the tech report) not because of the
installed base.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 31 Aug 2009 12:50:07 +0000

> Date: Mon, 31 Aug 2009 09:25:55 +0100
> 
> > ... Please explain how, for instance, a device that truncates and then

middleboxes have a higher standard than "do no harm".  the robustness
principle as applied to middleboxes would be expressed as "be liberal in
what you pass through and be conservative in what you interfere with."

to be compatible with the philosophy which underlaid RFC 1034 / RFC 1035,
middleboxes would have had to pass through any UDP/53 or TCP/53 which
appeared to them to be a format error.  that's clearly not happening.

> compatible with the earlier standard so that they may be easily deployed.

this is wrong.  by this reasoning, which is wrong, an IP router would be
free to drop all packets whose protocol type wasn't either ICMP, UDP or
TCP, if those were the only protocol types that showed up in the test lab.

the design-level conservatism you are asking for here might be appropriate
for product design, but not open systems protocol design.  here, we imagine
a sort of virtual installed base, existing only in our minds / the future.

---

From: "George Barwood" <[email-masked]>
Date: Mon, 31 Aug 2009 14:06:01 +0100

----- Original Message ----- 
From: "Mark Andrews" <[email-masked]>
To: "George Barwood" <[email-masked]>
Cc: "Alex Bligh" <[email-masked]>; "Doug Barton" <[email-masked]>; <[email-masked]>
Sent: Monday, August 31, 2009 1:22 PM
Subject: Re: [dnsext] Working around proxies 

> are causing us problems now were designed after EDNS0 was published.

Well that may well be the case, but of course no one takes much account
of standards that are not widely deployed, and that has been the case.

Regardless of the blame for the current mess, here we are, and a
realistic way forward is needed.

I think updating these boxes is unrealistic, and that some other option
will speed DNSSEC deployment.

Like King Canute, we must recognise that we have no power over the tide,
we have to swim with it.

George

---

From: Mark Andrews <[email-masked]>
Date: Mon, 31 Aug 2009 23:36:09 +1000

In message <B9B4363BF2AA46D7969DD66D173D57D4@localhost>, "George Barwood" write
> I mean the widely deployed standard defined by RFC 1034 / RFC 1035.

If they were compatible with RFC 1034 / RFC 1035 then they would
have been generating their own queries.  This is what a recursive
server was described as doing in RFC 1034 / RFC 1035.

Instead someone thought they would be "smart" and just copy the
packet without thinking about all the possible ramifications of
just copying a packet.  You are taking on blind faith that the
packet you are emitting will not cause problems if you have not
fully check the input packet and understood it completely.

A device that is fully compatible with a standard is incapable of
emitting a packet that is outside of that standard.  These devices
never were fully compatible with RFC 1034 / RFC 1035 because they
are capable of emitting packets which are not compliant with RFC
1034 / RFC 1035.

RFC 1034 / RFC 1035 has a lot of "do it this way" in it.  Until you
try and do it another way you don't realise what was rejected at
the design stage or in early prototypes.  Recursive servers fall
into this category.

> compatible with the earlier standard so that they may be easily deployed.

The were.

These devices were, and still are, not compliant with RFC 1034 / RFC
1035 as it existed or any combinations of the extension to RFC 1034
/ RFC 1035.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 01 Sep 2009 00:03:44 +1000

In message <339C5564ABB948BAB7F9591DF3325140@localhost>, "George Barwood" write
> will speed DNSSEC deployment.

We don't need to update the existing boxes.  We just need to make
sure future boxes behave better.  We are doing that by writing down
what the vendors got wrong and telling them what they should be
doing to fix the issues with their boxes.

It it possible to work through most of these boxes.  For those you
can't you just need to point your clients at a DNS server which is
not the box.  We did that sort of thing for years before PPP had a
nameserver option in the dialup world.

Step by step instructions exist showing how to do this for major OS's.

Mark

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 31 Aug 2009 07:51:18 -0700

> doing to fix the issues with their boxes.

This is predicated on the premise that the turnover on these boxes is  
reasonably swift, compared with the desired DNSSEC deployment.  I  
don't believe this is correct.

Look at it this way.  I'm a technophile.  If anyone is going to churn  
equipment, it would be someone like me.

In the past decade-plus, I've gone through 3 NATs.  The first one was  
replaced because it didn't include an AP, and it was my roommate's  
anyway.  The second one had a hardware failure after over 5+ years in  
service, and I wanted an excuse to upgrade to an 802.11BG access point.

During that time, I went through many more computers.  The lifespan of  
these stupid boxes is annoyingly long.

> nameserver option in the dialup world.

But this I agree with.  And as I've repeatedly advocated, the client  
needs to run a full recursive resolver in the DNSSEC world anyway, to  
give a good default failure case for name resolutions.

Although these stupid middleboxes are commonly broken, they will  
almost always pass random-garbage TCP unmolested in our experience,  
and even on UDP, many will pass non-fragmented DNS with EDNS0  
unmolested, or at least pass EDNS@512 unmolested, which means you can  
construct a local recursive resolver that can effectively and  
efficiently deal with these broken middleboxes, by quickly discovering  
their behavior and adapting the recursive resolver to operate within  
those constraints.

> Step by step instructions exist showing how to do this for major OS's.

Step by step instructions that my MOTHER can follow?

---

From: Mark Andrews <[email-masked]>
Date: Tue, 01 Sep 2009 01:19:59 +1000

In message <[email-masked]>, Nicholas W
> these stupid boxes is annoyingly long.

There is another technology change which is just starting to happen
is a big way.  Residential IPv6 is starting to be rolled out and
that will involve CPE box upgrades/replacements.  The same boxes
that we want to be fixed are the ones that will be upgraded /
replaced to support IPv6 or to continue to support IPv4 when the
ISP moves its infrastructure to IPv6.

I know I am waiting for a good AP+Router with IPv6 support to replace
the existing box.  I'd like to know if DNS actually worked in it
before buying it.

> Step by step instructions that my MOTHER can follow?
 
I don't know your mother.   I do know lots of mothers followed such
instructions in the past successfully.

Mark

---

From: Alex Bligh <[email-masked]>
Date: Mon, 31 Aug 2009 16:48:30 +0100

--On 1 September 2009 00:03:44 +1000 Mark Andrews <[email-masked]> wrote:

> not the box.

With some boxes (e.g. those that drop UDP fragments even in packets
not addressed to them), this will cause fallback to TCP for responses
greater than 1500 bytes. Whether or not this is acceptable appears
to be an open question.

-- 
Alex Bligh

---

From: Doug Barton <[email-masked]>
Date: Mon, 31 Aug 2009 09:52:23 -0700

> is a lot more complex than DNS configuration, that mDNS is no

If only there were a solution for the problem of hosts behind a local
router configuring themselves. We would need something that would
allow the host to send out a request for configuration information,
and something on the local network to send out information such as a
usable IP address, default gateway, netmask, and name servers. Oh, if
only such a thing were real! What a wonderful world that would be!

> Having a globally unique anycast addresses for default local resolvers

Yeah, I don't see any way THAT could go wrong.

Doug

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 01 Sep 2009 04:24:36 +0900

> ISP moves its infrastructure to IPv6.

Wrong.

Instead, it is merely that any technology which requires CPE
upgrades/replacements has significant difficulty for deployment.

> the existing box.  I'd like to know if DNS actually worked in it

You assume that ISPs are willing to perform:

	support IPv6

	modify COE for A+P

	replace CPE for A+P at the same time as they modify COE

which is a lot more difficult than just

	support IPv6

even which is not happening.

With end to end NAT, ISPs only need to

	modify COE for E2ENAT

and they can forget IPv6 support forever. Customers may or may not
upgrade end hosts.

With the COE modification, we can recommend source port randomization
that we don't have to support DNSSEC.

> instructions in the past successfully.

According to your theory, both IPv6 and DNSSEC should have already
been fully deployed.

						Masataka Ohta

---

From: Mark Andrews <[email-masked]>
Date: Tue, 01 Sep 2009 08:00:06 +1000

> even which is not happening.

Except it is.  It's cruch time and residential ISP are now reacting.
There are commisioning CPE product development, now, to allow them
to support both IPv4 (NAT'd) and IPv6 into the future.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 01 Sep 2009 08:51:27 +1000

> greater than 1500 bytes. Whether or not this is acceptable appears

You can still work through them.

Fallback to TCP is not a open question for these boxes.  Even if
you read RFC 3226 as disallowing advertising EDNS@512, EDNS at sizes
which prevent fragmentation is still expected and this will result
in TCP occuring.  The amount of TCP depends on lots of factors.

Mark

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 01 Sep 2009 08:49:00 +0900

> Except it is.  It's cruch time and residential ISP are now reacting.

Well...

According to some people, yes, IPv6 deployment has been happening
for these 15 years.

So?

> to support both IPv4 (NAT'd) and IPv6 into the future.

It's easy to develop products.

However, there is hardly any incentive for ISPs to replace all
the CPEs, which costs a lot.

Anyway, if we can instruct NAT vendors to follow our guideline
on DNS relaying behavior, we can let them implement plain old
DNS securely that there is no point to have DNSSEC, which is
merely weakly secure.

						Masataka Ohta

---

From: Mark Andrews <[email-masked]>
Date: Tue, 01 Sep 2009 10:14:57 +1000

> DNS securely that there is no point to have DNSSEC, which is

The problem is that the boxes are not EDNS compliant or even RFC
103[45] compliant.  I want a box that will do DNS/TCP.  The Netgear
box I have sitting next to me doesn't do that and Netgear expect
me to pay them to talk to them about this.  This is not a level 1
problem, you have to pay to get to level 2.  The bloody hide of
them.  DNS/TCP is basic DNS.  Nothing fancy.

At least CISCO (Linksys) will talk to you.  They will acknowledge
faults in their products without you have to pay to do so.

Mark

---

From: Alex Bligh <[email-masked]>
Date: Tue, 01 Sep 2009 06:55:13 +0100

> in TCP occuring.  The amount of TCP depends on lots of factors.

For clarity, the situation I meant was as follows:
 1. Client advertises EDNS0@4096 which it is perfectly capable of handling
 2. Client addresses DNS query directly to server (outside middlebox)
 3. Middlebox passes query untouched (except perhaps normal NAT stuff)
 4. Response is UDP, and >1500 bytes, so fragmented
 5. Middlebox passes first packet only, and drops UDP fragments
 6. Client never receives all fragments to reassemble

Now you might say "well the client should be advertising EDNS0@1500 or
whatever" but won't work (even if it is on the fallback path) where
the response is >1500 bytes (and can't be trimmed of extraneous
stuff so as to fit). Ignoring for a moment EDNS page option type
innovations, that one would have to go via TCP as far as I can see.

-- 
Alex Bligh