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

From: Marc Linsner <[email-masked]>
Date: Mon, 02 Nov 2009 09:13:54 -0500

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" <[email-masked]> 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" <[email-masked]> wrote:
> 
>> >
>> >
>> >
>> > 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: Mon, 02 Nov 2009 09:53:26 -0400

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

No
a
it
the
is
it.
over
>>>>>> >>>> that problem.  I'd rather beef up the system so we don't have to
>>>>>> drop calls
>>>>>>>> >>>>>> I don't believe we are going to see vanity domains used on
>>>>>>>> calls, and
>>>>>>>> >>>>>> even
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
when
you
>>>>>>> >>>>> We're not talking about existing firewalls and SBCs.  We're
>>>>>>> talking about

---

From: Marc Linsner <[email-masked]>
Date: Mon, 02 Nov 2009 12:33:44 -0500

> 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-

> 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.
> 
> something stupid), then the strategy of filtering by source won¹t be effective
> any more.
> 
>>>>>> the mix of SPs and the products they offer will change dramatically at a
>>>>>> relationships with every SP that may send an emergency call their way, it
>>>>>>> providers that have two way interactive media, where the identity of the
>>>>>>> callers is a simple domain name, emergency calls from those devices is
>>>>>>> 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.
>>>>>>> 
>>>>>>> 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
>>>>>>> when we're attacked.  OTOH, I don't want to promote the proxy server in
>>>>>>> the
>>>>>>>>> I'm the messenger here.  PSAPs prefer service providers to be on the
>>>>>>>>> path
>>>>>>>>> of
>>>>>>>>> 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
>>>>>>>> I, like others, believe the role/definition of the 'SP', as currently
>>>>>>>>> I don't believe we are going to see vanity domains used on calls, and
>>>>>>>>> even
>>>>>>>>> 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
>>>>>>>>> The Firewall/Session Border controls will have several criteria when
>>>>>>>>> PSAPs
>>>>>>>>> are overloaded, but AFAIK, no existing firewalls or SBCs do what you
>>>>>>>>> suggest
>>>>>>>>> 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.
>>>>>>>> 
>>>>>>>> you'll live with what you get.  My suggestions are not beyond what's

---

From: Brian Rosen <[email-masked]>
Date: Mon, 02 Nov 2009 12:56:44 -0400

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" <[email-masked]> wrote:

>> send
>> which
>> effective

---

From: Marc Linsner <[email-masked]>
Date: Tue, 03 Nov 2009 09:18:46 -0500

> Reality is that calls come from service providers. They like it that way.

I'll ask again, how does a call coming from a particular service provider
relate to the nature/veracity of the emergency?

> not to be the driver for any such change.

I have doubts that PS could alter the VoIP marketplace.

> that is getting pretty hard to do) first.  What else should we look for?

1) Location: Have I had other calls within x meters of this location in the
last 5 minutes? 20 minutes? 1 hour? 24 hours?

2) Caller Identity (From; Contact): Have I had other calls with the same
identity in the last 5 minutes? 20 minutes? 1 hour? 24 hours?

3) Network Address: Have I received other calls from this IP address in the
last 5 minutes? 20 minutes? 1 hour? 24 hours?

-Marc-

---

From: Brian Rosen <[email-masked]>
Date: Tue, 03 Nov 2009 09:37:10 -0400

inline

> relate to the nature/veracity of the emergency?
The quality of the information, and the ability to get additional
assistance, if needed, depends on the SP, if there is any.  Most SPs have
dedicated emergency call teams that will quickly assist a PSAP if there is a
problem.  They have information which may be valuable to the PSAP.  PSAPs
appreciate this.  They depend on it.  They really work over SPs who don't do
that.

> I have doubts that PS could alter the VoIP marketplace.
I assume "PS" is "SP".  SPs ARE the VoIP marketplace.  There is no VoIP
marketplace without SPs presently.  There is no reason to think that will
change  

> last 5 minutes? 20 minutes? 1 hour? 24 hours?
The primary problem is abuse.  What should I do if I had a legitimate call
from the same location, but a different address/SP/...?  What should I do if
I had an abusive call from the same location?  Our statistics on that are
probably poor, but my personal opinion is that location is not a good
indicator of abuse.  I suppose it depends on how reliable location will be
with abusive calls.  If it turns out to be very reliable, that might be
helpful.  I suspect the abuser will manage to make location unreliable.  I
guess we will see.  We certainly have the ability to use location as an
input to the routing decisions, so no problem if it actually works.

Of course, in the current systems, you don't get location with a "simless"
call.  I agree that we shouldn't assume that will be the case going forward.

I would not use this for a DDoS attack.  That would kill a call from a
non-compromised device in a residence/office with one that was compromised.

> identity in the last 5 minutes? 20 minutes? 1 hour? 24 hours?
Yes, this is like address. We'll clearly start with that.  If it works,
that's our primary defense.   Often effective on abuse, usually not
effective enough on a DDoS: you shut off the sources you know are bad, but
too many new ones pop up to make that effective enough.  It's also usually
spoofed. 

> last 5 minutes? 20 minutes? 1 hour? 24 hours?
As above.

The "filter based on source SP" is a secondary line of defense.  An attack
signature is an even better line of primary attack, if there is one.  Normal
abuse would not have a signature.  A DDoS attack often does.

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 3 Nov 2009 23:23:14 +0800

