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

[Brian Rosen <br at brianrosen.net>]

There is no doubt that the PSAPs care about the access provider, because the
access provider is responsible for location.  They want a good identity from
that location provider, and they want the data that it provides to have some
kind of integrity protection.

It is an advantage that the access provider is local.

However, calls don't come from access providers, they come from service
providers who provide some sort of real time two way media session service
(recognizing that often the access network and the SP that provides the
calling service are the same entity).  That's the SP we're talking about.

Unlike the calling network, where there is at least a rudimentary
authentication system in place always, there are many access networks that
have no authentication at all, which gives rise to the abuse problem that
makes this idea not tenable.  There is no reason to believe that is going to
change.

I also point out, once again, that using the access network as the source of
authentication means that we are using an IP address as an identifier.  IP
addresses make lousy identifiers.  They are addresses, not identifiers.

Oh, one more thing about this idea:

It means that devices have to have a SIP stack, regardless of what they
actually use to place calls.   That's okay for some devices, but of course
there are many, many more devices and services that don't use SIP from the
device to the service provider.  It's one thing to say that the SP has to
gateway to SIP if its devices don't already speak SIP.  It's quite another
to say that every device has to be able to speak SIP for emergency calls
regardless of what it uses for everything else.  There would be similar
daunting problems for codecs.






On 10/30/09 9:18 PM, "Dawson, Martin" <Martin.Dawson at andrew.com> wrote:

> Hey Brian,
> 
> Maybe if you keep saying "service provider" we'll all start believing it means
> "VSP" and it really does have some quintessential significance to emergency
> calling...
> 
> However, to quote Watto (Phantom Menace):
> 
>    "What? You think you're some kind of Jedi, waving your
>     hand around like that?"
> 
> :)
> 
> Sure PSAP providers like to have a "service provider" they can point their
> finger at. They like someone who might be a source of forensic information
> related to the source of nuisance calls. In particular, it's really useful if
> that provider is in the same jurisdiction that they are. That would be the 'I'
> SP rather than the 'V' SP that you keep trying to steer the focus back to.
> 
> Cheers,
> Martin
> -----Original Message-----
> From: ecrit-bounces at ietf.org [mailto:ecrit-bounces at ietf.org] On Behalf Of
> Brian Rosen
> Sent: Saturday, 31 October 2009 5:29 AM
> To: Marc Linsner
> Cc: ecrit at ietf.org
> Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered
> 
> I'm the messenger here.  PSAPs prefer service providers to be on the path of
> a call, and they have bad experiences when they aren't.
> 
> Given their experiences, I can't fault them.
> 
> The reason the text is in phonebcp is as you said it is: because "normal" is
> likely to work.  The fact that "normal" means SP path in 99.999% of cases
> gets the PSAPs what they want.  They don't care about why we did it, they
> care they get the right result.
> 
> I don't believe we are going to see vanity domains used on calls, and even
> if they were in "From", they won't be the domain in P-Asserted-Identity, or
> the SubjectAltName of the Identity signature.  If some service that used
> email addresses as identities sent us calls, the email address (with its
> domain) is the "userpart" of the identity, not the whole thing.  There are
> some interesting problems when you have URI to something like the MS IM
> systems.  The first "@' (br at brianrosen.net@msn.com) gets escaped.  We've
> built systems that handle that.
> 
> The Firewall/Session Border controls will have several criteria when PSAPs
> are overloaded, but AFAIK, no existing firewalls or SBCs do what you suggest
> other than the repeat offender rule, which is the first line of defense.
> They do filter based on criteria that equate to IP Address or Domain of the
> SP, which we can deal with.  We'll use what works for the other users of
> these systems, we're unlikely to be able to have emergency services special
> firewalls or SBCs.
> 
> In most cases we're going to have hard connections, or more likely VPNs from
> service providers to the ESInet routers.  That will probably handle 90+
> percent of calls, but we'll still have substantial numbers coming from the
> big I Internet.  We do want to know where they are coming from, and we will
> have SOME form of identity that we trust to separate those we know about
> from those we don't.
> 
> This is a percentages game.  Most of the time, calls will be accepted no
> matter how they get to the ESInet.  If you want your calls to get through
> when things are bad, send them the way you send all your other calls; that
> will work okay.  If you break that (by encouraging people to send them
> direct), then we'll have more problems.
> 
> I'm back to the basic tenet: if you can use the service to create media
> sessions to others, you can use it to send emergency calls, and we want the
> calls sent the same path (because it will work).  If you can't use the
> service (like, you can't register for one reason or another), we don't want
> you to be able to make emergency calls.
> 
> To be fair, there is at least one country I know of that doesn't agree.
> They have documented a small number of good calls in with the tens of
> thousands of bad ones, and think its worth it to handle the bad ones in
> order to get to the good ones.  Most PSAPs I know of don't.
> 
> And furthermore, there are some regulations around this that are nation
> specific, and I think we don't need the IETF to wade into trying to figure
> out how to meet those regulations.  In most cases, we don't really know how
> the regulator intends the regulations to cover devices on the Internet.
> 
> Brian
> 
> On 10/30/09 1:46 PM, "Marc Linsner" <mlinsner at cisco.com> wrote:
> 
>> Brian,
>> 
>> "Normal Call Path" was NOT added to phonebcp for the purpose of the
>> perceived security you describe.  The advantage (and the reason it's in
>> phonebcp) to using the normal call path is due to it being the most likely
>> mechanism to work.  Unused/untested mechanisms are more likely to fail when
>> tried for the first time verses mechanisms that are used/tested daily.
>> Emergency time is not the time to test a new mechanism, hence use the normal
>> call path, the same one you just used to call grandma, to summons emergency
>> assistance. (This is a negative against this proposed mechanism.)
>> 
>> If you are evangelizing within the PS community that 'sip:johnny at att.com' is
>> less of a threat than 'sip:johnny at vanitydomain.com', I suggest that is the
>> wrong message to be spreading. Please stop now. This will only lead to the
>> thousands of personal injury lawyers making big $$ at the expense of the PS
>> community.
>> 
>> As you are intimately aware, there are millions of 'vanity' domains in use
>> and it's growing. Its growing not just in the individual market, but in the
>> small/medium business market. You also know there are thousands of hosting
>> companies providing services to the owners of vanity domains (email, web,
>> ftp, etc.).  I expect in the near future that hosting providers will add sip
>> proxy services to their list of wares.
>> 
>> My guess would be that PS officials would like to treat their customer known
>> as -'sip:johnny at vanitydomain.com' the same as their customer known as
>> -'sip:johnny at att.com'.  The domain name does not dictate the level of
>> urgency in the request for emergency assistance, nor the veracity of the
>> caller.
>> 
>> When an overload of the ESInet exists, I would suggest to look for other
>> parameters to use in decision process of how to populate the various queues.
>> 
>> - Are the calls from all the same location?
>> - Is it reasonable that the IP address/network can be at the reported
>> location?
>> - How many calls have we received over a period of time from this AOR? IP
>> address/network? Location?
>> 
>> Simply using the domain/AOR as the black and white rule, as you suggest,
>> will lead to big problems.
>> 
>> Just my opinion,
>> 
>> -Marc-
>> 
>> On 10/30/09 9:47 AM, "Brian Rosen" <br at brianrosen.net> wrote:
>> 
>>> I want it to say MUST NOT use that mechanism :)
>>> 
>>> I don't want alternative ways to make emergency calls.  I want what phonebcp
>>> already says: send the call on the normal path and a normal identity and
>>> callback (which implies using a normal registration).
>>> 
>>> I understand that the local authority can disable the ESRP registration
>>> mechanism.  If this draft goes forward against my advice, then I will ask
>>> that there be text that says if the registration cannot be completed, the
>>> device MUST NOT send emergency calls direct to that ESRP, and must use its
>>> normal call path for emergency calls.
>>> 
>>> We can't stop calls from entering the emergency services IP network without
>>> passing through a service provider.  I have no wish to add any mechanism
>>> which would attempt to do so.  If it would help,  I would be happy to beef
>>> up language in framework that discusses this problem and what "normal call
>>> path" means.  I would even be very happy to add a item to phonebcp that says
>>> "if you can't make normal calls, you can't make emergency calls", although
>>> we might get hung up on defining "normal", because if at some time when you
>>> need help the only number that could actually answer your call, sent down
>>> the same call path as you would normally send any call, is the emergency
>>> service, then we want that call.
>>> 
>>> We frequently use you as an example.  If you have a SIP Registrar and proxy
>>> server in your home (or boat) and you have a phone that registers with it,
>>> and you normally make calls to your family and friends with that setup, then
>>> I suspect that there is some service provider helping your proxy server
>>> connect to your family and friends.  We would prefer your emergency calls go
>>> through that service provider.  However, if for some reason, your proxy
>>> server forwarded an emergency call direct to the ESInet, it will normally go
>>> through.
>>> 
>>> Unfortunately for you, if someone decides to attack the emergency call
>>> system, and it gets overloaded for some period of time until we can mitigate
>>> the attack, we may have to make choices on which calls we answer and which
>>> ones we don't.  Your call sent through your proxy server to the ESInet
>>> direct may get lower priority than the same call sent through the service
>>> provider, if we notice that most of the attack calls are coming direct from
>>> the Internet, rather than going through a service provider we know about.
>>> We're building in explicit attack mitigation strategies like that.  It's not
>>> unreasonable: if you have 5 sources entering your network, and one of them
>>> is the place where all (or most) of the attack is coming from, you shut off
>>> that source until you have a better filter.
>>> 
>>> If a whole lot of devices assume the direct path is the preferred path, that
>>> would be bad for them.
>>> 
>>> Furthermore, there is additional data sent to the emergency system (in the
>>> U.S.) with the call from the service provider.  That information may be
>>> useful in helping you.  The device can actually send the information, but
>>> while while we are pretty sure we can get most service providers to give it
>>> to us, we are pessimistic most devices will.  Devices that have sensors,
>>> where the sensor data is useful for emergency calls may very well do it.
>>> Medical monitoring devices for example.  NENA will be asking the IETF to
>>> standardize this soon, so that all service providers anywhere could provide
>>> it to all emergency services.  It has things like subscriber (as opposed to
>>> caller) contact data, class of service information, SP contact data, etc.
>>> When things go wrong, the PSAP will often contact the SP and get help.  The
>>> SP often has tools and mechanisms that CAN help.
>>> 
>>> Brian
>>> 
>>> 
>>> On 10/29/09 5:46 PM, "Marc Linsner" <mlinsner at cisco.com> wrote:
>>> 
>>>> Brian,
>>>> 
>>>> I didn't read anything in the draft that stated devices 'should' use this
>>>> mechanism (if it's there, it needs removed).  I read it more as a device
>>>> 'could' use this mechanism (as in an alternative to other mechanisms).
>>>> 
>>>> Further, since the ESRP is controlled by the PSAP, it certainly would be a
>>>> PSAP policy decision whether to support this mechanism.  As without the
>>>> ESRP
>>>> support of unknown UA registrations, the mechanism doesn't work.
>>>> 
>>>> BTW, the term 'unregistered' is not in phonebcp.  I think your are
>>>> stretching the 'normal call path' to include registration with
>>>> something(?).
>>>> I find nothing in phonebcp that disallows 'direct' calls to an ESRP.  If I
>>>> contact an ESRP from my UA 'directly', as long as the PSAP can call-back
>>>> using the Contact header I sent in the invite and my AOR leads back to my
>>>> UA, I've satisfied phonebcp.
>>>> 
>>>> What am I missing?
>>>> 
>>>> -Marc-
>>>> 
>>>> 
>>>> On 10/29/09 4:35 PM, "Brian Rosen" <br at brianrosen.net> wrote:
>>>> 
>>>>> The IETF writing standards that describe how devices should bypass their
>>>>> service provider and place emergency calls direct is not a PSAP policy
>>>>> issue.
>>>>> 
>>>>> I'm satisfied with the current -phonebcp dictum to send calls on the
>>>>> normal
>>>>> call path.  For an "unregistered" device, that will not allow any "calls"
>>>>> including emergency calls.
>>>>> 
>>>>> I discussed this draft on the NENA LTD meeting this morning.  That may
>>>>> generate some list discussion from some PSAP people who are subscribed.  I
>>>>> would also like to hear from more PSAP folks on this subject.
>>>>> 
>>>>> Brian
>>>>> 
>>>>> 
>>>>> On 10/29/09 3:27 PM, "Marc Linsner" <mlinsner at cisco.com> wrote:
>>>>> 
>>>>>> These are all PSAP policy decisions.  Just as it's a PSAP policy decision
>>>>>> to
>>>>>> 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 at 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 at 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 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
>>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
> 
> 
> _______________________________________________
> Ecrit mailing list
> Ecrit at ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit
>