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

[Brian Rosen <br at brianrosen.net>]

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

Sorry, it’s an effective strategy.  There aren’t many better ones when you can’t filter by attack signature or specific source address.  When 99.99% of legitimate calls come from SPs you know, then filtering ones you don’t when attacks come that way works well.

The current 9-1-1 system in the U.S. has an even worse mechanism.  It uses small trunk group sizes to limit how many calls an origination switch can send towards the PSAP.  This is the main defense against a local surge of calls.  Unfortunately, legitimate calls from callers not related to the surge who happen to be on the same switch get caught.  Compared to that, this is strategy is great.

If it’s not effective, that is, when attacks come from sources you know, which certainly is feasible with many bot-net style attacks, then of course we wouldn’t use it.  Our primary strategy is spread calls out to every available call taker.  20,000 on duty call takers can process A LOT of bad calls.  Of course, there are some attacks which would overwhelm that strategy.  We fall back to others.

PSAPs like SPs.  Please remember that.  SPs are really common.  No SP is really, really uncommon.  If that changes (by itself, not because we did something stupid), then the strategy of filtering by source won’t be effective any more.

But keep in mind that my major objection to –direct is not the effect it may have on attack filtering, it’s the abuse potential.

Brian


On 11/2/09 10:13 AM, "Marc Linsner" <mlinsner at cisco.com> wrote:

I have no problem with indications that advise the PSAP call-taker:

1. “This caller is using  a SP we don’t know, please query the caller as to their identity and location.”
2. “There is no validation that the IP address of this caller exists at the reported location, please query further about location.”
   

I have a problem with:

1. Queuing  the call (as in prior to a human answering) or responding to a call based on the SP (or lack thereof) the caller utilized.
   

I have no problem with:

1. Requiring that calls to the ESInet meet a set of open global Industry standard protocol specifications.
   

This thread started when you described what happens in a PSAP call overload situation.  Determining the validity/urgency of an emergency call cannot happen based on the SP utilized, the failure scenario of the algorithm is disastrous.

-Marc-



On 10/31/09 8:43 AM, "Brian Rosen" <br at brianrosen.net> wrote:

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


On 10/31/09 8:54 AM, "Marc Linsner" <mlinsner at cisco.com> wrote:

>
>
>
> On 10/30/09 6:41 PM, "Brian Rosen" <br at brianrosen.net> 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" <mlinsner at cisco.com> 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" <br at brianrosen.net> 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" <mlinsner at cisco.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On 10/30/09 2:29 PM, "Brian Rosen" <br at brianrosen.net> 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 "@' (br at brianrosen.net@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-
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>