Hi Brian,

Please *define* what you mean when you keep saying SP in this thread.

There are two VoIP providers I use regularly; MyNetFone which is an Oz provider and Skype. There are others as well that I use as circumstance suggests. So... come to the US and I'll only be entitled to second class emergency service calling?

Skype is the one I use the most, though I have a number of subscriptions. The most recent one is "martin-psp" which I exclusively log onto from my PSP and use, again, in circumstances where it's most convenient.

Now I don't *need* to provide any useful information (from an ESP perspective) to have these accounts. There's no identity information of the type you refer to.

The only reason Skype want more rigorous identity information is when they want to charge me money (e.g. for Skype out/in) - even then it might just be a PayPal username. The only reason any commercial VSP wants this sort of information is when they want to charge money. So... you appear to be limiting "premium" emergency service access to people with credit cards.

And - in any case - you haven't addressed your invented problem. People can still call the ESRP without going through one of these "blessed" VSP operators. So what have you achieved?

There's no empirical, or even anecdotal, evidence for your claims as far as I know. Please cite your sources. We've put the mechanisms in place to provide reliable location identity with calls (via the ISPs of course). Where is the study that shows that people are going to go running off to free airport WiFi access points (despite the fact that their location will be known) and start making nuisance calls in high volume? By the same token, where is the evidence that this would be mitigated by a patchwork of occasional and often foreign VSP subscriptions?

Regards,
Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: Wednesday, 4 November 2009 12:37 AM
To: Marc Linsner; [email-masked]
Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered

inline

As above.

> -Marc-

_______________________________________________
Ecrit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit

---

From: Brian Rosen <[email-masked]>
Date: Tue, 03 Nov 2009 11:02:26 -0400

I guess I've pretty much said my piece here Martin.

We'll accept calls from Skype, regardless of the fact that the identity may
be pretty weak.  These days, law enforcement can do pretty well with an IP
address and email address, but it's not foolproof.  It's my opinion, after
talking to them, that PSAPs STRONGLY prefer that a service provider be in
the path, and by service provider they mean calling network and not ISP.
For the purposes of this discussion, they don't want calls that have no SP.
I hesitate to call them VSPs, because "Voice" isn't right, but that's the SP
we mean.  

I agree that we'll be looking for the ISP to be able to help us with abuse
if we need them to.  We do want signed location, to provide some integrity
protection, and we definitely need the identity of the ISP that provided
location in the PIDF.  That's an AND, and not an OR though.  It's hard to
call location a reliable identity.  Too easy to discard.  We DO take calls
without location.  We don't like those either.

In normal circumstances, we take calls from anywhere, regardless of whether
they follow rules.  Frankly, I think if the call has an INVITE that looks
vaguely reasonable, with any form of sos urn, we'll probably take it until
it proves to be abusive or part of an attack.

So, yes, we'll take a call not from an SP, but we don't want to see such
calls.  We certainly don't want to encourage them.

But I think I am repeating myself, so unless there is something new, I'll
take a break from this thread.

Brian

On 11/3/09 11:23 AM, "Dawson, Martin" <[email-masked]> wrote:

> There are two VoIP providers I use regularly; MyNetFone which is an Oz
> provider and Skype. There are others as well that I use as circumstance
> suggests. So... come to the US and I'll only be entitled to second class
> emergency service calling?
> 
> Skype is the one I use the most, though I have a number of subscriptions. The
> most recent one is "martin-psp" which I exclusively log onto from my PSP and
> use, again, in circumstances where it's most convenient.
> 
> Now I don't *need* to provide any useful information (from an ESP perspective)
> to have these accounts. There's no identity information of the type you refer
> to.
> 
> The only reason Skype want more rigorous identity information is when they
> want to charge me money (e.g. for Skype out/in) - even then it might just be a
> PayPal username. The only reason any commercial VSP wants this sort of
> information is when they want to charge money. So... you appear to be limiting
> "premium" emergency service access to people with credit cards.
> 
> And - in any case - you haven't addressed your invented problem. People can
> still call the ESRP without going through one of these "blessed" VSP
> operators. So what have you achieved?
> 
> There's no empirical, or even anecdotal, evidence for your claims as far as I
> know. Please cite your sources. We've put the mechanisms in place to provide
> reliable location identity with calls (via the ISPs of course). Where is the
> study that shows that people are going to go running off to free airport WiFi
> access points (despite the fact that their location will be known) and start
> making nuisance calls in high volume? By the same token, where is the evidence
> that this would be mitigated by a patchwork of occasional and often foreign
> VSP subscriptions?
> 
> Regards,
> Martin
>

---

From: "Dawson, Martin" <[email-masked]>
Date: Fri, 6 Nov 2009 08:32:22 +0800

Thanks Brian,

I'm glad to draw a veil over your comments. Obviously I've found them less than convincing - and in some respects alarming.

The draft, I submit, stands worthy of being progressed in its own right.

I'll also add that a key feature it adds in conjunction with ECRIT - the temporary registration - is of potential utility regardless of the call being direct from the UA or via a VoIP proxy (be it a VSP or, more sensibly, something like an enterprise IP PABX).

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]]
Sent: Wednesday, 4 November 2009 2:02 AM
To: Dawson, Martin; Marc Linsner; [email-masked]
Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered

Brian