Subject: [Enum] Re: I-D ACTION:draft-conroy-enum-edns0-01.txt

From: Peter Koch <[email-masked]>
Date: Wed, 26 Oct 2005 20:21:42 +0200

Dear WG,

this is a first review of draft-conroy-enum-edns0-00/01.txt. The document
technically looks good and I agree with the general idea - not necassarily
with the approacvh chosen.
Some details need to be clarified and it would be good to solicit broader
review.

My main concern is that it's not clear how to achieve the goal of having
"everything involved in ENUM" support large DNS responses. It is obvious
that servers and application resolvers must "support" EDNS0 and those
might even be under control of an entity motivated to adapt. Speaking
of intermediaries (firewalls, packet filters, recursive resolvers, ...)
I am not convinced that it's useful to specify requirements in normative
language.

I'd have a similar problem with RFC 3226, but the situation is different.
DNSSEC is a protocol extension to the DNS, ENUM is not. ENUM is a DDDS
application (and thus the EDNS0 "requirement" would most likely apply to all
DDDS usages) using (primarily) the NAPTR RR in a dedicated namespace.

So, instead of heading standards track, a collection of pitfalls to avoid
in a BCP "What you need to know and do to support ENUM in your DNS and
network infrastructure" seems more appropriate at least when it comes to
defining the behaviour of firewalls etc. (see below).

Detailed comments interspersed:

> 2.  Introduction

>    Entities involved in processing ENUM queries and responses have to

The document does not clearly define what an ENUM query (and therefore
a response) is. Is it a query for anything in the e164.arpa domain or
just NAPTR queries?

> 2.1.  DNS - Background
> 
>    DNS is based on a simple question and answer model.  In the standard
>    approach described in RFC1035, a Resolver will construct and send a
>    question to a DNS Server using UDP transport.

s/question/query/

>    Supporting UDP queries is mandatory, but support for TCP queries is
>    recommended also, and is (in effect) required as RFC1123 requires
>    that a DNS Resolver discard a truncated response and retry using
>    another transport protocol.  In effect, Authoritative Name Servers
>    that do not answer TCP queries after returning truncated responses
>    are misconfigured.

The problem is that this is data dependent. If I am absolutely positively
sure my responses will always fit into 512 octets, there's no pressing
need for TCP (well, one might argue that TCP solves other problems than
the size as well, but this is a different topic). So, 1123 doesn't really
generally require TCP support. The second sentence is true but the error
may or may not be due to configuration (could be UDP only SW).

>    With the introduction of the Extension mechanisms described in
>    RFC2671, there is now a mechanism by which a DNS entity can indicate
>    that it is capable of handling messages larger than those implied in
>    the scheme described in RFC1035, so that it can use UDP transport but
>    still receive DNS messages up to the size it specifies in its request

s/request/query/

>    or response.

> 3.  Problem
 
>    While the percentage of queries processed that exceed the UDP size
>    limit specified in RFC1035 is relatively small, the impact on normal

s/while/since/ ?
Also, it should be noted that thi is an obeservation from (parts of) the
none-ENUM (non-NAPTR, non-RR-suffering-from-the-subtyping-problem) DNS.

> 4.1.  Required Aspects of EDNS0 Support

>    receives answers.  The list of involved Servers includes any DNS
>    Servers authoritative for delegated ENUM domains, but also the DNS
>    Servers authoritative for .arpa, the ENUM Tier 0 DNS Servers
>    authoritative for .e164.arpa, and all ENUM Tier 1 DNS Servers with
>    zones delegated from those Tier 0 Servers.

It is not immediately clear why arpa and e164.arpa would need EDNS0
support while at the same time the root servers are missing from this
list. A reason I could imagine is that you'd want to avoid failing EDNS0
negotiations, but those would occur on relatively rare occasions anyway.
In practice those servers will most likely support EDNS0 but making this
a requirement needs more justification.

>    Of course, support is one thing, but use is another.  To clarify, the

Indeed. The document not only needs to ask for EDNS0 support but would
also have to suggest minimum DNS payload sizes acceptable.

> 4.1.2.  Fragmentation Requirement
> 
>    Second, a DNS Server may receive queries that indicate a given size
>    of response is acceptable.  However, the Resolver may be connected
>    via a network with a lower MTU, in which case the response packet
>    will undergo fragmentation and reassembly in transit.
> 
>    Thus, although obvious (and not directly related to its use in
>    processing ENUM requests), this means that:
> 
>       A DNS Server responding to a query that includes the EDNS0 size
>       option MUST NOT set the DF (Don't Fragment) bit in the UDP packet
>       holding its answer.

(s/UDP packet holding its answer/UDP response packet/)

This clarification/addendum to EDNS0 is "obvious" but doesn't belong into
this document IMHO.

> 4.1.3.  Intermediary Node Requirement
> 
>    The final point concerns intermediate nodes.  It has been noticed
>    that some intermediate nodes exhibit overly aggressive behaviour.
> 
>    Specifically:
> 
>       Intermediate nodes MUST NOT block valid ENUM queries and responses
>       that indicate EDNS0 support, even if these are larger that the
>       size given in RFC1035.  In particular, intermediate packet filters
>       MUST NOT assume that large DNS queries and responses are invalid;
>       they are not if they indicate EDNS0 support correctly.  Such
>       packet discard strategies are in error.
> 
>       Intermediate nodes MUST NOT block valid ENUM queries and responses
>       sent over TCP transport.

"Firewalls must not interfere with solicited legal traffic."
This is a problematic approach in that I can't imagine what the
practical outcome is. This is a "don't drink and drive" style recommendation.
Also, the question whether or not these strategies are "in error" may be
viewed differently. The "unknown==hostile" approach isn't too uncommon.

>    This last requirement means that intermediary packet filters MUST NOT
>    simply block all TCP traffic; it is perfectly reasonable for DNS
>    queries to be sent over TCP transport, and a more selective strategy
>    will need to be chosen.

Again, I doubt that ruling the behaviour of any such device with normative
language is helpful.

> 5.  Security Considerations
> 
>    This document does appear to introduce any extra security issues over
>    and above those mentioned in RFC3761 and in RFC2671, as well as those
>    listed in the thorough analysis of the threats to DNS in RFC3833
>    [11].

Any "not" missing in this paragraph?

>    It should be noted that mandating the use of EDNS0 by ENUM-related
>    entities also facilitates the deployment of Secure DNS, DNSSEC,
>    currently defined in RFC4033 [12], RFC4034 [13] and RFC4035 [14].
>    Secure DNS will be necessary to verify the integrity of ENUM
>    responses.  RFC3225 [9] states that clients signal their ability to
>    handle signed responses via the DO (DNSSEC OK) bit in the EDNS0
>    header and a name server will not return these unless this bit is
>    set.  So unless EDNS0 is used, ENUM-related entities will be unable
>    to verify DNSSEC-signed responses from the DNS.  Signed replies from

This is already covered by the DNSSEC spec, and thus is misleading here.
In addition, the document uses EDNS0 as synonym for "payload size
negotiation" and then now concludes that you'd need the OK bit?
I'm glad to see a recommendation for DNSSEC in ENUMland, but this particular
linking appears a bit arbitrary.

>    the DNS are also much larger than unsigned ones, which provides an
>    added incentive to use larger UDP payloads.

Which is why the to-be-determined minimum payload size should also (optionally)
account for the DNSSEC payload growth, too.

> 8.2.  Informative References
> 
>    [8]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
>          Levels", RFC 2119, BCP 14, March 1997.

At least this one needs to be normative.

Finally, in addition to all these considerations of size, the WG should
also discuss the NAPTR RR's subtyping problem and potential consequences of
the proliferation of enum service specifications.

-Peter

_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: Jim Reid <[email-masked]>
Date: Thu, 27 Oct 2005 15:07:36 +0100

Peter, thanks for reviewing the draft and for your comments. I'm  
puzzled by some of them.

> I am not convinced that it's useful to specify requirements in  

Well if it's not done in that way through some sort of standards- 
track RFC, what other approach would you suggest? IMO without such a  
document, implementors have nothing to go on. If there's nothing that  
says "you've got to support EDNS0" (and explains why), there's a good  
chance EDNS0 support won't make it into ENUM-aware handsets. Making  
EDNS0 support mandatory should mean it doesn't get dropped from the  
feature set in the OS for these types of embedded devices. ie Unless  
someone/something tells those developers to put in EDNS0, they won't.

> defining the behaviour of firewalls etc. (see below).

Maybe. But this draft isn't really about firewalls or routers. And  
these should alredy be supporting EDNS0 anyway. And again, unless  
there's something that says EDNS0 is mandatory in ENUM -- which I  
think we agree it should be -- where's the incentive for vendors to  
incorporate support for this in their products?

> a response) is. Is it a query for anything in the e164.arpa domain or

Queries in e164.arpa, obviously.

> generally require TCP support.

You are Dan Bernstein and I claim my 5 dollars! :-)

> The second sentence is true but the error

