Re: [Ecrit] Nomadic VOIP is dead

["Winterbottom, James" <[e-mail]>]

Inline.



> -----Original Message-----

> From: Francois D. Menard [mailto:[e-mail]]

> Sent: Monday, 23 November 2009 4:02 PM

> To: Winterbottom, James

> Cc: ecrit

> Subject: Re: [Ecrit] Nomadic VOIP is dead

>

> > If I understand your approach, you will provide location directly to an

> end-point over DHCP, have the Target constructs a PIDF-LO and send this

> information off to its VSP (no checking),

>

> This means what you are saying is that end-points cannot be trusted to

> report their locations?

>

> Is this a stated assumption in ECRIT that the end-points cannot be

> trusted?

>

> You are saying that OBO should aways be mandatory?

[AJW] I am saying that I have spoken to quite a number (more than 4) regulators around the world and they will not trust location coming from end-points that cannot be verified by some other means. Martin Thomson, I and a few others have been trying to get a means for having literal location bound to a specific end-point but so far this has gotten little traction. So yes, I am saying that the only option right now is a trusted third-party request.



> You are saying that veracity needs to be assessed while a 9-1-1 call is

> being established?

[AJW] Trusted third-party also eliminates the need to do a veracity check at call time. So I only see this as another advantage.





>

> > then have the VPS direct this to the stage-1 routing proxy, because the

> location has been provided by the end-point you have the stage-1 routing

> proxy route the cal to the PSAP. Again no checking. This mean that the

> caller could quite literally be anywhere on Earth, but says he is in

> Toronto and the system will believe.

>

> If he is in Toronto, his ATA will get a DHCP 99/123 with that. If he is

> elsewhere on Earth, he will get a DHCP 99/123 with that information.



[AJW] Absolutely wrong. He can have a softphone and be where ever he wants to be and this is precisely the problem. You are not providing a means to stop this kind of malicious calling, or any means to trace the culprit. The solution does not provide any bar to entry for the would-be attacker and doesn't meet the requirements as I understand them to have been laid out. That is:

Location must be attributable and verifiable as belonging to a specific end-point at the time a specific call is made. Ci2, as currently proposed does do this.



<keep going>



> How can he be elsewhere on earth and get  DHCP 99/123 from Toronto?

> Because he cached it?

>

> > Where is the veracity provided in your solution because I can't see it.

>

> We are getting in the wild wet slide of 9-1-1 requires OBO...

> >

> > Canadian i2, says, VSP will send 911 call to the stage-1 routing proxy.

> Stage-1 routing proxy is only accessible by registered VSPs. Stage-1

> routing proxy uses IP address of the call to make a TRUSTED third-party

> request to the LIS for the caller's location

>

> Error here... the IP address is the key.  Will not work in many scenarios.

> This also requires that IP address be tied to a CIVIC in what is called

> the ILEC HOSTED LIS.  This means that we have to constantly upload the

> public IP addresses of all canadians just in case they call 9-1-1. This is

> a big privacy problem.

>

> > . The routing proxy then includes the location in-band to the PSAP or

> whatever exists between the routing proxy and the PSAP.

>

> ok

>

> > The trust in this case comes from the fact that there are only 5 stage-1

> routing proxies and they are run by the existing 911 service providers.

>

> Do I trust the ILEC with the IP addresses of all my customers?

>

> > Further more the call needs to have originated from a local ISP or the

> third-party request will fail.

>

> Why ?

[AJW] because if it does not, then the stage-1 routing proxy will fail to resolve to a known LIS and request will get default treatment. This sort of call can then be investigated.



>

> > Veracity not perfect, but certainly better than the other proposal.

> >

>

> How about adding digital signatures to DHCP 99/123 constructs that can

> flow through from the PSAP MSAG to the end-points and can get sent-back to

> the PSAP for authentication assessments?  I am thinking of MIME digital

> signatures of PIDF-LO constructs that can be stored in the memory of end-

> points and can be sent back to the PSAP via the relationship between the

> ILEC and the PSAP.

>

[AJW] As I have stated many times before, simply signing the location isn't good enough. You need to bind it to the device making the call, and you need to have a way of saying that the binding was still valid when the call was made. Quite frankly I don't believe that this can be done in any meaningful way using DHCP, and to the best of my knowledge I haven't seen any proposal (even draft ones) that show how it can be done. My question to you, is what is your aversion to doing this at the application layer and avoid having to change all the home routers in the path?



> And there will be no need that the ILEC provides a Hosted LIS and knows

> the identity of customers on the Internet that may never call 9-1-1 in

> their life.

[AJW] I am not a big fan of the ILEC hosted solution. As I understand it, it was in fact the ISPs that asked for such an option to exist. Quite frankly from my assessments any solution using this approach will require as much equipment in their networks as putting a LIS in will, so they may as well put the LIS in.



>

> This is way too much of a big brother database than what is the least

> acceptable.

>

> It will be fought in court.

>

> We need to re-state the concept of ECRIT as not requiring OBO... but trust

> between PSAPs and End-points.

[AJW] I disagree. I actually think that the right place to put the trust is between the ISP and the PSAP, and separate agreement exists between the end-point and the ISP. The ISP is then responsible for who he lets on to his network, and what they do when they are there.



>

> That requires digital signatures of PIDF-LOs.

>

> I've been saying so for the last couple of months to many people on the

> ECRIT list.  I think its time I do a real IETF draft on this.

[AJW] version 1.0 of HELD (5 or is it 6 years ago) had signed PIDF-LOs. Check out http://tools.ietf.org/html/draft-thomson-geopriv-location-dependability-04 it has been around for a very long time.

I will restress my position however, that I think ECRIT Direct and Trusted third-party requests is the right approach for emergency calling.



>

> Any people think its a bad idea?

>

> -=Francois=-

>

> > Cheers

> > James

> >

> >

>