Re: [Ecrit] Nomadic VOIP is dead

[Francois D. Menard <[e-mail]>]

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

How is that different from end-to-end location download in the end-point then?

If the veracity check is not done at call time, how is veracity is being assessed?
> 
> > 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.


How are softphones  different from ATAs?

If he is in Singapour, he will get an IP address from Singapour, and thus will get an DHCP location from Singapour.

I do not see your point at all.

Ci2 only bases its finding on the public IP address of the Call.  If I am behind VPN, we're toast.

Say I am VPNing to my home and using my SIP PBX at home... which I do by the way ;)

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

It will also fail in the case where an ISP is using a block of IP addresses of another ISP, where it is impossible to register something in ARIN.

There are lots of blocks out there that are not 'clean'.

This issue of involving ARIN has been over simplified by the ILECs in Canada.

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

OK, there is this new requirement 'you need to have a way to say that the binding is valid at E-9-1-1 call time'

In your statement, who is the entity referred to as 'you'.

The ISP? The PSAP? The End-User?

Our proposed legal requirement is not to have 'user-inputted' location.  There is no legal requirement for disallowing 'user-sent location if not user-inputted'.

I did not read this as being a requirement of ECRIT to deny end-to-end 'user-sent but not user-inputted location'.

OBO is not end-to-end.  All IETF standards are supposed to be end-to-end.

Show me an OBO that will actually work and will preserve privacy.  Ci2 doesn't do any of these two basic criterias.

a) if it is based on a public IP address it will not work all the time
b) if it is based on a Hosted LIS, which will contain all public IP addresses, it will not work period.

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


Ci2 requires a LIS at the ILEC as well as a LIS at the ISP called a Location Determination Platform.  LDP LIS.

Ci2 requires LIS to LIS communications utilizing HELD. HELD was never designed for that.

I am not even sure there is a current IETF draft which explains how to use HELD or BEEP for that.

An ISP LIS is to communicate to an ILEC LIS to retrieve location.

This location could actually come over RADIUS and the wiremap only reside in the ISP LIS.

If you really want OBO, the only other option that I can see is to force VoIP end-users to utilize a SIP PROXY that belongs to the ISP rather than one of the VoIP service provider and get into technical ITMPs (Internet Traffic Management Practices).   This way, no VoIP is allowed unless granted by an ISP SIP PROXY where the OBO can be assessed by the ISP.

This seems to me as adverse to net neutrality. 

It would be better to make end-to-end work.

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

There is no option for such trust to exist in Ci2.

There is no relationship between the ISP and the PSAP.  One only exists between the ISP and MaBell as an agent of the PSAPs.

MaBell is requiring ISPs to divulge the public IP addresses of all subscribers 24/7 just in case an E9-1-1 call ever gets made.

This is the OBO proposal we have in Canada before the regulator.  it will be fought in court if ever mandated. 

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

Thanks for the pointer. 

I fail to understand how signed PIDF-LO's, i.e. location objects that the PSAP can reconcile at call time, as being MSAG-VALID, and failing to reconcile at call time, can issue a dispatch knowing that it may take a chance... do not make such information exchange 'trustable'.

-=Francois=-