Peter, you're picking nits. A server that doesn't do TCP after a  
truncated response is misconfigured.
Whether that is caused by a broken configuration file or a faulty  
implementation is neither here nor there. It's more diplomatic to  
just say such setups are misconfigured. I would have preferred to say  
they were broken beyond belief but my co-author's wiser head prevailed.

> none-ENUM (non-NAPTR, non-RR-suffering-from-the-subtyping-problem)  

True enough, but that's a discussion for another working group.

> a requirement needs more justification.

We deliberately avoided references to the root servers for the  
obvious reasons. Anything that affects root server operations is a  
political nightmare. Anyway, all the root servers already support  
EDNS0  -- as you know. Besides, those servers need EDNS0 for other  
political horrors that are coming to the root zone Real Soon Now like  
IPv6 glue and Secure DNS. Now we could have said "lookups under  
e164.arpa must use EDNS0". But that would pre-judge whatever domain  
name is chosen for Carrier ENUM.
It would also exclude the ENUM-like stuff that the GSM people are  
doing under their bogus .gprs TLD. Sigh.

> also have to suggest minimum DNS payload sizes acceptable.

If it's not already there, that should be in the next iteration of  
the ENUM Experiences Draft. Some history Peter: The text about EDNS0  
started out in that draft by Lawrence and Kazunori Fujiwara. It was  
felt that it needed to be extracted and put into a standards-track  
draft. Since the experiences draft is likely to end up as an  
informational RFC, that would not be the appropriate place for  
documenting mandatory implementation requirements. So this is why we  
have the EDNS0 draft and normative references to it in the  
experiences draft. Hopefully this means we end up with a short  
standards-track RFC that says "use EDNS0" and an experiences draft  
that recommends appropriate payload sizes based on, well...  
operational experience.

> viewed differently. The "unknown==hostile" approach isn't too  

True enough. But without a document that says EDNS0 to be expected  
and must not be blocked, what hope is there of getting broken stuff  
fixed or expecting new stuff to work properly? If my firewall is  
broken, there's more chance of the vendor doing something about that  
if I can point them at a standards-track RFC that says why it's  
broken. ie It can be proven that the problem is a bug and not a feature.

> Again, I doubt that ruling the behaviour of any such device with  

Let's turn this around. Is this normative language unhelpful? In the  
worst-case scenario, it makes no difference IMO. For anything better  
than that, it provides an unambiguous reference to developers to do  
the Right Thing. Of course whether they choose to do that or not is  
another story. But at least the requirement has been documented.

> linking appears a bit arbitrary.

I don't understand why you think this is misleading or arbitrary.  
Perhaps you could provide alternate text? The text above is just  
telling implementors that they're eventually going to need EDNS0  
anyway because of DNSSEC. So if a developer thinks they might be able  
to weasel out of supporting EDNS0 -- say because they believe  
everyone will have tiny NAPTR RRsets -- they can think again. In  
other words, if you're writing an ENUM client for a handset you're  
going to need EDNS0 support because DNSSEC is just around the corner.  
Secure DNS is going to be done in six months, isn't it? :-)

> the proliferation of enum service specifications.

IMO that's for the experiences draft (or maybe another one on enum  
service definitions), not this one.

---

From: Peter Koch <[email-masked]>
Date: Thu, 27 Oct 2005 19:54:58 +0200

> track RFC, what other approach would you suggest? IMO without such a  

It depends on who you want to address. First, there's vendors of applications
issuing ENUM queries, then there's vendors and operators of servers for
e164.arpa zones, vendors and operators of intermediate DNS systems (recursive
servers, caches, ...) and vendors and operators of other infrastructure.
A standards document might be aimed at the first group, but for the other
ones it's an operational issue. E.g. there is no "ENUM (aware) name server",
it's the operator's task to pick the right gear. How would you assess that
a requirement like this

      size given in RFC1035.

is ready for Draft status? Do those firewalls implement ENUM?

> chance EDNS0 support won't make it into ENUM-aware handsets. Making  

Ok, this covers the client/querier side.

> Maybe. But this draft isn't really about firewalls or routers. And  

See the above quote.

> incorporate support for this in their products?

They want them to be usable?
> Queries in e164.arpa, obviously.

Sorry, that's not obvious to me (and below it seems not to you either).

> truncated response is misconfigured.

It is ``broken'' but there might be different reasons. What I was trying to
say is that this type of assessment seems misplaced in a requirements doc,
especially if this one is about "ENUM queries".

> True enough, but that's a discussion for another working group.

Sorry?

> IPv6 glue and Secure DNS.

