Re: [Ecrit] Nomadic VOIP is dead

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

Hi Francois,



Please read the ECRIT Direct draft. It does not require a SIP Proxy in the ISP.



Other comments inline.



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

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

> Sent: Tuesday, 24 November 2009 1:08 PM

> To: Winterbottom, James

> Cc: ecrit

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

>

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



[AJW] Let me see. If the emergency service provider requests the location information directly from the source, versus trusting location that has traversed and end-point, that as you continually point out could have been downloaded from an open source site and modified. Hmmm!! Do you really see these as being the same? I know I don't.

>

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

[AJW] I know you don't. If you did you wouldn't be saying what you are saying. There is absolutely nothing stopping him from adding whatever location he wants either directly into the device itself, or through the DHCP server. There is no control in this case, and no means to check veracity, and no bar to entry. Quite frankly anyone proposing this as a serious solution has really not assessed the risks. The regulators that I have spoken to will not support a proposal of this nature.





>

> Ci2 only bases its finding on the public IP address of the Call.  If I am

> behind VPN, we're toast.

[AJW] Actually you might not be. The onus is on the VPN server end to ensure that you get proper connectivity for the applications you want to use.



>

> Say I am VPNing to my home and using my SIP PBX at home... which I do by

> the way ;)

[AJW] So perhaps nomadic VoIP is not as dead as you might be professing... ;)



>

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

[AJW] Certainly when I was at the RIPE meeting a couple of months ago ARIN and the APNIC guys seemed to think that this type of problem was far from insurmountable. I don't propose to have a solution here, but those people that manage the database seemed to think that it could be solved.



>

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

[AJW] This is not actually a new requirement it is a core requirement. The you refers to the entity providing the location, and the entity ultimately using the location to provide a service.

>

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

[AJW] Since for reasons previously stated there is no way in your proposal to disseminate between the two, this split hair proposal that I think has very little merit. Either you can verify it, or the solution can't, if you can't, then you should assume that it as user entered.



>

> I did not read this as being a requirement of ECRIT to deny end-to-end

> 'user-sent but not user-inputted location'.

>

[AJW] I was under the impression that we were debating Ci2 and not ECRIT. Having said that, I believe that without a means to check location veracity that a lot of regions will be reluctant to deploy what is currently being proposed.





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

>

[AJW] I would argue that IETF specifications are peer to peer, rather than end to end per say. Consequently a Trusted Third-party location request is peer to peer and so quite acceptable.



> Show me an OBO that will actually work and will preserve privacy.  Ci2

> doesn't do any of these two basic criterias.

>

[AJW] It is for exactly this reason that the term OBO is no longer used. It is Trusted third-party, and the onus is on the trusted entity, and rules associated with that trust relationship.



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

[AJW] As an original designer of HELD I can state quite categorically that you are wrong. HELD was absolutely designed with this in mind. You might also care to look at: http://www.nena.org/standards/technical/voip/location-determination-ip-based-emergency-services



>

> I am not even sure there is a current IETF draft which explains how to use

> HELD or BEEP for that.

http://tools.ietf.org/html/draft-thomson-geopriv-held-beep-05



>

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

>

[AJW] See above, this is not what is being described at all.





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

>

[AJW] Let's agree to disagree on this point. The ISP is providing service within the jurisdiction of a PSAP. Ci2, as I understand it, proposes that if the ISP has a LIS, that the Stage-1 routing proxy has a VPN connection to the LIS over which third-party requests are made. How can this VPN be established without a trust agreement being in place?



> There is no relationship between the ISP and the PSAP.  One only exists

> between the ISP and MaBell as an agent of the PSAPs.

[AJW] If Bell is operating as the agent for the PSAP then it is still representing the PSAP is it not?



>

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

[AJW] This is not true if the ISP elects to run the LIS. Also what you are not making clear, is that if the ISP runs a LIS there is nothing that stops the ISP from making this location available to end-points so that they can use it. The only thing that Ci2 says is that for now we won't use device-provided location for emergency calling because we have no way to test it veracity. These all seem very reasonable approaches to me.



>

> This is the OBO proposal we have in Canada before the regulator.  it will

> be fought in court if ever mandated.

[AJW] That would be a pity and certainly not in the best interests of the public.

>

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

[AJW] I don't understand what you are trying say here. My point is that calls that come with location that cannot be validated may get a completely different call handling procedure to those that can be verified. Providing a single consistent means to verify location means that this can be done much more efficiently.



>

> -=Francois=-

>