Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-dns-tcp-requirements-01.txt

From: Alfred Hönes <[email-masked]>
Date: Wed, 28 Oct 2009 14:44:34 +0100 (MEZ)

At Tue, 27 Oct 2009 16:57:40 -0700, Doug Otis  wrote:

> ...
>
> Updating RFC 1123 should consider the functional alternative made
> possible with RFC2671.  The maximal DNS message size of 512 should
> not reflect a 576 MTU, but that of 1476 MTU. Only beyond that limit,
> should TCP become required.  After all, most CPE equipment can not
> proxy DNS over TCP, so DNS operation is not better accomplished with
> this over reaching TCP mandate.
>
> ...

Although perhaps 1476 might be desirable, it seems ill-advised to
ask for that.  We should align the limit to what already has found
consensus in the IETF for IPv6 in particular, and what link layer
specifications since then have learned to accommodate.

RFC 2460 specifies (on page 24):

|5. Packet Size Issues
|
|   IPv6 requires that every link in the internet have an MTU of 1280
|   octets or greater.  On any link that cannot convey a 1280-octet
|   packet in one piece, link-specific fragmentation and reassembly
|   must be provided at a layer below IPv6.

This limit has been chosen then with various tunnelling technologies
in mind, leaving enough head room for additional tunnel headers etc.
before reaching the traditional Ethernet packet size.

Also, there now indeed are wireless technologies that needed such
convergence layer to adapt the much smaller L2 packet size to the
IPv6 requirement.
We cannot expect anybody will change the boundary again, solely
because this WG would appreciate it (other folks as well, surely!).

The overwhelming majority of link layers for IPv4 should actually
accommodate the same limit today.  (Can somebody please quantify
this assumption based on empirical data? -- Maybe router vendors
will know best, and field tests might help to confirm the results.)

Since avoiding IP layer fragmentation is one of the most important
goals, from an operational and security perspective, we therefore
should contend with the future-(IPv6-)proof packet size limit.

I further suggest that DNSEXT should push the emerging INTAREA WG
to consider aligning the MTU requirements for IPv4 with those for
IPv6 (as quoted above).  This in turn would then allow this WG to
consider raising the mimimum UDP packet size for DNS as well.
Please comment on the INTAREA WG Review call archived at:
http://www.IETF.ORG/mail-archive/web/ietf-announce/current/msg06684.html

This IMHO is the proper temporal sequence of tasks.  I fear DNSEXT
would most likely fail in IETF LC and in the IESG if it attempted
to implicitely change the IPv4 specs in this way.

On the other hand, this means that the "MUST implement" requirement
for TCP Transport of 'normal' (non-{A|I}XFR) DNS traffic is still
needed, with as few exceptions as possible for DNS components,
and with _no_ exceptions for middleboxes.

Furthermore, it might be wise to request *middlebox* support for DNS
packets of (at least?) 4096 octets *today*, over any DNS transport.
It seems not reasonable to expect useful seamless deployment of any
increase in the DNS packet size (via EDNS, TCP transport, 'upgraded'
or IPv6-based UDP transport, or any future DNS transport) unless we
*first* happen to achieve adherence at large to this requirement!

Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: [email-masked]
Date: Wed, 28 Oct 2009 14:00:46 +0000

> *first* happen to achieve adherence at large to this requirement!

RFC 5625 does already attempt to address this.

Ray

---

From: Alfred Hönes <[email-masked]>
Date: Wed, 28 Oct 2009 15:26:25 +0100 (MEZ)

> RFC 5625 does already attempt to address this.

"attempt to address"  !=  "achieve adherence"    :-)

It's still a long way to go.  Some folks need steadily repeated
sermon until they are going to believe, isn't it?   :-)

So reinforcing the requirement to support larger DNS packets
where full transparency of the network is not possible or desired
should be worth the effort, wherever it fits neatly into a document.

  Alfred.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 28 Oct 2009 16:25:57 +0000

> From: Alfred =?hp-roman8?B?SM5uZXM=?= <[email-masked]>
> Date: Wed, 28 Oct 2009 15:26:25 +0100 (MEZ)
> 

"hello mr. middlebox vendor.  since we neglected to inform you that the
traffic you'll carry may include fragments and that you can't really 
predict maximum packet size based on the UDP port numbers on a packet,
we agree that it's perfectly reasonable that you totally fscked it up.
however, in an RFC you never heard of, we did finally get around to
asking that you rev your software to stop fscking up our traffic, so
could you please slot some engineering resources for it even though it
will not result in higher sales nor will failing to do it result in
lower sales?  thanks in advance!"

---

From: Doug Otis <[email-masked]>
Date: Wed, 28 Oct 2009 13:16:20 -0700

On 10/28/09 6:44 AM, Alfred � wrote:

Alfred,

> before reaching the traditional Ethernet packet size.

Yes it would cause fewer issues for tunneling IPv6 to impose an 
alternative to UDP jumbo frames when MTUs are larger than 1280 bytes.

> should contend with the future-(IPv6-)proof packet size limit.

Agreed.  However, how much IPv6 tunneling of UDP would be affected by a 
1476 MTU cut-off for DNS over UDP?  Less than 1%?  And how much more DNS 
traffic could then be handled by UDP with the 196 additional bytes? 
Surely this would cause less harm than 4096 byte MTUs. There is no 
desire to argue about this difference, but a TCP mandate at the 576 byte 
MTUs is clearly wrong.

Imposing _any_ TCP mandate represents an expedient that takes DNS in the 
wrong direction.  As such, this draft should also include a strong 
warning that resources needed to sustain TCP services might be 
provisioned for other transports during aberrant demand, and that it is 
not recommended to be dependent upon TCP availability.

> http://www.IETF.ORG/mail-archive/web/ietf-announce/current/msg06684.html

Imposing a TCP mandate when DNS messages exceed 512 bytes allows 
compliance with seldom used 576 byte MTUs.  A TCP mandate at this MTU 
size makes little sense when it will likely increase TCP traffic DNS 
servers are thereby _mandated_ to provide.  Expecting use of UDP up to 
either 1476 or 1280 byte MTUs still substantially limits reflected 
attack and packet fragmentation.

> *first* happen to achieve adherence at large to this requirement!

It would seem this request has been made long ago, but adherence creates 
other problems less easily solved without complete adherence.

-Doug

---

From: Mark Andrews <[email-masked]>
Date: Thu, 29 Oct 2009 10:41:00 +1100

> not recommended to be dependent upon TCP availability.
 
TCP has always been expected to be implemented unless you had GOOD
reasons to not implement it and had REALLY thought about the
consequences.  Read RFC 1034 and 1123.  TCP was not MAY.  It was
SHOULD.

Does anyone here really think that any proxy vendor, that doesn't
support TCP, could successfully argue that they did that analysis
and have the result pass a laugh test?

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

---

From: Mark Andrews <[email-masked]>
Date: Thu, 29 Oct 2009 11:09:36 +1100

> lower sales?  thanks in advance!"
 
Dear mr. middlebox vendor.  Please stop lying in your DHCP responses
by adverting that your boxes contain a DNS server when they actually
contain a DNS proxy and a poorly implemented one at that.

---

From: Doug Otis <[email-masked]>
Date: Wed, 28 Oct 2009 17:59:17 -0700

On 10/28/09 4:41 PM, Mark Andrews wrote:
> In message<[email-masked]>, Doug Otis writes:

The concern is about establishing a dependence upon TCP.  While TCP has 
often been a fall-back for truncated DNS answers, it has never been 
mandated.  A SHOULD is not a MUST.  TCP being functional for DNS was 
never assured.  Even ensuring that TCP is enable does not ensure 
availability of a lower priority service.  In addition, TCP is not 
enabled by one the roots, and most CPE equipment.  While people can 
configure their CPE equipment to bypass DNS proxy services lacking 
proper TCP support, most do not.

> and have the result pass a laugh test?

What analysis?  Vendors likely considered the resources needed to 
support the features they offered, and decided against expenditures 
related to TCP for DNS.  The CPE market decided TCP was not an 
overriding requirement for DNS, in favor of cost.  This same cost issue 
with TCP killed RDMA.  Mandating that DNS servers MUST provide TCP when 
the service can be carried over UDP extended to conservative MTUs of 
1280, or IMHO 1476, makes no sense.  This strategy should also help 
curtail growth of DNS TCP traffic.  After all, TCP is not well suited to 
efficiently handle DNS, and should be avoided where possible.

-Doug

---

From: Matthew Dempsky <[email-masked]>
Date: Wed, 28 Oct 2009 18:17:38 -0700

On Wed, Oct 28, 2009 at 5:59 PM, Doug Otis <[email-masked]> wrote:
>  Mandating that DNS servers MUST provide TCP when the service can be carried
> over UDP extended to conservative MTUs of 1280, or IMHO 1476, makes no
> sense.

In a world with 100% support for EDNS, maybe.  But not all clients and
servers support EDNS.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 29 Oct 2009 12:32:41 +1100

> proper TCP support, most do not.

And prey tell how are the customers supposed to know that they can
bypass it or even what values to configure?  If the CPE vendor
didn't want to implement a DNS server then they could have returned
the DNS servers learned from upstream or none at all.  Instead these
vendors choose to have their DHCP clients use their box as a DNS
server then failed to deliver on providing that service.

> efficiently handle DNS, and should be avoided where possible.

You mean the same boxes that implement HTTP servers can't accept a
TCP connection on port 53 and then make a outgoing TCP connection
and then shuffle bits between the two TCP connections?  This is all
that is required of a the TCP component of a DNS proxy.

