On the one hand, there are multiple manifestations of VSPs using proprietary client protocols, semi-proprietary protocols, and some standards compliant protocols, and you have them operating out of globally diverse jurisdictions. What's important is what happens when the call gets routed to the ESRP. This isn't a "normal" use case in the context of those services - so where's the guarantee that they will work with arbitrary ESRP implementations when that moment comes?
On the other hand, there's the possibility of an ECRIT-specific client implementation that can be embedded at the OS level. This can be implemented to a reference design made to work with the reference ESRP design. It can be solved once at the device OS level and not have a dependency on arbitrary "VSP" approaches into the future.
I argue that this is a more robust approach to the reliability of emergency call client and server behaviour.
Cheers,
Martin
-----Original Message-----
From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc Linsner
Sent: Saturday, 31 October 2009 9:12 AM
To: Brian Rosen
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered
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@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@cisco.com> wrote:
>
>>
>>
>> On 10/30/09 2:29 PM, "Brian Rosen" <br@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@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-
>>
>>
>>
>>
>
>
_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit
_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit
