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

From: Marc Linsner <[email-masked]>
Date: Sat, 31 Oct 2009 08:54:51 -0400

On 10/30/09 6:41 PM, "Brian Rosen" <[email-masked]> wrote:

> I don't see that as a big problem.  There aren't going to be thousands of
> such successful service providers.  It usually quickly settles Darwinian
> style to one or two.  When the PSAPs see a bunch of calls from some new
> source, they will call them up, and get them on the "we know you" list.  No
> big deal.  
> 
> You are still speculating about something that hasn't happened, and you
> can't find a good predecessor.  The latest "thing" is the social newtworks,
> there were maybe 50 of them, and now there are maybe 5 or 6 that matter.

Exactly my point.  In the scenario you've painted, the PSAP is going to
evaluate the validity/urgency of the request for emergency assistance
differently for their customers (as in the PSAP's customer) that chose to
use social network 7-50 verses 1-6.  Please explain how my emergency is
lesser of a priority because I buy services from social network provider
#29.  This is not the right tool for the PSAP to use for this purpose.
Simply stating these are the only tools available is not good enough.

-Marc-

> 
> Brian
> 
> 
> On 10/30/09 6:12 PM, "Marc Linsner" <[email-masked]> wrote:
> 
>> It's not that I necessarily believe there will be a lack of SPs.  I believe
>> the mix of SPs and the products they offer will change dramatically at a
>> pace that PSAPs won't be able to keep up.  This week Google, next week
>> Noggle, the next week Boogle, etc.  If in fact the PSAP requires
>> relationships with every SP that may send an emergency call their way, it
>> will only stifle innovation.
>> 
>> -Marc-
>> 
>> 
>> On 10/30/09 4:55 PM, "Brian Rosen" <[email-masked]> wrote:
>> 
>>> There is way too much speculation here.
>>> 
>>> You are speculating that there will be interesting services without service
>>> providers that have two way interactive media, where the identity of the
>>> callers is a simple domain name, emergency calls from those devices is
>>> interesting, they can't provide a suitable callback without a registration
>>> from the ESRP, and such calls wont be the preferred abuse call source.
>>> 
>>> When we have that problem, if we ever have that problem, we'll solve it.
>>> 
>>> Right now, the simpler case of a direct call from an unknown source because
>>> you have a proxy server in your boat will get through just fine nearly all
>>> the time.  When it doesn't, it will be because that path is being used by
>>> someone attacking, and the lack of a service provider will probably be to
>>> the disadvantage of the direct caller.  I'm not going to lose sleep over
>>> that problem.  I'd rather beef up the system so we don't have to drop calls
>>> when we're attacked.  OTOH, I don't want to promote the proxy server in the
>>> boat idea.  If it happens occasionally, we'll cope.
>>> 
>>> Brian
>>> 
>>> 
>>> On 10/30/09 4:14 PM, "Marc Linsner" <[email-masked]> wrote:
>>> 
>>>> 
>>>> 
>>>> On 10/30/09 2:29 PM, "Brian Rosen" <[email-masked]> wrote:
>>>> 
>>>>> 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, like others, believe the role/definition of the 'SP', as currently
>>>> defined by the PSAPs, will change significantly going forward.
>>>> 
>>>>> 
>>>>> 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 "@' ([email-masked]@msn.com) gets escaped.  We've
>>>>> built systems that handle that.
>>>> 
>>>> I think this is a little short-sighted.  Certificates for vanity domains
>>>> are
>>>> certainly doable.  Besides P-Asserted-Identity is not a MUST in phonebcp.
>>>> :^)
>>>> 
>>>>> 
>>>>> 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.
>>>> 
>>>> We're not talking about existing firewalls and SBCs.  We're talking about
>>>> ESInet Border Control Function.  If you don't define what you want there,
>>>> you'll live with what you get.  My suggestions are not beyond what's
>>>> possible, it's all software.
>>>> 
>>>> -Marc-
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
> 
>

---

From: Brian Rosen <[email-masked]>
Date: Sat, 31 Oct 2009 09:43:01 -0400

You are looking for trouble when there isn't any.

First of all, the latest example is that of a service provider, and not
entirely p2p.  That's what we expect, and we don't expect the scenario you
are trying to paint.

Then, ANY provider, regardless of size, should arrange to get whatever
credential we end up deploying.  That means:
A) The devices on their network and/or their own network elements yield
phonebcp compliant emergency calls
B) They correctly forward such calls to the ESInet
C) They include the additional information we ask for, which includes
appropriate contact info

It doesn't mean much more than that.  It does give us some basis for making
choices, when we have to make choices, about calls.  And please remember,
we're nearly always taking calls wherever they come from: the scenario we
are spilling all these bits in the last several messages is something we
hope roughly never happens, but we plan for it anyway.

I think PSAPs and their contractors will be trying to be proactive about
looking for calls from unknown providers, but as always, the ones with the
most calls are going to get more attention than the ones who have fewer
calls.  That's all I meant.  Actually, it occurs to me that they probably
will go after providers who send calls that don't follow the rules before
they go after well behaving, but unknown providers.

Brian

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 31 Oct 2009 18:16:21 -0700

> will only stifle innovation.

There is a fundamental scaling problem here that can't just be wished away. 
It doesn't strike me as realistic for PSAPs to maintain a large number of
bi-lateral relationships, whether they be with SPs anywhere on earth, 
enterprise networks operating in their service areas, or local
access networks.  This isn't a constraint that is created by the
choice of security technology (e.g. certificates vs. passwords or 
pre-shared keys);  it's fundamental. 

The only way to get around this scaling problem is by introducing
hierarchy.  However, we shouldn't necessarily assume that the hierarchy 
corresponds to today's notion of a "service provider".