Re: draft-bellis-enum-send-n-00

On Apr 3, 2008, at 20:16, Roy Arends wrote:
> On Apr 3, 2008, at 1:35 PM, Jim Reid wrote:
>
>> On Apr 3, 2008, at 08:05, Duane wrote:
>>> If not ENUM, then where does this best fit?
>>
>> IMO the issue of putting numbering plan information in the DNS is
>> best solved with a new DNS RR type that's designed for that specific
>> purpose and probably not with a NAPTR. So that probably means writing
>> up something for the dnsext 2929bis process. How that hypothetical
>> new RRtype could be used in e164.arpa is something that this WG could
>> pick up.
>>
>> However this draft is deeply flawed. There are many problems:
>>
>> [1] It is simply unacceptable to say this NAPTR service type MUST NOT
>> be used with a wildcard.
>
> Of course it is acceptable.

We will have to disagree about that. We're both used to disagreeing  
with each other. :-)

> Technically you could have a wildcard here, but it just makes no  
> sense doesn't it?

There may be circumstances where a wildcard will be needed. For  
instance when there are other NAPTRs besides this funky send-n  
service type at a given owner name.

Even though I despise wildcards, it's not unreasonable to have a  
construct like:
	*.<area-code-and-other-goop>.e164.arpa. NAPTR ... "<some-sip:-URI>" ..
to direct all numbers in a block to a specific end-point. Or maybe  
there are a bunch of wildcard NAPTRs, one for each specific service.  
If this scheme is deployed or needed, it can't be done if this send-n  
proposal goes ahead in its current form and there has to be one of  
these send-n NAPTRs as well. This is why I suggest a new RRtype  
that's specifically designed for encoding numbering schemes instead  
of a NAPTR.

> This record is at that position solely because it assumes a number  
> of labels.

This is also bad design. The RDATA for a resource record should not  
be dependent on the number of labels in the owner name. [And yes, I  
do know that RRSIGs have this property.] Thanks for reminding me  
about that so I could remind the list. :-)

> Maybe a better wording would be "NOT RECOMMENDED".

Maybe. But it still doesn't change the fact that it's very poor  
protocol design.

> This draft is an -00 version, and I'm sure this section is meant as an
> operations guideline, not as pure core protocol codex.

An operations guidline may well be the intention. But what's written  
looks like "pure core protocol codex". Deployment of this NAPTR  
service type would prevent a core feature of the DNS from being used.  
Ordinarily I would rejoice about something that curtailed DNS  
wildcarding. But that should be an ID that gets rid of wildcarding  
completely, not something that tinkers with wildcard semantics for a  
particular NAPTR subtype.

>> [3] The hierarchical structuring of E.164 numbers and the DNS means
>> the scheme as proposed is vulnerable to all sorts of nasties. IIUC
>> introducing one of these "E2U+pstndata:send-n" at the apex of the
>> tree could nuke all the others at any leaf nodes in the tree. Suppose
>> someone puts "E2U+pstndata:send-n" ""!^.*$!pstndata:send-n/1-15!" at
>> the zone apex. It's game over.
>
> Again, isn't that just a silly config mistake that one should avoid?

That's a gross over-simplification Roy. Firstly, a protocol which is  
not just vulnerable to such a silly config mistake but actually  
allows it to be made is broken. Now when you consider the environment  
where this draft is expected to be used, the ramifications of a  
"silly config mistake" are mind-boggling. PBXs and SBCs could be told  
to dial incomplete numbers. This provides additional threats besides  
the obvious denial of service worries. For example, a SIP server  
could well have a configuration rule which says "fall back to the  
PSTN and SS7 (=> pay real money) when the outcome of the ENUM lookup  
results in some sort of call completion failure". Let's also consider  
the impact of this "silly config mistake" when it causes calls to  
emergency numbers to fail.