So what? If it's a requirement that is already fulfilled, where's the
problem to state it? ARPA happens to be served by the root servers
as well, but you listed that explicitly. But you did not answer my
question: why would e164.arpa and arpa servers need to support EDNS0?
(and it's irrelevant that they do anyway)

>                           Now we could have said "lookups under  

In one of the earlier responses you said that en "ENUM query" is for
anything below "e164.arpa", now you're extending the scope?

> that recommends appropriate payload sizes based on, well...  

Thanks for that explanation, my last read of the experiences draft dates
a while back. However, I don't follow here. What's the point of mandating
the EDNS0 feature without at the same time setting minimum standards for
the payload size?

> broken. ie It can be proven that the problem is a bug and not a feature.

So, you are saying that the firewall vendor is more "impressed" by normative
language in an RFC that they've never heard of than by a DNS protocol
extension used by their customers (and that they've also never heard of)?
You're mixing policy and protocol.

> Let's turn this around. Is this normative language unhelpful? In the  

That's a weak justification.

> another story. But at least the requirement has been documented.

Yes, but that's an operational requirement.

> going to need EDNS0 support because DNSSEC is just around the corner.  

This effort looks more like an application developers "pick the right
DNS underwear" guideline than a standards track document. DNSSEC is more
complex than EDNS0; EDNS0 is mandatory for DNSSEC, but it's not the
enabler as your text suggested. What's more important is the combined
size requirements. Personally I like the "Secure DNS will be necessary to
verify the integrity of ENUM responses" easter egg.

Attempt of summary:

We agree that EDNS0 (with reasonable payload sizes) is the right way to deal
with huge NAPTR responses. My suggestion is that the document should skip
the normative language on firewalls ("intermediaries") and all the side
issues but instead should clearly focus on the resolver (application
using the ~) side.
In fact, doing this once for all DDDS applications would even be better.

-Peter

---

From: Jim Reid <[email-masked]>
Date: Thu, 27 Oct 2005 20:55:21 +0100

On Oct 27, 2005, at 18:54, Peter Koch wrote:

> How would you assess that a requirement like this
>
> is ready for Draft status?

IMO, yes. Besides, this is for the WG to decide.

> Do those firewalls implement ENUM?

I don't care. All that matters is they don't erroneously block EDNS0  
traffic. As some well-known firewalls are currently known to do.

>> Maybe. But this draft isn't really about firewalls or routers. And

You're obsessing about this Peter. The context should be simple. If  
ENUM clients use EDNS0 and ENUM name servers use EDNS0, anything in  
between shouldn't mess with those packets. That's all.

> They want them to be usable?

Well it hasn't worked so far. We seem to agree that EDNS0 support in  
clients and name servers makes them more usable. From our  
perspective, this is a Good Thing as it cuts down on TCP retries. An  
applications developer's perspective will be different: I do an ENUM  
lookup and get an answer. Eventually. I don't care if this causes  
extra delays or TCP queries. My code never sees what goes on  
underneath a call to the resolver API. My code is "usable" because it  
works and I get an answer from the DNS. So it all depends on the  
definition of "usable".

> especially if this one is about "ENUM queries".

s/misconfigured/broken/

Does that satisfy you?

>>> Also, it should be noted that thi is an obeservation from (parts  
>>> of) the none-ENUM (non-NAPTR, non-RR-suffering-from-the-subtyping- 
>>> problem) DNS.
>>

Debates about the merits of RR subtyping largely belong elsewhere --  
dnsext?

> anything below "e164.arpa", now you're extending the scope?

No. I'm just not prejudging the outcome of what might emerge from the  
WG's Carrier ENUM discussions or the documents that ETSI or the GSMA  
could chuck over the wall to the WG.

> the EDNS0 feature without at the same time setting minimum  

To be sure EDNS0 support makes it into ENUM clients, especially  
handsets. Payload size comes later.
FWIW, RFC3225 says nothing about DNSSEC payload size either.

> You're mixing policy and protocol.

No. I'm saying that if ENDS0 is made mandatory for ENUM, operators  
have something they can add to their procurement criteria. And show  
to their suppliers who might otherwise quibble about supporting EDNS0.

> DNS underwear" guideline than a standards track document.

That may well be true. However if that "choose the right DNS  
underwear" guidance doesn't appear as some sort of standards track  
document, you can be sure manufacturers will not pay enough attention  
to it. Especially in the telco world.

> issues but instead should clearly focus on the resolver (application

I wish I could agree Peter. IMO the draft can't talk about EDNS0  
support in clients (and by implication for ENUM name servers) without  
mentioning intermediate nodes. There's no point in my client talking  
EDNS0 to your name server if some box in between is going to barf  
over those packets.
How can we resolve this?