that case and the direct case?
On Oct 29, 2009, at 11:28 AM, Elwell, John wrote:
> Brian,
>
> Just a question for clarification below:
>
>> -----Original Message-----
>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]
>> On Behalf Of Brian Rosen
>> Sent: 29 October 2009 03:18
>> To: Marc Linsner
>> Cc: ecrit@ietf.org
>> 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" <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
_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit
