support the suggested mechanism in the draft. Existence of the document
describing the mechanism doesn't force PSAP policy.
I personally would like to see some PSAPs and/or PS jurisdictions line up
behind the draft before it proceeds, but I don't see any harm in it going
forward.
Of course, I'm dreaming about this special place where a PSAP actually wants
to enable communication with all their customers and not force them to be a
member of a special club.
[non-chair hat on]
-Marc-
On 10/29/09 2:35 PM, "Brian Rosen" <br@brianrosen.net> wrote:
> Thank you. That is what I meant, and you said it better than I was going
> 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
