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?
Joey@miscreant.org 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
Joey@miscreant.org 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" <br@brianrosen.net> 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" <rbarnes@bbn.com> 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" <mlinsner@cisco.com> 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" <br@brianrosen.net> 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" <Martin.Dawson@andrew.com>
>>>>> 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: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On
>>>>>> Behalf Of
>>>>>> Hannes Tschofenig
>>>>>> Sent: Tuesday, 27 October 2009 8:23 AM
>>>>>> To: ecrit@ietf.org
>>>>>> 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: geopriv-bounces@ietf.org
>>>>>>> [mailto:geopriv-bounces@ietf.org] On Behalf Of Rosen, Brian
>>>>>>> Sent: 26 October, 2009 23:10
>>>>>>> To: geopriv@ietf.org
>>>>>>> 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
>>>>>>> Geopriv@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/geopriv
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Ecrit mailing list
>>>>>> Ecrit@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>
>>>>>> _______________________________________________
>>>>>> Ecrit mailing list
>>>>>> Ecrit@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Ecrit mailing list
>>>>> Ecrit@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> Ecrit mailing list
>>> Ecrit@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ecrit
>>
>
>
_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit
