Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered

["Elwell, John" <john.elwell at siemens-enterprise.com>]

Brian,

Just a question for clarification below:

> -----Original Message-----
> From: ecrit-bounces at ietf.org [mailto:ecrit-bounces at ietf.org]
> On Behalf Of Brian Rosen
> Sent: 29 October 2009 03:18
> To: Marc Linsner
> Cc: ecrit at 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 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
> >>>
> >>
> >>
> >
> >
>
>
> _______________________________________________
> Ecrit mailing list
> Ecrit at ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit
>