Re: New I-D:draft-kaplan-enum-source-uri-00.txt

Hi Peter, folks,
  I agree with all of Peter's comments.
Also...
   Forget ENUM.
First, there is no such thing as an ENUM server - only a DNS server  
that acts authoritatively for domains associated (via ENUM) with E. 
164 telephone numbers.
Second, the fact that a modified ENUM client happens to be the source  
of these DNS queries is not significant to the DNS query itself, nor  
is it to the kind of response it receives.
This draft describes a general mechanism for carrying option data  
within a DNS query that MAY identify the source of that query. The  
intended reaction of a DNS server that supported this extension would  
be to select from its data based on this source identity data as well  
as the QNAME, QCLASS and QTYPE. It seems that the client is  
associated with a DNS recursive resolver, and it appears that this  
resolver partitions any local cache space cache space depending on  
the source identifying data as well as the QNAME, QCLASS and QTYPE.  
This seems to require (very) special treatment for the DNS responses,  
and this special treatment seems to be orthogonal to the QTYPE or  
QTYPE. However, it's a DNS issue, not an issue for a group that  
specifies the ENUM protocol/algorithm, Enumservices and the  
guidelines for development of Enumservices.

Considering process issues:
This draft proposes a DNS extension and requests an EDNS option code  
to be assigned for this purpose. Looking at the extension  
registration process in RFC 2671, it seems that an Informational RFC  
is all that is required for an EDNS option code to be allocated.  
However, I guess that as an extension to DNS, this would be "of  
interest" to the DNSEXT group or maybe DNSOPTS, if DNSEXT sleeps with  
the fishes.
Opinions requested - Peter?

Who's calling?
Vying as my biggest concern with this draft is authentication of the  
option data. How does one know whether the DNS user has any  
association with this data value? Authentication is not covered in  
the draft, and seems to be a REALLY REALLY hard problem using DNS.

Up there with this is the way that the draft discards name space  
partitioning as "proprietary" and requiring collusion of every  
involved party.
AFAICT, this draft needs the collusion of every involved party plus  
every intermediary DNS entity.

ISTM that "in the privacy of your own home", using a technique  
similar to ENUM but combining (say) the source number with the  
destination number would seem to require no changes to anything.  
There would seem to be little or no standardisation required, as this  
is merely a provisioning issue and so appropriate for other fora  
(maybe PEPPERMINT, possibly SPEERMINT for the use case, but agreeing  
a choice on the name space partitioning is something for other folk).

Please not in the ENUM WG - we have enough trouble using the DNS  
architecture as it is, without rewiring it (with special treatment)  
like this.

all the best,
   Lawrence


On 12 Dec 2007, at 16:40, Peter Koch wrote:

> On Tue, Dec 11, 2007 at 08:45:53PM -0500, Richard Shockey wrote:
>
>> That said the larger issue is this document a ENUM WG or an DNSEXT  
>> document.
>
> on a more abstract level this is the counterpart to the NSID EDNS  
> option
> that now would enable the client to identify itself.  The extension  
> is that
> the server would be allowed to change the response based on this  
> identity.
> First, this would be a massive paradigm shift (I know that "views" and
> src-addr based "tricks" exist, but they live ouside the architecture),
> which should, if at all, be discussed in the main WG responsible  
> for protocol
> maintenance.
>
> Second, this "identity" transported by EDNS is hop-by-hop, where  
> what is
> obviously intended here is end-to-end. Intermediates cannot be  
> expected
> to either transparently transmit or unpack and repack this option  
> code.
>
> This addition to (QNAME,QTYPE,QCLASS) also does not seem to  
> interact too
> well with DNSSEC.
>
>>  The ENUM client MUST NOT cache responses for such queries, and
>>  instead MUST treat the TTL value as zero.  Otherwise the local cache
>>  would be used for subsequent queries, even if the originating info
>>  changed, which would lead to false results.  Clearly this could be
>
> This, albeit an obvious restriction, would have negative side effects.
>
> And apart from the privacy issues raised by others,
>
>>  There are no specific security issues for this mechanism, beyond
>>  those already applicable to DNS and ENUM.
>
> also would need to discuss how the "URI" (or in general: the option  
> payload)
> would be authenticated and/or authorized and what the security  
> model behind
> the different "views" is.
>
> It appears to me that not only are the saddlebags about to kill the
> animal <http://www3.ietf.org/proceedings/00dec/slides/PLENARY-3/ 
> index.html>,
> but in fact adding more protocol elements to ENUM (or DNS, for that  
> matter)
> only for use in "private infrastructure ENUM" scenarios urgently  
> suggests
> to revisit the applicability of the underlying infrastructure for this
> use case.  Maybe it's time to replace the "ENUM" in "Infrastructure  
> ENUM"
> with another term.
>
> -Peter
>
> _______________________________________________
> enum mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/enum