[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered
Nope, just dealing with reality.
Reality is that calls come from service providers. They like it that way.
If that changes, then strategies should change, but emergency calling ought
not to be the driver for any such change.
What "real value of the information included with the call" am I ignoring?
I said we'll deal with addresses (albeit, with SBCs and all manner of NATs,
that is getting pretty hard to do) first. What else should we look for?
Brian
On 11/2/09 1:33 PM, "Marc Linsner" <mlinsner at cisco.com> wrote:
>
> On 11/2/09 8:53 AM, "Brian Rosen" <br at brianrosen.net> wrote:
>
>> 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.
>
> These are self-imposed limitations that conveniently allow the claim of
> 'effective strategy'. NENA is writing how congestion control works. The SP
> the call utilizes should be low on the list of criteria used to 'rank' the
> veracity of the call. You are ignoring the real value of the information
> included with call. Instead you are focusing on carrying forward the warm
> and fuzzy from the legacy system.
>
> The PS community needs to utilize different tools to deal with calls from
> the Internet verses calls via the PSTN.
>
> -Marc-
>
>>
>> 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-
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>
>