Nor does my smart fridge, nor will a whole range of devices quite capable of transmitting speech over IP connections. I want these to be able to make emergency calls if they need to.
We are not in competition, you want to remain in a legacy world with VSPs, fine, I want to move past that. Emergency networks are not an add-on to standards call networks, they are their own network and application.
Cheers
James
> -----Original Message-----
> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of
> Brian Rosen
> Sent: Thursday, 29 October 2009 2:18 PM
> 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.
>
> 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
