Subject: Re: [Speermint] Re: [Enum] How to correctly set up the request URI?

From: "Stastny Richard" <[email-masked]>
Date: Fri, 2 Jun 2006 23:37:09 +0200

Tony,
 
I do not fully understand what the CALEA issue has to do with the question which
URI is put in ENUM. This may be a signalling requirement in SPEERMINT
 
I have complete different concerns regarding CALEA, in principle I do 
not understand why the service providers are bothered with this at all,
because the NSA is getting all data from Penn anyway ;-)
 
http://news.com.com/AT38T+leaks+sensitive+info+in+NSA+suit/2100-1028_3-6077353.html?tag=nefd.lede
 
http://www.wired.com/news/technology/0,70944-0.html
 
-sta

________________________________

Von: Tony Rutkowski [mailto:[email-masked]]
Gesendet: Fr 02.06.2006 23:13
An: Pfautz, Penn L, GBLAM; James McEachern; [email-masked]; [email-masked]
Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request URI?

Hi Penn,

>I see no privacy issue with a carrier URI like the one you show below as
>long as it points to a carrier network element rather than directly to
>say, the user's terminal adapter. If the pointer is direct to CPE I'd
>have some concerns, which is not to say a provider can be forbidden
>(except by regulators) to do so.

The concerns primarily relate to network integrity as
well as support of law enforcement (CALEA/LI requirements)
in determining authoritative bindings of user/provider
information to identifiers.  In Europe and many countries,
this binding information is also subject to data retention
directives.

--tony

_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: Tony Rutkowski <[email-masked]>
Date: Fri, 02 Jun 2006 18:05:44 -0400

Hi Richard,

>URI is put in ENUM.

ENUM is little more than a more flexible routing table
- a more dynamic LERG.  Stable public infrastructures
- for network integrity, law enforcement support, and
a host of other requirements - require some ability
to authenticate changes and maintain authoritative
bindings to provider/user information.  Austrian
police cannot do lawful interceptions if they can't
trust the E.164 to URI bindings and do queries to
get authoritative information about providers and
users.

>not understand why the service providers are bothered with this at all,

European authorities will be much better supported
under the EU Data Retention Directive - which will
require capturing and timestamping every signalling
query.

--tony

---

From: "Richard Shockey" <[email-masked]>
Date: Sat, 3 Jun 2006 10:42:25 -0400

Well Tony we continue to agree on some things after all ..

You point is well taken.  ENUM IS more than a flexible routing table. Its
value is in the ability to authenticate and maintain authoritative bindings
for E164 to URI bindings.

How those bindings are used may or may not involve the use of DNS
technology.

Consequently the critical issue is the TRUST created by and maintained by
the authoritative Registry of those bindings and that Registry MAY and in
all likelihood MUST maintain some mechanism for the maintenance of
information about providers and users.

Which is why we did the work on IRIS in the ENUM WG.

BTW Which EU directive you mention IYHO will require the maintenance of a
pin trap of ENUM queries?

> -----Original Message-----
> From: Tony Rutkowski [mailto:[email-masked]]
> Sent: Friday, June 02, 2006 6:06 PM
> To: Stastny Richard; Pfautz, Penn L, GBLAM; James McEachern;
> [email-masked]; [email-masked]
> Subject: Re: [Speermint] Re: [Enum] How to correctly set up the request
> URI?
> 
> Hi Richard,
>

---

From: Michael Haberler <[email-masked]>
Date: Sat, 03 Jun 2006 19:23:15 +0200

>require capturing and timestamping every signalling

Tony -

1) you seem to assume that just because the data may be in a public 
tree it will be queried for call resolution

my guess is the public tree will be a reference-of-last resort - most 
folks will query an internal copy - transferred by IXFR, AXFR, some 
kind of push - whatever

I cant see how this is any different to some internal resolution 
mechanism today?

2) the Data Retention Directive is interpreted quite widely at times, 
but the signaling query recording requirement is new to me

---

we had the nonsense of recording every (cc)TLD nameserver query pop 
up in the European discussion before, it seems we have laid it to 
rest for the time being, just like the the officials asking for 
national IP address allocation every other year or so - the RIR and 
TLD folks are getting quite good at curbing that kind of bull

-Michael

---

From: Tony Rutkowski <[email-masked]>
Date: Sat, 03 Jun 2006 14:28:47 -0400

Hi Michael,

>2) the Data Retention Directive is interpreted quite widely at 
>times, but the signaling query recording requirement is new to me

Art. 5 requires providers to capture:

  (a) data necessary to trace and identify the source
      of a communication:
   ...
   (2) concerning Internet access, Internet e-mail and Internet
       telephony:
        (i) the user ID(s) allocated;
       (ii) the user ID and telephone number allocated to any
            communication entering the public telephone
            network;
      (iii) the name and address of the subscriber or registered
            user to whom an Internet Protocol (IP) address, user
            ID or telephone number was allocated at the time of
            the communication;

  (b) data necessary to trace and identify the destination
      of a communication:
   ...
   (2) concerning Internet e-mail and Internet telephony:
       (i) the user ID or telephone number of the intended
           recipient(s) of an Internet telephony call;
      (ii) the name(s) and address(es) of the subscriber(s)
           or registered user(s) and user ID of the intended
           recipient of the communication;

  (c) data necessary to identify the date, time and duration
      of a communication:
     ...
    (2) concerning Internet access, Internet e-mail and Internet
        telephony:
        (i) the date and time of the log-in and log-off of the
            Internet access service, based on a certain time
            zone, together with the IP address, whether dynamic
            or static, allocated by the Internet access service
            provider to a communication, and the user ID of the
            subscriber or registered user;
       (ii) the date and time of the log-in and log-off of the
            Internet e-mail service or Internet telephony service,
            based on a certain time zone;

  (d) data necessary to identify the type of communication:
      ...
      (2) concerning Internet e-mail and Internet telephony: the
          Internet service used;

The extent to which signalling queries get captured will be
determined by the degree the query information is necessary
to comply with these Art. 5 requirements.

It's worth noting also in the States that the recently enacted
anti-cyberstalking provisions of the VAWA statute defines
Internet software a telecommunications device for the purposes
of making it a crime to use VoIP to harass someone without
sufficiently identifying the calling party.  VoIP providers
will want to provide authoritative identification mechanisms
to meet the requirements.

--tony