Again, you want me to believe that they couldn't do something so
simple?  That the cost was too high once they had attracted the DNS
traffic to their box rather than have it go to the upstream boxes
directly?

Mark

---

From: Alex Bligh <[email-masked]>
Date: Thu, 29 Oct 2009 07:26:08 +0000

> and have the result pass a laugh test?

I'm not sure middlebox vendors much care about a namedroppers laugh test
or they wouldn't produce the proxy s/w they do.

-- 
Alex Bligh

---

From: Douglas Otis <[email-masked]>
Date: Thu, 29 Oct 2009 09:37:05 -0700

On 10/28/09 6:32 PM, Mark Andrews wrote:
> In message<[email-masked]>, Doug Otis writes:
>> While people can configure their CPE equipment to bypass DNS proxy
>> services lacking proper TCP support, most do not.
>

A status page often displays information obtained from the provider. A
user might copy information over to their DHCP settings section, or
perhaps explore their provider's support page.  For this effort, they
could find themselves without DNS service whenever these settings change.

Perhaps the _most_ important setting a customer should make would be to
change the _default_ password and ensure external access is disabled.  A
large number of CPE devices have been 0wned as a result of password
guessing and various firmware faults.

>> Mandating that DNS servers MUST provide TCP when the service can
>> be carried over UDP extended to conservative MTUs of 1280, or IMHO
>>  1476, makes no sense.  This strategy should also help curtail
>> growth of DNS TCP traffic.  After all, TCP is not well suited to

Sure, it could be done.  Unlike UDP, TCP requires more receive,
transmit, and state buffers related to negotiations between two
end points. Received buffers deal with message framing when products
offer DNS related features, and transmit buffers for packet recovery.
Moore's law helps, but dealing with more traffic offsets density
improvements, where power and cooling also impose limits.

Providers offering DNS also benefit from the reliance upon UDP. UDP
requires fewer servers and is less prone to being DDoSed.

-Doug

---

From: Mark Andrews <[email-masked]>
Date: Fri, 30 Oct 2009 09:41:25 +1100

> could find themselves without DNS service whenever these settings change.

Which leads us back to the CPE vendor doing a proper job.  Either
correctly copying data from upstream or fully implementing DNS.
Customers shouldn't have to manually configure this information.

> guessing and various firmware faults.

Useful but not relevent to the discussion.
 
> improvements, where power and cooling also impose limits.

LOL.  You think the HTTP server doesn't require these resources.

One could even just translate both source and destination addresses
and NAT the TCP/DNS connection.  This does have the obvious problem
in that it reduces the redunancy but if you track which nameservers
are responding over UDP it should be reasonably robust.  You could
even send the SYN to all the DNS servers and just let the first to
respond with a SYS/ACK continue.  This gives you back the reduancy.

It is not hard to provide DNS/TCP.  The CPE vendors that don't are
just plain lazy.

---

From: Douglas Otis <[email-masked]>
Date: Thu, 29 Oct 2009 16:45:11 -0700

On 10/29/09 3:41 PM, Mark Andrews wrote:
> In message<[email-masked]>, Douglas Otis writes:
>> A status page often displays information obtained from the
>> provider. A user might copy information over to their DHCP
>> settings section, or perhaps explore their provider's support page.
>> For this effort, they could find themselves without DNS service
>> whenever these settings change.
>

Customers should still change default passwords, but few do.  There are
also features based upon DNS interception, such as parental controls
et al.  UDP makes these implementations easier.

>> end points. Received buffers deal with message framing when
>> products offer DNS related features, and transmit buffers for
>> packet recovery. Moore's law helps, but dealing with more traffic
>> offsets density improvements, where power and cooling also impose
>> limits.
>

The web access feature is however limited to a single session.  This
would not be the case for DNS over TCP, especially when manipulation
might be involved.  However, even the simple single session web access
feature commonly contains security flaws.

> It is not hard to provide DNS/TCP.  The CPE vendors that don't are

This still depends upon available resources.  Rather than lazy, perhaps
it could be described as vendors avoiding support for more than what is
absolutely necessary.  An opportunity for non-lazy programmers to offer
alternative reference implementations for common CPE chip-sets?

-Doug

---

From: Mark Andrews <[email-masked]>
Date: Fri, 30 Oct 2009 11:40:59 +1100

In message <[email-masked]>, Douglas Otis writes:
> Customers should still change default passwords, but few do.

Again you make a irrelevent comment.  If the vendor wanted to they
could set a default password which is different for every box.  This
is not hard and some vendors do exactly that.

> There are

Doing this with TCP is not significantly harder than with UDP.

> feature commonly contains security flaws.

But multiple TCP connections.
 
> alternative reference implementations for common CPE chip-sets?

They exist.

Mark