to.
We may also have some transitive relationships: that is, if there is a
"local" PSAP that trusts that they have done so, other PSAPs may trust that
they have done so.
Brian
On 10/29/09 11:48 AM, "DRAGE, Keith (Keith)" <drage@alcatel-lucent.com>
wrote:
> I suspect that what Brian is saying is that anyone can be a service provider
> (or whatever else you want to call it) in this case provided that:
>
> 1) they make that agreement with the PSAP providers they route calls to;
>
> 2) they authenticate the calls requests to a level of security that meets
> the PSAPs (and any legal) requirements;
>
> 3) the PSAP trusts that they have done so.
>
> While this would normally be what we would understand as public
> telecommuncation operators, it doesn't mean they have to be.
>
> regards
>
> Keith
>
>> -----Original Message-----
>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]
>> On Behalf Of Marc Linsner
>> Sent: Thursday, October 29, 2009 12:32 PM
>> To: Brian Rosen
>> Cc: ecrit@ietf.org
>> Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct
>> considered
>>
>> Brian,
>>
>> Please define what you consider to be a service provider.
>>
>> Is Skype a service?
>> Is Jabber a service?
>> Is Google Voice a service?
>> Is mydomain.com hosted on a commercial site a service?
>> Is mydomain.com hosted on a home server a service?
>> Is myEnterpriseVoIP.com a service?
>>
>> So, what you are saying that if I can make calls via all of
>> the above, it's OK for all of the above to contact an ESRP?
>>
>> Are you requiring that I have a full-time proxy on-line for
>> mydomain.com or can I simply run a transient UA and dynamic DNS?
>>
>> -Marc-
>>
>>
>>
>> On 10/28/09 11:17 PM, "Brian Rosen" <br@brianrosen.net> wrote:
>>
>>> 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.
>>>
>>> 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" <mlinsner@cisco.com> 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?
>>>>
>>>> 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
>>
_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit
