Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered

["Elwell, John" <[e-mail]>]

Brian,

So suppose my SIP-PBX is in the UK and uses a VoIP service provider in the UK. I am in a hotel in the US and make an emergency call using a device that uses my SIP-PBX in the UK as its outbound proxy. From the location determined by my device, the call needs to go to a PSAP in the US. Will routing via the UK service provider really help? It seems unlikely that the UK service provider would have an arrangement with a US PSAP. So perhaps the UK provider could route it on to a US provider, which hopefully would have such an arrangement. This round-about routing seems to increase the chances of failure.

It seems what is really needed in this situation is either:
- routing directly from the SIP-PBX in the UK to the US PSAP; or
- my device sends the call directly to the US PSAP.

John

> -----Original Message-----
> From: Brian Rosen [mailto:[e-mail]]
> Sent: 30 October 2009 14:07
> To: Elwell, John; Marc Linsner
> Cc: [e-mail]
> Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct
> considered
>
> Well, yes.
>
> Normally, your SIP-PBX would route calls outside the domain
> to some kind of
> carrier.  That is what I want it to do, but I can foresee
> circumstances
> where the PBX sends calls to the ESRP.  I would like the ESRP
> to know about
> the PBX (that is, have it's identity in some list it has, one way or
> another, so that when it lowers priority of calls from
> unknown sources,
> those calls are not lowered.  I think such arrangements will
> be uncommon,
> but possible.
>
> Brian
>
>
> On 10/29/09 5:28 AM, "Elwell, John"
> <[e-mail]>
> wrote:
>
> > Brian,
> >
> > Just a question for clarification below:
> >
> >> -----Original Message-----
> >> From: [e-mail] [mailto:[e-mail]]
> >> On Behalf Of Brian Rosen
> >> Sent: 29 October 2009 03:18
> >> To: Marc Linsner
> >> Cc: [e-mail]
> >> Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct
> >> considered
> >>
> >> I'm not worried about security by obscurity.  I don't want
> >> phones (or other
> >> devices) built to call directly.
> >>
> >> -phonebcp says "send the call on your normal outbound call
> >> path".  That's
> >> what I want it to say, and I don't want it to say "send it
> >> direct, bypass
> >> your service provider.
> > [JRE] So if my normal outbound call path is my SIP-PBX,
> then the SIP-PBX can
> > route directly to the PSAP?
> >
> > John
> >
> >
> >>
> >> I'm not stopping attack, I am stopping abuse.
> >>
> >> I don't want devices that are not subscribed to services to
> >> be able to make
> >> emergency calls (that is, if they can't make "normal" calls,
> >> they should not
> >> be able to make emergency calls).
> >>
> >> Brian
> >>
> >>
> >> On 10/28/09 6:51 PM, "Marc Linsner" <[e-mail]> wrote:
> >>
> >>> Brian,
> >>>
> >>> What I hear you saying: 'if we don't document how to spoof
> >> a PSAP, then
> >>> nobody will figure it out.'  Isn't that a little short sighted?
> >>>
> >>> [e-mail] will figure out how to establish a SIP
> >> session with any
> >>> PSAP in the world within 10 minutes of that PSAP being
> >> accessible via the
> >>> Internet, regardless of documentation.
> >>>
> >>> I believe there's more harm created in not documenting this for
> >>> John.Q.Public@ordinary_citizen.com.
> >>>
> >>> Granted, nobody here is looking to cause harm to a PSAP.  But
> >>> [e-mail] can certainly expend public safety
> >> resources by reporting
> >>> a bomb threat to a local school.  Should we require that
> >> all SIP calls to
> >>> the local school come from a trusted SP?  Where does it end?
> >>>
> >>> This isn't the way to deal with spam.
> >>>
> >>> -Marc-
> >>>
> >>>
> >>>
> >>> On 10/27/09 11:00 AM, "Brian Rosen" <[e-mail]> wrote:
> >>>
> >>>> The first goal is to prevent bad calls.
> >>>>
> >>>> The second goal is to indentify the source of the bad calls.
> >>>>
> >>>> I'm starting with the first goal.  I don't want you to be
> >> able to take a
> >>>> device out of a box, plug it into a network, and have the
> >> only call you can
> >>>> make be an emergency call.  I want the device to actually
> >> "work" (as in be
> >>>> able to place calls to all the entities that it was
> >> intended to) first, and
> >>>> then be able to place emergency calls.
> >>>>
> >>>> Please spend some time in a PSAP while a kid with a
> >> simless phone has "fun"
> >>>> with it.  Imagine how much fun the test mechanism is as
> >> opposed to placing
> >>>> real calls.
> >>>>
> >>>> If we somehow get a bad call, we need to send the cops.
> >> That means we need
> >>>> an identity (and a location).
> >>>>
> >>>> I think a good cert could be the basis of a good identity,
> >> if we could get
> >>>> one.  I don't see how we do that.
> >>>>
> >>>> Brian
> >>>>
> >>>>
> >>>> On 10/27/09 10:39 AM, "Richard Barnes" <[e-mail]> wrote:
> >>>>
> >>>>> Brian,
> >>>>>
> >>>>> Is the security goal here more access control (i.e.,
> >> controlling who
> >>>>> can send calls to a PSAP) or attribution/identification
> >> for post-hoc
> >>>>> action.
> >>>>>
> >>>>> If it's the latter, then ISTM that the problem can
> >> largely be reduced
> >>>>> to having a certificate infrastructure that binds authenticated
> >>>>> identities to real-world entities.  The "extended validation"
> >>>>> certificates that current commercial CAs issue seem to
> >> largely satisfy
> >>>>> this requirement.
> >>>>>
> >>>>> --Richard
> >>>>>
> >>>>>
> >>>>> On Oct 27, 2009, at 4:31 PM, Brian Rosen wrote:
> >>>>>
> >>>>>> Of course not all VSPs will have trust relationships with all
> >>>>>> PSAPs.  One
> >>>>>> can hope that long term, we can evolve to transitive trust
> >>>>>> relationships
> >>>>>> that work pretty well cross border.
> >>>>>>
> >>>>>> The emergency guys are actually terrified of private/individual
> >>>>>> domains
> >>>>>> sending them calls, and we're telling them we expect that to be
> >>>>>> possible,
> >>>>>> but rare, and we're giving them mechanisms that will
> effectively
> >>>>>> allow them
> >>>>>> to turn off calls selectively, based on factors including what
> >>>>>> domain the
> >>>>>> call comes from.  They expect that such calls will be
> one of the
> >>>>>> loopholes
> >>>>>> where they get equivalents to sim-less calls, which drive them
> >>>>>> nuts.  They
> >>>>>> don't want ANY calls that don't come from service providers,
> >>>>>> although they
> >>>>>> seem to be okay with the notion that the SP may not have great
> >>>>>> identity (AOL
> >>>>>> being a poster child).  So, while indeed they
> >> understand, and have
> >>>>>> concerns
> >>>>>> about having to take calls from Sierra Leone VoIP
> >> services Pty, they
> >>>>>> would
> >>>>>> much rather have a call that went through them then a
> >> call that went
> >>>>>> through
> >>>>>> no service provider at all.
> >>>>>>
> >>>>>> I'm not trying to make calls direct from devices or
> >> private domains
> >>>>>> impossible, but I think the notion that we're
> promoting them is a
> >>>>>> very bad
> >>>>>> idea until we have effective mechanisms to prevent abuse.
> >>>>>>
> >>>>>> Brian
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On 10/27/09 9:02 AM, "Marc Linsner" <[e-mail]> wrote:
> >>>>>>
> >>>>>>> Brian,
> >>>>>>>
> >>>>>>> I'm a little confused.  I don't remember you objecting to
> >>>>>>> requirement RE1
> >>>>>>> from RFC5012 and I remember your use case about a
> >> Sierra Leone VSP.
> >>>>>>>
> >>>>>>> Are you implying that *all* VSPs will have a trust
> relationships
> >>>>>>> with *all*
> >>>>>>> PSAPs?
> >>>>>>>
> >>>>>>> What is the difference between a call coming from a private/
> >>>>>>> individual
> >>>>>>> domain (as in not a commercial VSP) and a VSP on the
> >> other side of
> >>>>>>> the world
> >>>>>>> (outside the jurisdiction)?
> >>>>>>>
> >>>>>>> I'm trying to figure out whether you're objecting to anonymous
> >>>>>>> calls to the
> >>>>>>> PSAP or the mechanisms proposed in this draft?
> >>>>>>>
> >>>>>>> [Don't take this as my endorsement of the draft, as I'm
> >> not sure I
> >>>>>>> agree
> >>>>>>> with UAs registering with the ESRP.]
> >>>>>>>
> >>>>>>> -Marc-
> >>>>>>>
> >>>>>>>
> >>>>>>> On 10/26/09 8:59 PM, "Brian Rosen" <[e-mail]> wrote:
> >>>>>>>
> >>>>>>>> First of all, I put it on the wrong email list, sorry
> >> about that.
> >>>>>>>>
> >>>>>>>> Then, we have carefully arranged it so that there is
> >> no identity
> >>>>>>>> coming from
> >>>>>>>> the access network provider, and because the
> location is coming
> >>>>>>>> from that
> >>>>>>>> provider, we really don't want to.  But even if we
> >> did, we would
> >>>>>>>> need a
> >>>>>>>> really good identifier, and there isn't one.
> >>>>>>>>
> >>>>>>>> The problem we have with -direct is anonymous callers,
> >> and if they
> >>>>>>>> have any
> >>>>>>>> option, they would also be location-less.  Until and
> >> unless we get
> >>>>>>>> rid of
> >>>>>>>> anonymity, we can't encourage service provider-less
> calls.  The
> >>>>>>>> draft does
> >>>>>>>> not make any provision to provide any kind of identity.  Many
> >>>>>>>> networks
> >>>>>>>> (think free wifi for example) would make providing
> >> good identity
> >>>>>>>> difficult.
> >>>>>>>>
> >>>>>>>> The fact is that there is a SERVICE provider in nearly
> >> all of the
> >>>>>>>> communications systems.   The SERVICE provider is in a
> >> position to
> >>>>>>>> assist
> >>>>>>>> the emergency calling system when it needs more information.
> >>>>>>>> That's what a
> >>>>>>>> good SERVICE provider does.  Cutting them out is not a great
> >>>>>>>> idea.  Most of
> >>>>>>>> the attempts to provide real time communications
> between people
> >>>>>>>> have evolved
> >>>>>>>> to using service providers, even when there were
> >> alternatives.  File
> >>>>>>>> transfer via something like Torrent is a
> counterexample (which
> >>>>>>>> isn't real
> >>>>>>>> time), but even there, you end up with service
> >> providers like The
> >>>>>>>> Pirate Bay
> >>>>>>>> (R.I.P) to provide introduction services.  I don't
> think we're
> >>>>>>>> going to see
> >>>>>>>> changes that eliminate service providers, and in this
> >> case, they
> >>>>>>>> provide
> >>>>>>>> value to the emergency calling systems.  All of the emergency
> >>>>>>>> professionals
> >>>>>>>> I know have issues with service providers, but they
> would react
> >>>>>>>> with horror
> >>>>>>>> if you suggested cutting them out.  Ask them, please.
> >>>>>>>>
> >>>>>>>> So, I claim you have a solution in search of a
> >> problem.  We have
> >>>>>>>> solved the
> >>>>>>>> "calling network isn't the access network" problem
> >> already.  Service
> >>>>>>>> providers ARE in the path now, in nearly every case
> (in fact a
> >>>>>>>> counter
> >>>>>>>> example escapes me, although there probably are some).
> >>  There is
> >>>>>>>> no movement
> >>>>>>>> I can detect which would change that any time soon; quite the
> >>>>>>>> opposite.  We
> >>>>>>>> have a known killer problem without some kind of
> >> subscription to a
> >>>>>>>> service
> >>>>>>>> that provides a good identity, for which you provide
> >> no answers.
> >>>>>>>> We have
> >>>>>>>> experience with the killer problem: sim-less calling
> >> was supposed
> >>>>>>>> to provide
> >>>>>>>> a way to make an emergency call in exactly the kinds of
> >>>>>>>> circumstances you
> >>>>>>>> are describing.  Our real world experience is that
> you create a
> >>>>>>>> huge problem
> >>>>>>>> that diverts resources from helping people to chasing
> >> scammers and
> >>>>>>>> flea-market sellers.
> >>>>>>>>
> >>>>>>>> Nothing is perfect: you can get a AIM screen name
> >> without a very
> >>>>>>>> good
> >>>>>>>> identity for example.  However, the notion that
> we're going to
> >>>>>>>> provide
> >>>>>>>> direct access without a service provider deliberately,
> >> especially
> >>>>>>>> without
> >>>>>>>> really good identity from the access network is, in my
> >> opinion not
> >>>>>>>> only a
> >>>>>>>> no, it's a heck no.  I'll line up as many emergency service
> >>>>>>>> professionals as
> >>>>>>>> you would like to tell you this is a harmful idea.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On 10/26/09 7:56 PM, "Dawson, Martin"
> >> <[e-mail]>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> I am glad this has come up. It's a debate that has to
> >> happen if
> >>>>>>>>> we are to
> >>>>>>>>> move
> >>>>>>>>> beyond a long standing legacy misconception.
> >>>>>>>>>
> >>>>>>>>> In the circuit service world - whether it was POTS or
> >> mobile, the
> >>>>>>>>> access
> >>>>>>>>> network had full responsibility for delivering the emergency
> >>>>>>>>> call. In that
> >>>>>>>>> world, routing an emergency call meant getting a circuit
> >>>>>>>>> established to the
> >>>>>>>>> correct call center. In most parts of the world,
> this was done
> >>>>>>>>> using the
> >>>>>>>>> regional part of the PSTN to switch the circuit to a
> >> call center
> >>>>>>>>> on the
> >>>>>>>>> PSTN.
> >>>>>>>>> In some jurisdictions, such as the US, it was done
> >> directly from
> >>>>>>>>> the local
> >>>>>>>>> exchange carrier to the call center. Either way,
> there was no
> >>>>>>>>> third party
> >>>>>>>>> involved.
> >>>>>>>>>
> >>>>>>>>> Now we have the Internet. We still have public
> access network
> >>>>>>>>> providers.
> >>>>>>>>> They
> >>>>>>>>> switch packets onto the Internet for their
> >> subscribers. They can
> >>>>>>>>> similarly
> >>>>>>>>> ensure that packets reach the local emergency call centers.
> >>>>>>>>>
> >>>>>>>>> The fact is that there was no equivalent of a VSP in the
> >>>>>>>>> traditional
> >>>>>>>>> environment. VoIP is a presence service, and it had
> no common
> >>>>>>>>> equivalent in
> >>>>>>>>> the PSTN world. It could have, but the narrowband state of
> >>>>>>>>> technology and
> >>>>>>>>> the
> >>>>>>>>> common market use cases didn't support its
> development. By the
> >>>>>>>>> time ISDN
> >>>>>>>>> arrived, the PSTN had already slipped into its
> >> palliative stage
> >>>>>>>>> without
> >>>>>>>>> realizing it.
> >>>>>>>>>
> >>>>>>>>> It's an entrenched misconception that because the
> >> circuit service
> >>>>>>>>> provided
> >>>>>>>>> by
> >>>>>>>>> exchange carriers was most commonly used for
> "voice" (but, it
> >>>>>>>>> should be
> >>>>>>>>> noted,
> >>>>>>>>> also for fax, telex, tty, security system monitoring
> >> and, even,
> >>>>>>>>> IP data)
> >>>>>>>>> that
> >>>>>>>>> VSPs are somehow equivalent to exchange carriers.
> >> They are not.
> >>>>>>>>>
> >>>>>>>>> Indeed, involving VSPs in emergency calls is the Internet
> >>>>>>>>> equivalent of
> >>>>>>>>> involving long distance providers in POTS emergency
> >> calls. They
> >>>>>>>>> are neither
> >>>>>>>>> necessary nor particularly helpful; they can't be
> >> guaranteed to
> >>>>>>>>> be within
> >>>>>>>>> the
> >>>>>>>>> emergency jurisdiction; depending on them actually
> >> diminishes the
> >>>>>>>>> efficacy
> >>>>>>>>> of
> >>>>>>>>> emergency service access. It does not help the caller, the
> >>>>>>>>> emergency
> >>>>>>>>> service,
> >>>>>>>>> nor the third party to insist on the third party's
> >> involvement.
> >>>>>>>>>
> >>>>>>>>> It can't be helped if you have over sold the benefits of VSP
> >>>>>>>>> involvement to
> >>>>>>>>> yourself and others Brian. It is time to have a
> >> reasoned debate.
> >>>>>>>>> From my
> >>>>>>>>> perspective, the argument that there is no "subscription"
> >>>>>>>>> involved is
> >>>>>>>>> patently
> >>>>>>>>> false. There has to be a subscription of some description in
> >>>>>>>>> order to get to
> >>>>>>>>> the Internet. Yes, there is free public Internet
> >> access (just as
> >>>>>>>>> there are
> >>>>>>>>> free courtesy phones on the PSTN and free access to
> emergency
> >>>>>>>>> services from
> >>>>>>>>> pay phones. All these services are still connected to
> >> the public
> >>>>>>>>> Internet
> >>>>>>>>> infrastructure and they all represent an "operator"
> with some
> >>>>>>>>> level of
> >>>>>>>>> information about the caller.
> >>>>>>>>>
> >>>>>>>>> With the over-emphasis on VSPs, what is missing
> from the ECRIT
> >>>>>>>>> and i3 models
> >>>>>>>>> is the direct interface for querying the access network for
> >>>>>>>>> subscriber data
> >>>>>>>>> (should it prove necessary). These models need to
> >> take the long
> >>>>>>>>> view of how
> >>>>>>>>> emergency calling is done in the Internet age; they
> >> should not be
> >>>>>>>>> protracting
> >>>>>>>>> an unnecessary reliance on VSPs.
> >>>>>>>>>
> >>>>>>>>> I have deleted the premature and prejudicial text from the
> >>>>>>>>> subject heading.
> >>>>>>>>> And I'll leave this on ECRIT as the most appropriate WG.
> >>>>>>>>>
> >>>>>>>>> Cheers,
> >>>>>>>>> Martin
> >>>>>>>>>
> >>>>>>>>> -----Original Message-----
> >>>>>>>>> From: [e-mail]
> >> [mailto:[e-mail]] On
> >>>>>>>>> Behalf Of
> >>>>>>>>> Hannes Tschofenig
> >>>>>>>>> Sent: Tuesday, 27 October 2009 8:23 AM
> >>>>>>>>> To: [e-mail]
> >>>>>>>>> Subject: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct
> >>>>>>>>> considered harmful,
> >>>>>>>>> at least given our current experiences
> >>>>>>>>>
> >>>>>>>>> FYI: feedback from Brian regarding a recent ECRIT
> >> contribution.
> >>>>>>>>>
> >>>>>>>>>> -----Original Message-----
> >>>>>>>>>> From: [e-mail]
> >>>>>>>>>> [mailto:[e-mail]] On Behalf Of Rosen, Brian
> >>>>>>>>>> Sent: 26 October, 2009 23:10
> >>>>>>>>>> To: [e-mail]
> >>>>>>>>>> Subject: [Geopriv] Winterbottom-ecrit-direct considered
> >>>>>>>>>> harmful, at least given our current experiences
> >>>>>>>>>>
> >>>>>>>>>> The notion behind -direct is to not use a service
> provider to
> >>>>>>>>>> place an emergency call.  Instead, the device
> registers with
> >>>>>>>>>> an Emergency Services Routing Proxy immediately before the
> >>>>>>>>>> call and the call is routed directly from the device
> >> to the ESRP.
> >>>>>>>>>>
> >>>>>>>>>> At least at the moment, this is an exceedingly bad idea.
> >>>>>>>>>>
> >>>>>>>>>> Emergency calling authorities like service
> providers, a lot.
> >>>>>>>>>> They like them because they can hold them
> >> accountable, and the
> >>>>>>>>>> service providers don't like theft of service, which is
> >>>>>>>>>> something the emergency call guys have an analog to.
> >>>>>>>>>>
> >>>>>>>>>> The facts are that where unaccountable access to emergency
> >>>>>>>>>> calling is allowed, huge numbers of false calls
> >> occur, with no
> >>>>>>>>>> way to stop them, and no way to tell the good ones from the
> >>>>>>>>>> bad ones.  This has been seen multiple times where
> so called
> >>>>>>>>>> "simless" or "unauthenticated" calls are allowed.
> >>>>>>>>>>
> >>>>>>>>>> -direct precisely duplicates simless calling.  The only
> >>>>>>>>>> "registration" is an emergency registration, only emergency
> >>>>>>>>>> calls are allowed, any device can make an emergency call if
> >>>>>>>>>> all it has is a (radio) connection to any network.
> >>>>>>>>>> We can predict, with a very high degree of
> >> certainty, that the
> >>>>>>>>>> feature will be horribly abused: for example to test that a
> >>>>>>>>>> phone without a service plan works.
> >>>>>>>>>>
> >>>>>>>>>> There have been studies which show tens of thousands of bad
> >>>>>>>>>> calls with zero good ones.  Nearly every authority I know
> >>>>>>>>>> where the regulator has insisted on simless
> calling wants it
> >>>>>>>>>> repealed.  There is one counter example I know
> where the fact
> >>>>>>>>>> that they got a couple, literally, of good calls among the
> >>>>>>>>>> tens of thousands of bad calls was considered enough
> >> reason to
> >>>>>>>>>> put up with the problem.
> >>>>>>>>>>
> >>>>>>>>>> Service providers give us information that may be useful: a
> >>>>>>>>>> subscriber name and address for example, which is not
> >>>>>>>>>> spoofable by the caller.  They have ways to trace callers,
> >>>>>>>>>> especially bad callers.  They don't want their
> systems abused
> >>>>>>>>>> any more than the emergency calling authorities do.
> >>>>>>>>>>
> >>>>>>>>>> This is a bad idea.  A very bad idea.  Please stop it.
> >>>>>>>>>>
> >>>>>>>>>> Someday, we may have better ways to prevent abuse. Until we
> >>>>>>>>>> do, service providers are a good thing on an
> emergency call.
> >>>>>>>>>> We don't want them cut out.
> >>>>>>>>>>
> >>>>>>>>>> Brian
> >>>>>>>>>>
> >>>>>>>>>> _______________________________________________
> >>>>>>>>>> Geopriv mailing list
> >>>>>>>>>> [e-mail]
> >>>>>>>>>> https://www.ietf.org/mailman/listinfo/geopriv
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> _______________________________________________
> >>>>>>>>> Ecrit mailing list
> >>>>>>>>> [e-mail]
> >>>>>>>>> https://www.ietf.org/mailman/listinfo/ecrit
> >>>>>>>>>
> >>>>>>>>> _______________________________________________
> >>>>>>>>> Ecrit mailing list
> >>>>>>>>> [e-mail]
> >>>>>>>>> https://www.ietf.org/mailman/listinfo/ecrit
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> _______________________________________________
> >>>>>>>> Ecrit mailing list
> >>>>>>>> [e-mail]
> >>>>>>>> https://www.ietf.org/mailman/listinfo/ecrit
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> Ecrit mailing list
> >>>>>> [e-mail]
> >>>>>> https://www.ietf.org/mailman/listinfo/ecrit
> >>>>>
> >>>>
> >>>>
> >>>
> >>>
> >>
> >>
> >> _______________________________________________
> >> Ecrit mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/ecrit
> >>
>
>
>