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

Yup, you're right, I should make that issue very explicit in the draft.  The purpose of this draft's extension is strictly for non-public ENUM use, and I should have said that (d'oh).

The requester can decide if it wants to include the extension or not, and whether to provide an anonymous URI or not.  If a device "in the network" wants to issue such a request, and has the source URI info with which to do so, then I'm afraid the government can already get that information - directly from that device.  In fact, without this extension, to perform routing for certain types of application messages, such as SIP, would instead require using SIP and sending the entire SIP request (bodies and all) to the routing service and it would get far more information than just the source URI.

-hadriel

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