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

The privacy issues here are central as you correctly point out. But I would
not assume that these queries are going to be used in the context of the
single root DNS. There have always been split views of the DNS and there
always will be.

The authors need to be very clear under what circumstances this class of
query is used and under what network elements actually use the query and
what are the security aspects that these queries are used in. 

Is this private ENUM implementation issue?

That said the larger issue is this document a ENUM WG or an DNSEXT document.


Upper IETF Management needs to address this issue ASAP.

However it is manifestly self evident the direction we have been going in
the ENUM WG is what is the use of RFC 3761 "technology" for a variety SIP
session related routing/signaling issues outside the general scope of
e164.arpa.

That decision has already been made with our ongoing drafts on LNP, CNAM and
trunk group data.

IMHO the document is clearly "in scope" the only issue is what WG scope is
it in.

>  -----Original Message-----
>  From: Duane [mailto:[email protected]]
>  Sent: Tuesday, December 11, 2007 8:20 PM
>  To: Hadriel Kaplan
>  Cc: [email protected]; Robert H. Walter; Creighton, Tom; Raja Gopal
>  Subject: Re: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt
>  
>  Hadriel Kaplan wrote:
>  > Howdy,
>  >
>  > We just submitted an I-D for a mechanism to include the source URI
>  > information in ENUM queries, primarily targeted at including the
>  > From/PAI SIP/Tel URI of the SIP Request which triggered the ENUM
>  lookup,
>  > so the ENUM server can provide a response based on that.  This is
>  useful
>  > for performing source-based ENUM routing and filtering.
>  >
>  > http://www.ietf.org/internet-drafts/draft-kaplan-enum-source-uri-
>  00.txt
>  
>  While you have focused on the implemtation in your draft, I feel there
>  is a number of privacy implications and you don't seemed to have
>  covered
>  this subject or anything like it in your current draft.
>  
>  Currently NAPTR/DNS requests, regardless if the informations is
>  privately or publicly accessible, has the potential for the source IP
>  and requested destination to be tracked in varying degrees. Source IP
>  in
>  most cases will be a shared server such as an upstream provider and
>  depending on the time to live of DNS information may be requested by
>  multiple people but only having one internet request which limits the
>  ability for third parties to be able to identify the requester or
>  requesters.
>  
>  This draft appears to make it trivial for a number of parties, such as
>  most governments and numerous commercial entities which are actively
>  researching ways to determine the caller. This proposal appears to
>  make
>  identifying and tracking callers when they wouldn't normally be in the
>  call path or otherwise have access to such information.
>  
>  Most if not all methods in use at present, to limit or at least reduce
>  unnecessary leaking of personal and organisational privacy, would fail
>  if source URI was included.
>  
>  Such measures include, but aren't limited to, how DNS requests are
>  sent
>  - via provider and other upstream server(s) or requested directly via
>  a
>  local cache or using a public dns service, the number of users sharing
>  the same caching name server or name server path if IP links are being
>  monitored, the use of IP masquerading, the use of TOR or similar
>  anonymising services to hide the requesters public IP, the use of
>  encryption on VoIP packets but DNS requests/replies may not be using
>  the
>  same path and as a result may not be encrypted, IP link in terms of
>  static or dynamic IP allocation.
>  
>  --
>  
>  Best regards,
>   Duane
>  
>  _______________________________________________
>  enum mailing list
>  [email protected]
>  https://www1.ietf.org/mailman/listinfo/enum