Re: 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