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

["DRAGE, Keith (Keith)" <drage at alcatel-lucent.com>]

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