Subject: Re: [dnsext] Working around proxies

From: Doug Barton <[email-masked]>
Date: Tue, 01 Sep 2009 08:46:23 -0700

Mark Andrews wrote:

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

I agree totally with Mark here. All this effort spent trying to figure
out how to work around broken middleboxes is (to put it in the
politest possible terms) wasted. We have a LANDMARK opportunity here
to educate CPE manufacturers about the need to include proper DNS
support (including DNSSEC, EDNS and TCP) in their products while they
are redesigning them for IPv6. DNSSEC and IPv6 are likely to be the
last 2 major renovations of Internet protocols that we will ever be
able to do. If we miss this opportunity it's gone forever.

The fact is that there will either be market demand for IPv6 and
DNSSEC, or there will not. If there is sufficient market demand then
the CPEs that don't work with it/them will have to be replaced anyway.
If there is not sufficient market demand then we're wasting our effort
trying to make them work.

Doug

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 02 Sep 2009 06:30:36 +0900

> are redesigning them for IPv6.

With Mark? But, he wrote:

> The problem is that the boxes are not EDNS compliant or even RFC
> 103[45] compliant.

That is, middleboxes produced long after 103[45] was published are
not 103[45] compliant.

So, how can you expect middleboxes to be produced will be EDNS
compliant?

Note also that, if designers of middleboxes are well educated, they
will randomize source port of DNS query and won't inappropriately
cache glues that we don't need DNSSEC at all.

> DNSSEC, or there will not.

The fact we have confirmed with these 15 years of experience is that
there is no market demands for IPv6 nor DNSSEC.

Note also that there is no technical demands, because IPv4 address
space can be extended by NAT while preserving end to end
transparency and DNSSEC is not secure end to end.

						Masataka Ohta

---

From: Mark Andrews <[email-masked]>
Date: Wed, 02 Sep 2009 11:07:47 +1000

> So, how can you expect middleboxes to be produced will be EDNS

By performing a EDUCATION campain.  That's not just publishing
RFC's.  It's ringing/phoning/writing to vendors and making sure
that they are aware of the issues.  It's logging fault reports with
vendors if you happen to have their products.  It's talking to
consumer orginizations and having them to product reviews on this
class of products.  It's talking to the tech editors of papers about
the problems that are coming up if the these vendors don't act.
There are some products that get this right.  It's about talking
those up and the ones that are broken down.

The 1st aim is to get new products being developed doing the right thing.
The 2nd aim is to get currently shipping products fixed so that new ones 
oing to the shelves don't make things worse.
The 3rd aim is to encourage vendors to make fixes to existing products
available.
The 4th aim is to get the public to apply those fixes.

I'm aiming for 100% with the 1st aim.
If we get 50% I'd be happy with the 2nd aim.
If we get 1% I'd be happy with the 4th aim.

> cache glues that we don't need DNSSEC at all.

You are missing the point.  EDNS needs to work reliably whether it
is carrying DNSSEC records or not.  Referrals are already too big
for plain DNS to work.  This is future planning whether it be DNSSEC
or something else we still need EDNS to work cleanly though these
boxes.
 
> there is no market demands for IPv6 nor DNSSEC.

The future is not the past.   The jury is still very much out on
both of these.

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

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 02 Sep 2009 14:09:00 +0900

> By performing a EDUCATION campain.

Good luck.

> for plain DNS to work.

Considering that anycast works, routing table entries for anycast
addresses are not a problem compared to those for multihoming and
that IPv6 won't be deployed, I can see no need for larger message
size.

BTW, properly designed public key DNS with 2048 bit key length does
not need messages longer than 512B, either (assuming anycasting
properly deployed), even during key roll over.

> The future is not the past.   The jury is still very much out on

Given that technical demands disappeared, it is assured that future
market demands will be less than those of the past.

						Masataka Ohta

---

From: [email-masked]
Date: Wed, 2 Sep 2009 09:19:39 +0100

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

All of the details are on the ICANN SSAC page, and also at:

http://download.nominet.org.uk/dnssec-cpe/

Ray

---

From: [email-masked]
Date: Wed, 2 Sep 2009 09:22:23 +0100

> The devices are NOT broken. The protocol should have been designed
> to be compatible with the existing installed base.

George, with respect, that's rubbish.

The transport-related RFCs that I reference in RFC 5625 are all at least 
10 years old.  RFC 2671 (EDNS0) was published in August 1999.

Ray