[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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 at 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 at 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 at 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 at ordinary_citizen.com.
>> 
>> Granted, nobody here is looking to cause harm to a PSAP.  But
>> Joey at 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 at 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 at 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 at 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 at 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 at 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 at ietf.org [mailto:ecrit-bounces at ietf.org] On
>>>>>>>> Behalf Of
>>>>>>>> Hannes Tschofenig
>>>>>>>> Sent: Tuesday, 27 October 2009 8:23 AM
>>>>>>>> To: ecrit at 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 at ietf.org
>>>>>>>>> [mailto:geopriv-bounces at ietf.org] On Behalf Of Rosen, Brian
>>>>>>>>> Sent: 26 October, 2009 23:10
>>>>>>>>> To: geopriv at 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 at ietf.org
>>>>>>>>> https://www.ietf.org/mailman/listinfo/geopriv
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> Ecrit mailing list
>>>>>>>> Ecrit at ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> Ecrit mailing list
>>>>>>>> Ecrit at ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>> 
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> Ecrit mailing list
>>>>>>> Ecrit at ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> Ecrit mailing list
>>>>> Ecrit at ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>> 
>>> 
>>> 
>> 
>> 
> 
>