Subject: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered harmful, at least given our current experiences

From: "Hannes Tschofenig" <[email-masked]>
Date: Mon, 26 Oct 2009 23:23:27 +0200

FYI: feedback from Brian regarding a recent ECRIT contribution.  

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Rosen, Brian
>Sent: 26 October, 2009 23:10
>To: [email-masked]
>Subject: [Geopriv] Winterbottom-ecrit-direct considered 
>harmful, at least given our current experiences
>
>The notion behind -direct is to not use a service provider to 
>place an emergency call.  Instead, the device registers with 
>an Emergency Services Routing Proxy immediately before the 
>call and the call is routed directly from the device to the ESRP.
>
>At least at the moment, this is an exceedingly bad idea.
>
>Emergency calling authorities like service providers, a lot.  
>They like them because they can hold them accountable, and the 
>service providers don't like theft of service, which is 
>something the emergency call guys have an analog to.
>
>The facts are that where unaccountable access to emergency 
>calling is allowed, huge numbers of false calls occur, with no 
>way to stop them, and no way to tell the good ones from the 
>bad ones.  This has been seen multiple times where so called 
>"simless" or "unauthenticated" calls are allowed.
>
>-direct precisely duplicates simless calling.  The only 
>"registration" is an emergency registration, only emergency 
>calls are allowed, any device can make an emergency call if 
>all it has is a (radio) connection to any network.
>We can predict, with a very high degree of certainty, that the 
>feature will be horribly abused: for example to test that a 
>phone without a service plan works.
>
>There have been studies which show tens of thousands of bad 
>calls with zero good ones.  Nearly every authority I know 
>where the regulator has insisted on simless calling wants it 
>repealed.  There is one counter example I know where the fact 
>that they got a couple, literally, of good calls among the 
>tens of thousands of bad calls was considered enough reason to 
>put up with the problem.
>
>Service providers give us information that may be useful: a 
>subscriber name and address for example, which is not 
>spoofable by the caller.  They have ways to trace callers, 
>especially bad callers.  They don't want their systems abused 
>any more than the emergency calling authorities do.
>
>This is a bad idea.  A very bad idea.  Please stop it.
>
>Someday, we may have better ways to prevent abuse. Until we 
>do, service providers are a good thing on an emergency call.  
>We don't want them cut out.
>
>Brian
>
>_______________________________________________
>Geopriv mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/geopriv
>

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 27 Oct 2009 07:56:42 +0800

I am glad this has come up. It's a debate that has to happen if we are to move beyond a long standing legacy misconception.

In the circuit service world - whether it was POTS or mobile, the access network had full responsibility for delivering the emergency call. In that world, routing an emergency call meant getting a circuit established to the correct call center. In most parts of the world, this was done using the regional part of the PSTN to switch the circuit to a call center on the PSTN. In some jurisdictions, such as the US, it was done directly from the local exchange carrier to the call center. Either way, there was no third party involved.

Now we have the Internet. We still have public access network providers. They switch packets onto the Internet for their subscribers. They can similarly ensure that packets reach the local emergency call centers.

The fact is that there was no equivalent of a VSP in the traditional environment. VoIP is a presence service, and it had no common equivalent in the PSTN world. It could have, but the narrowband state of technology and the common market use cases didn't support its development. By the time ISDN arrived, the PSTN had already slipped into its palliative stage without realizing it.

It's an entrenched misconception that because the circuit service provided by exchange carriers was most commonly used for "voice" (but, it should be noted, also for fax, telex, tty, security system monitoring and, even, IP data) that VSPs are somehow equivalent to exchange carriers. They are not.

Indeed, involving VSPs in emergency calls is the Internet equivalent of involving long distance providers in POTS emergency calls. They are neither necessary nor particularly helpful; they can't be guaranteed to be within the emergency jurisdiction; depending on them actually diminishes the efficacy of emergency service access. It does not help the caller, the emergency service, nor the third party to insist on the third party's involvement.

It can't be helped if you have over sold the benefits of VSP involvement to yourself and others Brian. It is time to have a reasoned debate. From my perspective, the argument that there is no "subscription" involved is patently false. There has to be a subscription of some description in order to get to the Internet. Yes, there is free public Internet access (just as there are free courtesy phones on the PSTN and free access to emergency services from pay phones. All these services are still connected to the public Internet infrastructure and they all represent an "operator" with some level of information about the caller.

With the over-emphasis on VSPs, what is missing from the ECRIT and i3 models is the direct interface for querying the access network for subscriber data (should it prove necessary). These models need to take the long view of how emergency calling is done in the Internet age; they should not be protracting an unnecessary reliance on VSPs.

I have deleted the premature and prejudicial text from the subject heading. And I'll leave this on ECRIT as the most appropriate WG.

Cheers,
Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Tuesday, 27 October 2009 8:23 AM
To: [email-masked]
Subject: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered harmful, at least given our current experiences

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

---

From: Brian Rosen <[email-masked]>
Date: Mon, 26 Oct 2009 20:59:06 -0400

First of all, I put it on the wrong email list, sorry about that.

Then, we have carefully arranged it so that there is no identity coming from
the access network provider, and because the location is coming from that
provider, we really don't want to.  But even if we did, we would need a
really good identifier, and there isn't one.

The problem we have with -direct is anonymous callers, and if they have any
option, they would also be location-less.  Until and unless we get rid of
anonymity, we can't encourage service provider-less calls.  The draft does
not make any provision to provide any kind of identity.  Many networks
(think free wifi for example) would make providing good identity difficult.

The fact is that there is a SERVICE provider in nearly all of the
communications systems.   The SERVICE provider is in a position to assist
the emergency calling system when it needs more information.  That's what a
good SERVICE provider does.  Cutting them out is not a great idea.  Most of
the attempts to provide real time communications between people have evolved
to using service providers, even when there were alternatives.  File
transfer via something like Torrent is a counterexample (which isn't real
time), but even there, you end up with service providers like The Pirate Bay
(R.I.P) to provide introduction services.  I don't think we're going to see
changes that eliminate service providers, and in this case, they provide
value to the emergency calling systems.  All of the emergency professionals
I know have issues with service providers, but they would react with horror
if you suggested cutting them out.  Ask them, please.

So, I claim you have a solution in search of a problem.  We have solved the
"calling network isn't the access network" problem already.  Service
providers ARE in the path now, in nearly every case (in fact a counter
example escapes me, although there probably are some).  There is no movement
I can detect which would change that any time soon; quite the opposite.  We
have a known killer problem without some kind of subscription to a service
that provides a good identity, for which you provide no answers.  We have
experience with the killer problem: sim-less calling was supposed to provide
a way to make an emergency call in exactly the kinds of circumstances you
are describing.  Our real world experience is that you create a huge problem
that diverts resources from helping people to chasing scammers and
flea-market sellers.

Nothing is perfect: you can get a AIM screen name without a very good
identity for example.  However, the notion that we're going to provide
direct access without a service provider deliberately, especially without
really good identity from the access network is, in my opinion not only a
no, it's a heck no.  I'll line up as many emergency service professionals as
you would like to tell you this is a harmful idea.

On 10/26/09 7:56 PM, "Dawson, Martin" <[email-masked]> wrote:

> I am glad this has come up. It's a debate that has to happen if we are to move
> beyond a long standing legacy misconception.
> 
> In the circuit service world - whether it was POTS or mobile, the access
> network had full responsibility for delivering the emergency call. In that
> world, routing an emergency call meant getting a circuit established to the
> correct call center. In most parts of the world, this was done using the
> regional part of the PSTN to switch the circuit to a call center on the PSTN.
> In some jurisdictions, such as the US, it was done directly from the local
> exchange carrier to the call center. Either way, there was no third party
> involved.
> 
> Now we have the Internet. We still have public access network providers. They
> switch packets onto the Internet for their subscribers. They can similarly
> ensure that packets reach the local emergency call centers.
> 
> The fact is that there was no equivalent of a VSP in the traditional
> environment. VoIP is a presence service, and it had no common equivalent in
> the PSTN world. It could have, but the narrowband state of technology and the
> common market use cases didn't support its development. By the time ISDN
> arrived, the PSTN had already slipped into its palliative stage without
> realizing it.
> 
> It's an entrenched misconception that because the circuit service provided by
> exchange carriers was most commonly used for "voice" (but, it should be noted,
> also for fax, telex, tty, security system monitoring and, even, IP data) that
> VSPs are somehow equivalent to exchange carriers. They are not.
> 
> Indeed, involving VSPs in emergency calls is the Internet equivalent of
> involving long distance providers in POTS emergency calls. They are neither
> necessary nor particularly helpful; they can't be guaranteed to be within the
> emergency jurisdiction; depending on them actually diminishes the efficacy of
> emergency service access. It does not help the caller, the emergency service,
> nor the third party to insist on the third party's involvement.
> 
> It can't be helped if you have over sold the benefits of VSP involvement to
> yourself and others Brian. It is time to have a reasoned debate. From my
> perspective, the argument that there is no "subscription" involved is patently
> false. There has to be a subscription of some description in order to get to
> the Internet. Yes, there is free public Internet access (just as there are
> free courtesy phones on the PSTN and free access to emergency services from
> pay phones. All these services are still connected to the public Internet
> infrastructure and they all represent an "operator" with some level of
> information about the caller.
> 
> With the over-emphasis on VSPs, what is missing from the ECRIT and i3 models
> is the direct interface for querying the access network for subscriber data
> (should it prove necessary). These models need to take the long view of how
> emergency calling is done in the Internet age; they should not be protracting
> an unnecessary reliance on VSPs.
> 
> I have deleted the premature and prejudicial text from the subject heading.
> And I'll leave this on ECRIT as the most appropriate WG.
> 
> Cheers,
> Martin
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 27 Oct 2009 09:07:07 +0800

The only SERVICE necessary in this case is internet access.

If caller identity is your solution to the problem, then you're joining illustrious company [1].  It certainly would solve a lot of problems...

I think that jumping to conclusions here doesn't do us any favours.  Perhaps we need to do as was suggested by Bernard in Stockholm [2] and start to look at the security of the entire system.

--Martin

[1]  <http://www.theregister.co.uk/2009/10/16/kaspersky_rebukes_net_anonymity/>
[2]  <http://tools.ietf.org/html/draft-tschofenig-ecrit-trustworthy-location>

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Brian Rosen
> Sent: Tuesday, 27 October 2009 11:59 AM
> To: Dawson, Martin; Hannes Tschofenig; [email-masked]
> Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered
> 
> > From: [email-masked] [mailto:[email-masked]] On
> Behalf Of
> > Hannes Tschofenig
> > Subject: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered
> harmful,

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 26 Oct 2009 22:08:11 -0400

On Oct 26, 2009, at 7:56 PM, Dawson, Martin wrote:

>
> It can't be helped if you have over sold the benefits of VSP  
> involvement to yourself and others Brian. It is time to have a  
> reasoned debate. From my perspective, the argument that there is no  
> "subscription" involved is patently false. There has to be a  
> subscription of some description in order to get to the Internet.  
> Yes, there is free public Internet access (just as there are free  
> courtesy phones on the PSTN and free access to emergency services  
> from pay phones. All these services are still connected to the  
> public Internet infrastructure and they all represent an "operator"  
> with some level of information about the caller.

Without weighing in on the rest of the discussion, that level can be  
pretty minimal. Columbia University allows anybody to use the 802.11  
service, without authentication, as does Panera Bread and any number  
of non-chain cafes. Thus, we should be careful to distinguish  
knowledge of the caller's location from that of his or her identity.  
As noted, this is essentially like a pay phone.

Henning

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 27 Oct 2009 10:12:11 +0800

And - of course - anybody can make a 9-1-1 call from a phone on the campus. Nothing changes just because it's IP as opposed to circuits.

Cheers,
Martin

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]]
Sent: Tuesday, 27 October 2009 1:08 PM
To: Dawson, Martin
Cc: Hannes Tschofenig; [email-masked]
Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered

Henning

---

From: Marc Linsner <[email-masked]>
Date: Tue, 27 Oct 2009 09:02:44 -0400

Brian,

I'm a little confused.  I don't remember you objecting to requirement RE1
from RFC5012 and I remember your use case about a Sierra Leone VSP.

Are you implying that *all* VSPs will have a trust relationships with *all*
PSAPs?

What is the difference between a call coming from a private/individual
domain (as in not a commercial VSP) and a VSP on the other side of the world
(outside the jurisdiction)?

I'm trying to figure out whether you're objecting to anonymous calls to the
PSAP or the mechanisms proposed in this draft?

[Don't take this as my endorsement of the draft, as I'm not sure I agree
with UAs registering with the ESRP.]

-Marc-

---

From: Brian Rosen <[email-masked]>
Date: Tue, 27 Oct 2009 10:31:57 -0400

Of course not all VSPs will have trust relationships with all PSAPs.  One
can hope that long term, we can evolve to transitive trust relationships
that work pretty well cross border.

The emergency guys are actually terrified of private/individual domains
sending them calls, and we're telling them we expect that to be possible,
but rare, and we're giving them mechanisms that will effectively allow them
to turn off calls selectively, based on factors including what domain the
call comes from.  They expect that such calls will be one of the loopholes
where they get equivalents to sim-less calls, which drive them nuts.  They
don't want ANY calls that don't come from service providers, although they
seem to be okay with the notion that the SP may not have great identity (AOL
being a poster child).  So, while indeed they understand, and have concerns
about having to take calls from Sierra Leone VoIP services Pty, they would
much rather have a call that went through them then a call that went through
no service provider at all.

I'm not trying to make calls direct from devices or private domains
impossible, but I think the notion that we're promoting them is a very bad
idea until we have effective mechanisms to prevent abuse.

Brian

---

From: Richard Barnes <[email-masked]>
Date: Tue, 27 Oct 2009 16:39:28 +0200

Brian,

Is the security goal here more access control (i.e., controlling who  
can send calls to a PSAP) or attribution/identification for post-hoc  
action.

If it's the latter, then ISTM that the problem can largely be reduced  
to having a certificate infrastructure that binds authenticated  
identities to real-world entities.  The "extended validation"  
certificates that current commercial CAs issue seem to largely satisfy  
this requirement.

--Richard

On Oct 27, 2009, at 4:31 PM, Brian Rosen wrote:

>>>> I am glad this has come up. It's a debate that has to happen if  
>>>> we are to
>>>> move
>>>> regional part of the PSTN to switch the circuit to a call center  
>>>> on the
>>>> PSTN.
>>>> Now we have the Internet. We still have public access network  
>>>> providers.
>>>> They
>>>> the PSTN world. It could have, but the narrowband state of  
>>>> technology and
>>>> the
>>>> It's an entrenched misconception that because the circuit service  
>>>> provided
>>>> by
>>>> exchange carriers was most commonly used for "voice" (but, it  
>>>> should be
>>>> noted,
>>>> also for fax, telex, tty, security system monitoring and, even,  
>>>> IP data)
>>>> that
>>>> necessary nor particularly helpful; they can't be guaranteed to  
>>>> be within
>>>> the
>>>> emergency jurisdiction; depending on them actually diminishes the  
>>>> efficacy
>>>> of
>>>> emergency service access. It does not help the caller, the  
>>>> emergency
>>>> service,
>>>> involvement to
>>>> perspective, the argument that there is no "subscription"  
>>>> involved is
>>>> patently
>>>> Subject: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct  
>>>> considered harmful,
>>>> at least given our current experiences
>>>>

---

From: Brian Rosen <[email-masked]>
Date: Tue, 27 Oct 2009 11:00:24 -0400

The first goal is to prevent bad calls.

The second goal is to indentify the source of the bad calls.

I'm starting with the first goal.  I don't want you to be able to take a
device out of a box, plug it into a network, and have the only call you can
make be an emergency call.  I want the device to actually "work" (as in be
able to place calls to all the entities that it was intended to) first, and
then be able to place emergency calls.

Please spend some time in a PSAP while a kid with a simless phone has "fun"
with it.  Imagine how much fun the test mechanism is as opposed to placing
real calls.  

If we somehow get a bad call, we need to send the cops.  That means we need
an identity (and a location).

I think a good cert could be the basis of a good identity, if we could get
one.  I don't see how we do that.

Brian

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 27 Oct 2009 09:07:47 -0700

In the case of an emergency call, what is "transitive trust" is based on,
exactly?  Is it an understanding that a VSP allowed to contact the PSAP will
only
interconnect with other carriers that it deems sufficiently trustworthy and
that
demonstrate an ability/willingness to trace/investigate/prevent prank calls?

If so, what happens if an individual attempts to make an emergency call from
a
VSP that does not satisfy those conditions (e.g. a provider that, say,
enables
emergency calls to be made from the IP-equivalent of a Trac phone)?  Or are
all VSPs somehow "inherently trustworthy" as are all potential transitive
trust
paths? 

Issues of "transitive trust" and expectations of customer facing providers
also
arise at lower layers.  This isn't just about authentication, it's also
about
tracing and audit, as SAVI WG demonstrates. 

In these kind of discussions, it can be quite helpful to attempt to write
down
exactly what security properties are desired and under what
conditions/assumptions
they can be delivered.  This may not lead to any conclusions, but at least
we'll
have a clear understanding of what the key assumptions are and when they can
be
expected to be valid.  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Richard Barnes
Sent: Tuesday, October 27, 2009 7:39 AM
To: Brian Rosen
Cc: [email-masked]
Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered

Brian,

--Richard

---

From: Brian Rosen <[email-masked]>
Date: Tue, 27 Oct 2009 12:34:32 -0400

In this case, I'm imagining that national emergency services people will
trust their local providers, and we can arrange transitive trust
relationships between such national entities.

As an example, the U.S. Emergency authority's CA could sign a cert for a
carrier in the U.S.  A caller who nomaded to the U.K. may place an emergency
call via the U.S. Carrier and it may be reasonable for the UK PSAP to have
access to the US CA's cert.

One of the things you learn about the emergency service guys is that they
have all of these rules.  You say "okay, I understand the rules, but what
happens if a call arrives that doesn't follow the rules?".  They bluster a
lot about how you HAVE to follow the rules, but then they say "we'll take
the call".  That is, as long as they have a call taker available.

So, two points: we try to build as good of a system as we can, and we try up
front to get as many calls to follow the rules.  We'll let calls that don't
through.  However, if the call center is stressed, especially if it is
deliberately attacked, the systems will react by prioritizing which calls
are answered first.  One of the inputs is where is the call coming from.  If
a call comes from someone the PSAP knows, and it is overloaded, it's more
likely such calls will be answered then if it comes from someone it doesn't
know.

"simless" calls, or things that look like simless calls, go to the bottom of
the queue.

Brian

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 27 Oct 2009 12:48:50 -0500

James

I'd like to focus on this point below.

At what point did an ESRP become a SIP registrar (for unauthenticated 
UAs to register to when they don't register to any other registrar in 
any domain in the <what>... universe)?

James

At 08:02 AM 10/27/2009, Marc Linsner wrote:
><snip>
> on the PSTN.
> providers. They
> technology and the
> IP data) that
> be within the
> emergency service,

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 28 Oct 2009 03:51:06 +0800

I think that this response highlights the misunderstanding that is being propagated about this draft.

The domain is not totally private blah blah blah. It is an access network, ISP if you will, that will direct the flow to the ESRP. The ISP has foot print in the PSAP jurisdiction, it can be followed up with and forced to comply with things in exactly the same way that LEC can today. This is the same model as happened to today, the local access provider directs the calls to the PSAP.

Why do we need a long distance provider involved or even more alarmingly, as Brian suggests, a chain of long distance providers? When things fail or run amok in this scenario, who is responsible and how on Earth, or in heaven for that matter, do you unravel the mess? You will need an international court to decide the real cause.

The emergency providers are terrified, Brian, because real alternatives are not being put on the table. The emergency providers I talk to are just as terrified of end-points providing location and them having to just believe what it says, with no form of validation being available. The proposal on the table here provides mechanisms for these checks to take place, as well as keeping the traffic local rather than trunking it out of the local jurisdiction.

I will stress again that this solution is being totally misrepresented as if you are comparing it SIMless because it is not, the device must have a legitimate connection to the Internet.

Cheers
James

> Brian Rosen
> Sent: Wednesday, 28 October 2009 1:32 AM
> To: Marc Linsner; [email-masked]
> >>> I am glad this has come up. It's a debate that has to happen if we are
> to
> >>> move
> >>> regional part of the PSTN to switch the circuit to a call center on
> the
> >>> PSTN.
> >>> the PSTN world. It could have, but the narrowband state of technology
> and
> >>> the
> >>> exchange carriers was most commonly used for "voice" (but, it should
> be
> >>> noted,
> >>> also for fax, telex, tty, security system monitoring and, even, IP
> data)
> >>> that
> >>> necessary nor particularly helpful; they can't be guaranteed to be
> within
> >>> the
> Of

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 28 Oct 2009 03:53:44 +0800

Hi James,

It is not unauthenticated, the device must have access to an Internet feed, and that feed is always registered or authenticated in some fashion. 

One of the key proposals of this draft is that the calling device, and please do not think phone, think computing device (which might be a game console) does register with the ESRP. This relatively short-term registration is the way in which call-back is attained. The registration can also be used by the ESRP to check that the caller is in fact in the calling domain of the PSAP or at a minimum where the point of presence in the access network is.

So in short answer to your question James, in the expanding Universe of NG Emergency Service solutions.

Cheers
James  

> From: James M. Polk [mailto:[email-masked]]
> Sent: Wednesday, 28 October 2009 4:49 AM
> To: Winterbottom, James
> Cc: [email-masked]
> > >> I am glad this has come up. It's a debate that has to happen if we
> are to
> > >> move

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 27 Oct 2009 16:07:05 -0400

On Oct 27, 2009, at 3:53 PM, Winterbottom, James wrote:

> Hi James,
>
> It is not unauthenticated, the device must have access to an  
> Internet feed, and that feed is always registered or authenticated  
> in some fashion.

The "feed" might be, but the mobile user of the "feed" may not be. See  
earlier examples.

>
> One of the key proposals of this draft is that the calling device,  
> and please do not think phone, think computing device (which might  
> be a game console) does register with the ESRP. This relatively  
> short-term registration is the way in which call-back is attained.  
> The registration can also be used by the ESRP to check that the  
> caller is in fact in the calling domain of the PSAP or at a minimum  
> where the point of presence in the access network is.

---

From: Marc Linsner <[email-masked]>
Date: Tue, 27 Oct 2009 17:18:32 -0400

James W.,

On 10/27/09 3:53 PM, "Winterbottom, James" <[email-masked]>
wrote:

> Hi James,
> 
> It is not unauthenticated, the device must have access to an Internet feed,
> and that feed is always registered or authenticated in some fashion.
> 
> One of the key proposals of this draft is that the calling device, and please
> do not think phone, think computing device (which might be a game console)
> does register with the ESRP. This relatively short-term registration is the
> way in which call-back is attained. The registration can also be used by the
> ESRP to check that the caller is in fact in the calling domain of the PSAP or
> at a minimum where the point of presence in the access network is.
> 

What is different in the registration process that allows "the ESRP to check
that the caller is in fact in the calling domain of the PSAP" that can't
happen via a SIP invite (with no registration)?

Thanks,

-Marc-

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 28 Oct 2009 07:18:39 +0800

I guess nothing, but it can be done in the registration. The primary advantage of the registration is to support call-back.

Cheers
James

> From: Marc Linsner [mailto:[email-masked]]
> Sent: Wednesday, 28 October 2009 8:19 AM
> To: Winterbottom, James
> Cc: [email-masked]

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 28 Oct 2009 08:02:34 +0800

SIP outbound (RFC 5626 now) works while the dialog for the call is open without a registration.  However, to take advantage of an existing flow, the subsequent call back needs a session.  A registration seemed the easiest way to ensure that this flow is maintained.

> Of Winterbottom, James
> Sent: Wednesday, 28 October 2009 10:19 AM
> To: Marc Linsner
> Cc: [email-masked]
> I guess nothing, but it can be done in the registration. The primary
> advantage of the registration is to support call-back.
> 
> Cheers
> James
> 
> Internet
> > feed,
> > please
> > > does register with the ESRP. This relatively short-term
> registration is
> > the
> > > way in which call-back is attained. The registration can also be
> used by
> > the
> > > ESRP to check that the caller is in fact in the calling domain of
> the
> > PSAP or
> > What is different in the registration process that allows "the ESRP
> to
> > check

---

From: Marc Linsner <[email-masked]>
Date: Wed, 28 Oct 2009 08:35:06 -0400

James,

Thanks, call-back was the only advantage I could come up with, so I wanted
to make sure I wasn't missing something.

-Marc-

On 10/27/09 7:18 PM, "Winterbottom, James" <[email-masked]>
wrote:

> I guess nothing, but it can be done in the registration. The primary advantage
> of the registration is to support call-back.
> 
> Cheers
> James
>

---

From: Marc Linsner <[email-masked]>
Date: Wed, 28 Oct 2009 18:51:18 -0400

Brian,

What I hear you saying: 'if we don't document how to spoof a PSAP, then
nobody will figure it out.'  Isn't that a little short sighted?

[email-masked] will figure out how to establish a SIP session with any
PSAP in the world within 10 minutes of that PSAP being accessible via the
Internet, regardless of documentation.

I believe there's more harm created in not documenting this for
[email-masked].

Granted, nobody here is looking to cause harm to a PSAP.  But
[email-masked] can certainly expend public safety resources by reporting
a bomb threat to a local school.  Should we require that all SIP calls to
the local school come from a trusted SP?  Where does it end?

This isn't the way to deal with spam.

-Marc-

---

From: Brian Rosen <[email-masked]>
Date: Wed, 28 Oct 2009 23:17:49 -0400

I'm not worried about security by obscurity.  I don't want phones (or other
devices) built to call directly.

-phonebcp says "send the call on your normal outbound call path".  That's
what I want it to say, and I don't want it to say "send it direct, bypass
your service provider.

I'm not stopping attack, I am stopping abuse.

I don't want devices that are not subscribed to services to be able to make
emergency calls (that is, if they can't make "normal" calls, they should not
be able to make emergency calls).

Brian

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 29 Oct 2009 13:58:38 +0800

My nintendo DS doesn't have a normal call provider!
Nor does my smart fridge, nor will a whole range of devices quite capable of transmitting speech over IP connections. I want these to be able to make emergency calls if they need to.

We are not in competition, you want to remain in a legacy world with VSPs, fine, I want to move past that. Emergency networks are not an add-on to standards call networks, they are their own network and application.

Cheers
James

> Sent: Thursday, 29 October 2009 2:18 PM
> To: Marc Linsner
> Cc: [email-masked]

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 29 Oct 2009 10:28:36 +0100

Brian,

Just a question for clarification below:

> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Brian Rosen
> Sent: 29 October 2009 03:18
> To: Marc Linsner
> Cc: [email-masked]
[JRE] So if my normal outbound call path is my SIP-PBX, then the SIP-PBX can route directly to the PSAP?

John

> >>>> being a poster child).  So, while indeed they
> understand, and have
> >>>> concerns
> >>>> about having to take calls from Sierra Leone VoIP
> services Pty, they
> >>>> would
> >>>> much rather have a call that went through them then a
> call that went
> >>>> through
> >>>>> domain (as in not a commercial VSP) and a VSP on the
> other side of
> >>>>> the world
> >>>>> [Don't take this as my endorsement of the draft, as I'm
> not sure I
> >>>>> agree
> >>>>>> Then, we have carefully arranged it so that there is
> no identity
> >>>>>> coming from
> >>>>>> provider, we really don't want to.  But even if we
> did, we would
> >>>>>> need a
> >>>>>> The problem we have with -direct is anonymous callers,
> and if they
> >>>>>> have any
> >>>>>> option, they would also be location-less.  Until and
> unless we get
> >>>>>> rid of
> >>>>>> (think free wifi for example) would make providing
> good identity
> >>>>>> difficult.
> >>>>>>
> >>>>>> communications systems.   The SERVICE provider is in a
> position to
> >>>>>> assist
> >>>>>> time), but even there, you end up with service
> providers like The
> >>>>>> Pirate Bay
> >>>>>> changes that eliminate service providers, and in this
> case, they
> >>>>>> provide
> >>>>>> So, I claim you have a solution in search of a
> problem.  We have
> >>>>>> solved the
> >>>>>> example escapes me, although there probably are some).
>  There is
> >>>>>> no movement
> >>>>>> have a known killer problem without some kind of
> subscription to a
> >>>>>> service
> >>>>>> that provides a good identity, for which you provide
> no answers.
> >>>>>> We have
> >>>>>> experience with the killer problem: sim-less calling
> was supposed
> >>>>>> to provide
> >>>>>> Nothing is perfect: you can get a AIM screen name
> without a very
> >>>>>> good
> >>>>>> direct access without a service provider deliberately,
> especially
> >>>>>> without
> >>>>>> really good identity from the access network is, in my
> opinion not
> >>>>>> only a
> >>>>>> On 10/26/09 7:56 PM, "Dawson, Martin"
> <[email-masked]>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> In the circuit service world - whether it was POTS or
> mobile, the
> >>>>>>> access
> >>>>>>> In some jurisdictions, such as the US, it was done
> directly from
> >>>>>>> the local
> >>>>>>> switch packets onto the Internet for their
> subscribers. They can
> >>>>>>> similarly
> >>>>>>> arrived, the PSTN had already slipped into its
> palliative stage
> >>>>>>> without
> >>>>>>> realizing it.
> >>>>>>>
> >>>>>>> involving long distance providers in POTS emergency
> calls. They
> >>>>>>> are neither
> >>>>>>> yourself and others Brian. It is time to have a
> reasoned debate.
> >>>>>>> From my
> >>>>>>> the Internet. Yes, there is free public Internet
> access (just as
> >>>>>>> there are
> >>>>>>> pay phones. All these services are still connected to
> the public
> >>>>>>> Internet
> >>>>>>> (should it prove necessary). These models need to
> take the long
> >>>>>>> view of how
> >>>>>>> emergency calling is done in the Internet age; they
> should not be
> >>>>>>> protracting

---

From: Richard Barnes <[email-masked]>
Date: Thu, 29 Oct 2009 11:36:37 +0200

... and if the answer is "yes", then how do you distinguish between  
that case and the direct case?

---

From: Marc Linsner <[email-masked]>
Date: Thu, 29 Oct 2009 08:32:13 -0400

Brian,

Please define what you consider to be a service provider.

Is Skype a service?
Is Jabber a service?
Is Google Voice a service?
Is mydomain.com hosted on a commercial site a service?
Is mydomain.com hosted on a home server a service?
Is myEnterpriseVoIP.com a service?

So, what you are saying that if I can make calls via all of the above, it's
OK for all of the above to contact an ESRP?

Are you requiring that I have a full-time proxy on-line for mydomain.com or
can I simply run a transient UA and dynamic DNS?

-Marc-

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 29 Oct 2009 16:48:15 +0100

I suspect that what Brian is saying is that anyone can be a service provider (or whatever else you want to call it) in this case provided that:

1)      they make that agreement with the PSAP providers they route calls to;

2)      they authenticate the calls requests to a level of security that meets the PSAPs (and any legal) requirements;

3)      the PSAP trusts that they have done so.

While this would normally be what we would understand as public telecommuncation operators, it doesn't mean they have to be.

regards

Keith

> On Behalf Of Marc Linsner
> Sent: Thursday, October 29, 2009 12:32 PM
> To: Brian Rosen
> Cc: [email-masked]
> So, what you are saying that if I can make calls via all of
> the above, it's OK for all of the above to contact an ESRP?
>
> Are you requiring that I have a full-time proxy on-line for
> mydomain.com or can I simply run a transient UA and dynamic DNS?
>
> -Marc-
>
>
>
> > I'm not worried about security by obscurity.  I don't want
> phones (or
> > other
> > -phonebcp says "send the call on your normal outbound call path".
> > That's what I want it to say, and I don't want it to say "send it
> > direct, bypass your service provider.
> >
> > I don't want devices that are not subscribed to services to
> be able to
> > make emergency calls (that is, if they can't make "normal"
> calls, they
> > should not be able to make emergency calls).
> >
> > Brian
> >
> >
> >> What I hear you saying: 'if we don't document how to spoof a PSAP,
> >> then nobody will figure it out.'  Isn't that a little
> short sighted?
> >>
> >> [email-masked] will figure out how to establish a SIP session
> >> with any PSAP in the world within 10 minutes of that PSAP being
> >> accessible via the Internet, regardless of documentation.
> >>
> >> [email-masked] can certainly expend public safety resources by
> >> reporting a bomb threat to a local school.  Should we require that
> >> all SIP calls to the local school come from a trusted SP?
> Where does it end?
> >>
> >>> I'm starting with the first goal.  I don't want you to be able to
> >>> take a device out of a box, plug it into a network, and have the
> >>> only call you can make be an emergency call.  I want the
> device to
> >>> actually "work" (as in be able to place calls to all the entities
> >>> that it was intended to) first, and then be able to place
> emergency calls.
> >>>
> >>> with it.  Imagine how much fun the test mechanism is as
> opposed to
> >>> placing real calls.
> >>>
> >>> If we somehow get a bad call, we need to send the cops.
> That means
> >>> we need an identity (and a location).
> >>>
> >>> I think a good cert could be the basis of a good identity, if we
> >>> could get one.  I don't see how we do that.
> >>>
> >>> Brian
> >>>
> >>>
> >>>> Is the security goal here more access control (i.e., controlling
> >>>> who can send calls to a PSAP) or attribution/identification for
> >>>> post-hoc action.
> >>>>
> >>>> If it's the latter, then ISTM that the problem can largely be
> >>>> reduced to having a certificate infrastructure that binds
> >>>> authenticated identities to real-world entities.  The
> "extended validation"
> >>>> certificates that current commercial CAs issue seem to largely
> >>>> satisfy this requirement.
> >>>>
> >>>> --Richard
> >>>>
> >>>>
> >>>>> Of course not all VSPs will have trust relationships with all
> >>>>> PSAPs.  One can hope that long term, we can evolve to
> transitive
> >>>>> trust relationships that work pretty well cross border.
> >>>>>
> >>>>> The emergency guys are actually terrified of private/individual
> >>>>> domains sending them calls, and we're telling them we
> expect that
> >>>>> to be possible, but rare, and we're giving them mechanisms that
> >>>>> will effectively allow them to turn off calls
> selectively, based
> >>>>> on factors including what domain the call comes from.
> They expect
> >>>>> that such calls will be one of the loopholes where they get
> >>>>> equivalents to sim-less calls, which drive them nuts.
> They don't
> >>>>> want ANY calls that don't come from service providers, although
> >>>>> they seem to be okay with the notion that the SP may not have
> >>>>> great identity (AOL being a poster child).  So, while
> indeed they
> >>>>> understand, and have concerns about having to take calls from
> >>>>> Sierra Leone VoIP services Pty, they would much rather
> have a call
> >>>>> that went through them then a call that went through no service
> >>>>> provider at all.
> >>>>>
> >>>>> I'm not trying to make calls direct from devices or private
> >>>>> domains impossible, but I think the notion that we're promoting
> >>>>> them is a very bad idea until we have effective mechanisms to
> >>>>> prevent abuse.
> >>>>>
> >>>>> Brian
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>> I'm a little confused.  I don't remember you objecting to
> >>>>>> requirement RE1 from RFC5012 and I remember your use
> case about a
> >>>>>> Sierra Leone VSP.
> >>>>>>
> >>>>>> Are you implying that *all* VSPs will have a trust
> relationships
> >>>>>> with *all* PSAPs?
> >>>>>>
> >>>>>> What is the difference between a call coming from a private/
> >>>>>> individual domain (as in not a commercial VSP) and a
> VSP on the
> >>>>>> other side of the world (outside the jurisdiction)?
> >>>>>>
> >>>>>> I'm trying to figure out whether you're objecting to anonymous
> >>>>>> calls to the PSAP or the mechanisms proposed in this draft?
> >>>>>>
> >>>>>> [Don't take this as my endorsement of the draft, as
> I'm not sure
> >>>>>> I agree with UAs registering with the ESRP.]
> >>>>>>
> >>>>>> -Marc-
> >>>>>>
> >>>>>>
> >>>>>>> coming from the access network provider, and because the
> >>>>>>> location is coming from that provider, we really
> don't want to.
> >>>>>>> But even if we did, we would need a really good
> identifier, and
> >>>>>>> there isn't one.
> >>>>>>>
> >>>>>>> The problem we have with -direct is anonymous callers, and if
> >>>>>>> they have any option, they would also be
> location-less.  Until
> >>>>>>> and unless we get rid of anonymity, we can't
> encourage service
> >>>>>>> provider-less calls.  The draft does not make any
> provision to
> >>>>>>> provide any kind of identity.  Many networks (think free wifi
> >>>>>>> for example) would make providing good identity difficult.
> >>>>>>>
> >>>>>>> communications systems.   The SERVICE provider is in
> a position to
> >>>>>>> assist
> >>>>>>> good SERVICE provider does.  Cutting them out is not a great
> >>>>>>> idea.  Most of the attempts to provide real time
> communications
> >>>>>>> between people have evolved to using service providers, even
> >>>>>>> when there were alternatives.  File transfer via
> something like
> >>>>>>> Torrent is a counterexample (which isn't real time), but even
> >>>>>>> there, you end up with service providers like The Pirate Bay
> >>>>>>> (R.I.P) to provide introduction services.  I don't
> think we're
> >>>>>>> going to see changes that eliminate service providers, and in
> >>>>>>> this case, they provide value to the emergency
> calling systems.
> >>>>>>> All of the emergency professionals I know have issues with
> >>>>>>> service providers, but they would react with horror if you
> >>>>>>> suggested cutting them out.  Ask them, please.
> >>>>>>>
> >>>>>>> solved the "calling network isn't the access network" problem
> >>>>>>> already.  Service providers ARE in the path now, in
> nearly every
> >>>>>>> case (in fact a counter example escapes me, although there
> >>>>>>> probably are some).  There is no movement I can detect which
> >>>>>>> would change that any time soon; quite the opposite.
> We have a
> >>>>>>> known killer problem without some kind of subscription to a
> >>>>>>> service that provides a good identity, for which you
> provide no
> >>>>>>> answers.
> >>>>>>> We have
> >>>>>>> experience with the killer problem: sim-less calling was
> >>>>>>> supposed to provide a way to make an emergency call
> in exactly
> >>>>>>> the kinds of circumstances you are describing.  Our
> real world
> >>>>>>> experience is that you create a huge problem that diverts
> >>>>>>> resources from helping people to chasing scammers and
> >>>>>>> flea-market sellers.
> >>>>>>>
> >>>>>>> good identity for example.  However, the notion that
> we're going
> >>>>>>> to provide direct access without a service provider
> >>>>>>> deliberately, especially without really good identity
> from the
> >>>>>>> access network is, in my opinion not only a no, it's
> a heck no.
> >>>>>>> I'll line up as many emergency service professionals as you
> >>>>>>> would like to tell you this is a harmful idea.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> we are to move beyond a long standing legacy misconception.
> >>>>>>>>
> >>>>>>>> In the circuit service world - whether it was POTS
> or mobile,
> >>>>>>>> the access network had full responsibility for
> delivering the
> >>>>>>>> emergency call. In that world, routing an emergency
> call meant
> >>>>>>>> getting a circuit established to the correct call center. In
> >>>>>>>> most parts of the world, this was done using the
> regional part
> >>>>>>>> of the PSTN to switch the circuit to a call center
> on the PSTN.
> >>>>>>>> In some jurisdictions, such as the US, it was done directly
> >>>>>>>> from the local exchange carrier to the call center.
> Either way,
> >>>>>>>> there was no third party involved.
> >>>>>>>>
> >>>>>>>> switch packets onto the Internet for their subscribers. They
> >>>>>>>> can similarly ensure that packets reach the local emergency
> >>>>>>>> call centers.
> >>>>>>>>
> >>>>>>>> The fact is that there was no equivalent of a VSP in the
> >>>>>>>> traditional environment. VoIP is a presence service,
> and it had
> >>>>>>>> no common equivalent in the PSTN world. It could
> have, but the
> >>>>>>>> narrowband state of technology and the common market
> use cases
> >>>>>>>> didn't support its development. By the time ISDN
> arrived, the
> >>>>>>>> PSTN had already slipped into its palliative stage without
> >>>>>>>> realizing it.
> >>>>>>>>
> >>>>>>>> It's an entrenched misconception that because the circuit
> >>>>>>>> service provided by exchange carriers was most commonly used
> >>>>>>>> for "voice" (but, it should be noted, also for fax,
> telex, tty,
> >>>>>>>> security system monitoring and, even, IP data) that VSPs are
> >>>>>>>> somehow equivalent to exchange carriers. They are not.
> >>>>>>>>
> >>>>>>>> Indeed, involving VSPs in emergency calls is the Internet
> >>>>>>>> equivalent of involving long distance providers in POTS
> >>>>>>>> emergency calls. They are neither necessary nor particularly
> >>>>>>>> helpful; they can't be guaranteed to be within the emergency
> >>>>>>>> jurisdiction; depending on them actually diminishes the
> >>>>>>>> efficacy of emergency service access. It does not help the
> >>>>>>>> caller, the emergency service, nor the third party
> to insist on
> >>>>>>>> the third party's involvement.
> >>>>>>>>
> >>>>>>>> false. There has to be a subscription of some description in
> >>>>>>>> order to get to the Internet. Yes, there is free public
> >>>>>>>> Internet access (just as there are free courtesy
> phones on the
> >>>>>>>> PSTN and free access to emergency services from pay
> phones. All
> >>>>>>>> these services are still connected to the public Internet
> >>>>>>>> infrastructure and they all represent an "operator"
> with some
> >>>>>>>> With the over-emphasis on VSPs, what is missing from
> the ECRIT
> >>>>>>>> and i3 models is the direct interface for querying
> the access
> >>>>>>>> network for subscriber data (should it prove
> necessary). These
> >>>>>>>> models need to take the long view of how emergency
> calling is
> >>>>>>>> done in the Internet age; they should not be protracting an
> >>>>>>>> unnecessary reliance on VSPs.
> >>>>>>>>
> >>>>>>>> Behalf Of Hannes Tschofenig
> >>>>>>>> considered harmful, at least given our current experiences
> >>>>>>>>

---

From: Brian Rosen <[email-masked]>
Date: Thu, 29 Oct 2009 14:35:06 -0400

Thank you.  That is what I meant, and you said it better than I was going
to.

We may also have some transitive relationships: that is, if there is a
"local" PSAP that trusts that they have done so, other PSAPs may trust that
they have done so.

Brian

On 10/29/09 11:48 AM, "DRAGE, Keith (Keith)" <[email-masked]>
wrote:

> I suspect that what Brian is saying is that anyone can be a service provider
> (or whatever else you want to call it) in this case provided that:
> 
> While this would normally be what we would understand as public
> telecommuncation operators, it doesn't mean they have to be.
> 
> regards
> 
> Keith
>

---

From: Marc Linsner <[email-masked]>
Date: Thu, 29 Oct 2009 15:27:21 -0400

These are all PSAP policy decisions.  Just as it's a PSAP policy decision to
support the suggested mechanism in the draft.  Existence of the document
describing the mechanism doesn't force PSAP policy.

I personally would like to see some PSAPs and/or PS jurisdictions line up
behind the draft before it proceeds, but I don't see any harm in it going
forward.

Of course, I'm dreaming about this special place where a PSAP actually wants
to enable communication with all their customers and not force them to be a
member of a special club.

[non-chair hat on]

-Marc- 

On 10/29/09 2:35 PM, "Brian Rosen" <[email-masked]> wrote:

>> 2)      they authenticate the calls requests to a level of security that
>> meets
>> the PSAPs (and any legal) requirements;
>>

---

From: Brian Rosen <[email-masked]>
Date: Thu, 29 Oct 2009 16:35:47 -0400

The IETF writing standards that describe how devices should bypass their
service provider and place emergency calls direct is not a PSAP policy
issue.

I'm satisfied with the current -phonebcp dictum to send calls on the normal
call path.  For an "unregistered" device, that will not allow any "calls"
including emergency calls.

I discussed this draft on the NENA LTD meeting this morning.  That may
generate some list discussion from some PSAP people who are subscribed.  I
would also like to hear from more PSAP folks on this subject.

Brian

---

From: Marc Linsner <[email-masked]>
Date: Thu, 29 Oct 2009 17:46:41 -0400

Brian,

I didn't read anything in the draft that stated devices 'should' use this
mechanism (if it's there, it needs removed).  I read it more as a device
'could' use this mechanism (as in an alternative to other mechanisms).

Further, since the ESRP is controlled by the PSAP, it certainly would be a
PSAP policy decision whether to support this mechanism.  As without the ESRP
support of unknown UA registrations, the mechanism doesn't work.

BTW, the term 'unregistered' is not in phonebcp.  I think your are
stretching the 'normal call path' to include registration with something(?).
I find nothing in phonebcp that disallows 'direct' calls to an ESRP.  If I
contact an ESRP from my UA 'directly', as long as the PSAP can call-back
using the Contact header I sent in the invite and my AOR leads back to my
UA, I've satisfied phonebcp.

What am I missing?

-Marc-

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 29 Oct 2009 18:15:58 -0400

I think we should not be too constrained by the arrangements today,  
where the VSP or possibly ISP provides caller authentication. There  
are other models; for example, I just heard a talk about the Austrian  
(cryptographic) identity card that is leveraged by lots of other  
institutions, including private entities (banks, health clubs, ...).  
For SIP, this could be used for RFC 4474. Thus, you could imagine that  
the authentication is done individually, at higher strength than  
typical carrier authentication with semi-anonymous accounts. As per  
the example, this may be viable in certain jurisdictions before it's  
feasible elsewhere. There's a lot of activity in the identity space,  
so we should be allowing for a variety of future options, rather than  
just what's happening today.

Henning

On Oct 29, 2009, at 4:35 PM, Brian Rosen wrote:

>>> On 10/29/09 11:48 AM, "DRAGE, Keith (Keith)" <[email-masked] 
>>> >
>>> wrote:
>>>
>>>> 1)      they make that agreement with the PSAP providers they  
>>>> route calls
>>>> to;
>>>>
>>>>>>>>>>>> and if
>>>>>>>>>>>> the emergency calling system when it needs more  
>>>>>>>>>>>> information.
>>>>>>>>>>>> That's what a
>>>>>>>>>>>>> directly

---

From: "Dawson, Martin" <[email-masked]>
Date: Fri, 30 Oct 2009 09:45:25 +0800

Hi Brian,

The significance of "VSPs" is twofold:

1. They are a presence service (long term significance)
2. They provide a bridging service to the circuit service world (temporary significance)

You are taking the temporary significance and attempting to hard code it into a long term role.

You have been using the term "service" as if it means something quite specific (it does not). Focussing on the following comment:

" The IETF writing standards that describe how devices should bypass their
service provider and place emergency calls direct is not a PSAP policy
issue."

It seems presumptious. You appear to want to prevent the IETF from saying how an Internet connected device can establish communication with an Internet connected emergency service. You appear to be saying that there is some "official service provider" that has to be in the middle for this to happen. The phrase "bypass their service provider" implies presumption of some formal role that I don't think exists.

I travel to the US frequently; if I subscribe to T-Mobile's hotspot network for example, then I want to be able to make an emergency call from that point of connection. I don't want to have to previously ensure that I have a subscription with some or other "service" through whom I have to go if I want emergency service. I am subscribed to a service - "TMO's hotspot network" - that's the real subscriber information and point of regulatory control that is relevant.

If I have a MiFi device in my car connected to Verizon's 3G service and there are a variety of devices connected to the Internet through that device, then I want those devices to be valid options to make an emergency call. If my child has their PSP connected via it then I want them to be able to call help without the presumption that there also has to be some sort of VoIP subscription on that PSP. I am subscribed to a service in this context - "Verizon's 3G service" - that's the real subscriber information and point of regulatory control in that use case.

I don't know where this "edict" comes from that only devices that are normally used to "make calls" should be able to make emergency calls. Time and technology makes the whole presumption of what constitutes "making calls" a pretty fuzzy concept.

You seem to have invented a problem, then invented a solution which... ironically... doesn't address the invented problem anyway. Either access to LoST emergency routing requests and to PSAP URIs is going to be blocked to all but a privileged set of VoIP providers or there's a hole in the "solution" that can have a truck driven through it.

The draft proposed provides excellent guidance for a general and reference Internet emergency calling client that is consistent with ECRIT. It provides excellent guidance for jurisdictions that want to provide emergency access from the Internet, isolated to their jurisdiction, and without presumption of, potentially foreign, VSP involvement. Personally I think it's what Phone BCP always could have been but, regardless, it's neither dangerous nor useless as you seem to be suggesting.

Cheers,
Martin
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: Friday, 30 October 2009 7:36 AM
To: Marc Linsner
Cc: [email-masked]
Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered

Brian

---

From: Brian Rosen <[email-masked]>
Date: Fri, 30 Oct 2009 09:17:11 -0400

Martin

Show me a popular two way real time communications system where there is not
a middleman providing a service deemed important enough to the users that
they don't mind having the service in the path one way or another.

If nothing else, the service provider provides a consistent naming mechanism
used as identities for establishing communication.

That's a service provider, and their aren't any interesting real time two
way communications services that don't have a service provider.

It may be that some day in the future, we have such entities, but even in
things like P2PSIP, there is an enrollment server that issues credentials,
and unless you have such a credential, you can't get into the overlay.
That's a good enough service provider for me, especially if the callers on
such an overlay send calls to emergency services the same way they send any
other call.

I don't want the ESRP providing an alternate path to make calls.  I don't
want a device, like a P2PSIP device, having a way to make an emergency call
if they can't make a regular call.

I claim you have re-invented a problem we explicitly don't want to solve.
Put another way, if you are in the circumstance that your solution helps, we
don't want your call.  That is because we already have a similar situation,
and we have serious problems with it.  Until and unless you solve that
problem, and I think it's pretty unsolvable without a much better identity
system, then we can't tolerate your "solution".

If there are really good identity systems then I suspect we could use them
to avoid the abuse problem.  But even so, I think that the emergency call
community would still prefer that callers use their normal call path, and
that if they can't make "normal" calls, then they can't make emergency
calls.  I'll ask about that.  They like service providers, even though they
often have difficulties with them.

On 10/29/09 9:45 PM, "Dawson, Martin" <[email-masked]> wrote:

> You have been using the term "service" as if it means something quite specific
> (it does not). Focussing on the following comment:
> 
> It seems presumptious. You appear to want to prevent the IETF from saying how
> an Internet connected device can establish communication with an Internet
> connected emergency service. You appear to be saying that there is some
> "official service provider" that has to be in the middle for this to happen.
> The phrase "bypass their service provider" implies presumption of some formal
> role that I don't think exists.
> 
> I travel to the US frequently; if I subscribe to T-Mobile's hotspot network
> for example, then I want to be able to make an emergency call from that point
> of connection. I don't want to have to previously ensure that I have a
> subscription with some or other "service" through whom I have to go if I want
> emergency service. I am subscribed to a service - "TMO's hotspot network" -
> that's the real subscriber information and point of regulatory control that is
> relevant.
> 
> If I have a MiFi device in my car connected to Verizon's 3G service and there
> are a variety of devices connected to the Internet through that device, then I
> want those devices to be valid options to make an emergency call. If my child
> has their PSP connected via it then I want them to be able to call help
> without the presumption that there also has to be some sort of VoIP
> subscription on that PSP. I am subscribed to a service in this context -
> "Verizon's 3G service" - that's the real subscriber information and point of
> regulatory control in that use case.
> 
> I don't know where this "edict" comes from that only devices that are normally
> used to "make calls" should be able to make emergency calls. Time and
> technology makes the whole presumption of what constitutes "making calls" a
> pretty fuzzy concept.
> 
> You seem to have invented a problem, then invented a solution which...
> ironically... doesn't address the invented problem anyway. Either access to
> LoST emergency routing requests and to PSAP URIs is going to be blocked to all
> but a privileged set of VoIP providers or there's a hole in the "solution"
> that can have a truck driven through it.
> 
> The draft proposed provides excellent guidance for a general and reference
> Internet emergency calling client that is consistent with ECRIT. It provides
> excellent guidance for jurisdictions that want to provide emergency access
> from the Internet, isolated to their jurisdiction, and without presumption of,
> potentially foreign, VSP involvement. Personally I think it's what Phone BCP
> always could have been but, regardless, it's neither dangerous nor useless as
> you seem to be suggesting.
> 
> Cheers,
> Martin

---

From: Brian Rosen <[email-masked]>
Date: Fri, 30 Oct 2009 09:47:33 -0400

I want it to say MUST NOT use that mechanism :)

I don't want alternative ways to make emergency calls.  I want what phonebcp
already says: send the call on the normal path and a normal identity and
callback (which implies using a normal registration).

I understand that the local authority can disable the ESRP registration
mechanism.  If this draft goes forward against my advice, then I will ask
that there be text that says if the registration cannot be completed, the
device MUST NOT send emergency calls direct to that ESRP, and must use its
normal call path for emergency calls.

We can't stop calls from entering the emergency services IP network without
passing through a service provider.  I have no wish to add any mechanism
which would attempt to do so.  If it would help,  I would be happy to beef
up language in framework that discusses this problem and what "normal call
path" means.  I would even be very happy to add a item to phonebcp that says
"if you can't make normal calls, you can't make emergency calls", although
we might get hung up on defining "normal", because if at some time when you
need help the only number that could actually answer your call, sent down
the same call path as you would normally send any call, is the emergency
service, then we want that call.

We frequently use you as an example.  If you have a SIP Registrar and proxy
server in your home (or boat) and you have a phone that registers with it,
and you normally make calls to your family and friends with that setup, then
I suspect that there is some service provider helping your proxy server
connect to your family and friends.  We would prefer your emergency calls go
through that service provider.  However, if for some reason, your proxy
server forwarded an emergency call direct to the ESInet, it will normally go
through.

Unfortunately for you, if someone decides to attack the emergency call
system, and it gets overloaded for some period of time until we can mitigate
the attack, we may have to make choices on which calls we answer and which
ones we don't.  Your call sent through your proxy server to the ESInet
direct may get lower priority than the same call sent through the service
provider, if we notice that most of the attack calls are coming direct from
the Internet, rather than going through a service provider we know about.
We're building in explicit attack mitigation strategies like that.  It's not
unreasonable: if you have 5 sources entering your network, and one of them
is the place where all (or most) of the attack is coming from, you shut off
that source until you have a better filter.

If a whole lot of devices assume the direct path is the preferred path, that
would be bad for them.

Furthermore, there is additional data sent to the emergency system (in the
U.S.) with the call from the service provider.  That information may be
useful in helping you.  The device can actually send the information, but
while while we are pretty sure we can get most service providers to give it
to us, we are pessimistic most devices will.  Devices that have sensors,
where the sensor data is useful for emergency calls may very well do it.
Medical monitoring devices for example.  NENA will be asking the IETF to
standardize this soon, so that all service providers anywhere could provide
it to all emergency services.  It has things like subscriber (as opposed to
caller) contact data, class of service information, SP contact data, etc.
When things go wrong, the PSAP will often contact the SP and get help.  The
SP often has tools and mechanisms that CAN help.

Brian

---

From: Brian Rosen <[email-masked]>
Date: Fri, 30 Oct 2009 10:06:42 -0400

Well, yes.

Normally, your SIP-PBX would route calls outside the domain to some kind of
carrier.  That is what I want it to do, but I can foresee circumstances
where the PBX sends calls to the ESRP.  I would like the ESRP to know about
the PBX (that is, have it's identity in some list it has, one way or
another, so that when it lowers priority of calls from unknown sources,
those calls are not lowered.  I think such arrangements will be uncommon,
but possible.

Brian

On 10/29/09 5:28 AM, "Elwell, John" <[email-masked]>
wrote:

>> phones (or other
>> be able to make
>> opposed to placing
>> That means we need
>>>>>> PSAPs.  One
>>>>>> domains
>>>>>>> requirement RE1
>>>>>>> individual
>>>>>>> calls to the
>>>>>>>> idea.  Most of
>>>>>>>>> traditional
>>>>>>>>> equivalent of
>>>>>>>>> order to get to

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 30 Oct 2009 17:53:18 +0100

Brian,

So suppose my SIP-PBX is in the UK and uses a VoIP service provider in the UK. I am in a hotel in the US and make an emergency call using a device that uses my SIP-PBX in the UK as its outbound proxy. From the location determined by my device, the call needs to go to a PSAP in the US. Will routing via the UK service provider really help? It seems unlikely that the UK service provider would have an arrangement with a US PSAP. So perhaps the UK provider could route it on to a US provider, which hopefully would have such an arrangement. This round-about routing seems to increase the chances of failure.

It seems what is really needed in this situation is either:
- routing directly from the SIP-PBX in the UK to the US PSAP; or
- my device sends the call directly to the US PSAP.

John

> From: Brian Rosen [mailto:[email-masked]]
> Sent: 30 October 2009 14:07
> To: Elwell, John; Marc Linsner
> Cc: [email-masked]
> > [JRE] So if my normal outbound call path is my SIP-PBX,
> then the SIP-PBX can
> > route directly to the PSAP?
> >
> > John
> >
> >
> >>
> >>>>>> but rare, and we're giving them mechanisms that will
> effectively
> >>>>>> allow them
> >>>>>> call comes from.  They expect that such calls will be
> one of the
> >>>>>> loopholes
> >>>>>> impossible, but I think the notion that we're
> promoting them is a
> >>>>>> very bad
> >>>>>>> with *all*
> >>>>>>>> the access network provider, and because the
> location is coming
> >>>>>>>> from that
> >>>>>>>> anonymity, we can't encourage service provider-less
> calls.  The
> >>>>>>>> draft does
> >>>>>>>> the attempts to provide real time communications
> between people
> >>>>>>>> have evolved
> >>>>>>>> transfer via something like Torrent is a
> counterexample (which
> >>>>>>>> isn't real
> >>>>>>>> going to see
> >>>>>>>> I know have issues with service providers, but they
> would react
> >>>>>>>> with horror
> >>>>>>>> providers ARE in the path now, in nearly every case
> (in fact a
> >>>>>>>> counter
> >>>>>>>> are describing.  Our real world experience is that
> you create a
> >>>>>>>> huge problem
> >>>>>>>> identity for example.  However, the notion that
> we're going to
> >>>>>>>> provide
> >>>>>>>>> correct call center. In most parts of the world,
> this was done
> >>>>>>>>> using the
> >>>>>>>>> exchange carrier to the call center. Either way,
> there was no
> >>>>>>>>> third party
> >>>>>>>>> involved.
> >>>>>>>>>
> >>>>>>>>> environment. VoIP is a presence service, and it had
> no common
> >>>>>>>>> equivalent in
> >>>>>>>>> common market use cases didn't support its
> development. By the
> >>>>>>>>> time ISDN
> >>>>>>>>> free courtesy phones on the PSTN and free access to
> emergency
> >>>>>>>>> services from
> with some
> >>>>>>>>> level of
> >>>>>>>>> With the over-emphasis on VSPs, what is missing
> from the ECRIT
> >>>>>>>>> and i3 models

---

From: Brian Rosen <[email-masked]>
Date: Fri, 30 Oct 2009 13:36:38 -0400

Nope, your UK provider can correctly route.  Actually, if your phone is
phonebcp compliant, all that means is the service provider forwards the call
where the phone is trying to send it (to the ESRP learned from the ECRF).
Assuming the UK provider gets the location from the phone (in the
Geolocation header), it could route, or, perhaps more relevant, it can
verify the route. There is no need to send it through a U.S. Service
provider, who couldn't help us at all.

And the UK provider may well be able to help.  We want to know about them.
They may have information that is useful.

As was discussed a few messages ago, it may be that the UK service provider
has an identity that the UK emergency call authorities trust.  We may be
able to arrange that the US emergency call authorities can figure out that
the UK trust relationship is in place, and transitively trust the UK
provider, even though it has no relationship with that provider.  This might
be as simple as a signature on a cert by the UK authorities that the US
authorities can verify simply by having access to the (presumably well
known) UK CA cert.  I think we will have such certs available for US service
providers if other emergency authorities wish to use similar mechanisms.

Brian

On 10/30/09 12:53 PM, "Elwell, John" <[email-masked]>
wrote:

> Brian,
> 
> So suppose my SIP-PBX is in the UK and uses a VoIP service provider in the UK.
> I am in a hotel in the US and make an emergency call using a device that uses
> my SIP-PBX in the UK as its outbound proxy. From the location determined by my
> device, the call needs to go to a PSAP in the US. Will routing via the UK
> service provider really help? It seems unlikely that the UK service provider
> would have an arrangement with a US PSAP. So perhaps the UK provider could
> route it on to a US provider, which hopefully would have such an arrangement.
> This round-about routing seems to increase the chances of failure.
>

---

From: Marc Linsner <[email-masked]>
Date: Fri, 30 Oct 2009 13:46:16 -0400

Brian,

"Normal Call Path" was NOT added to phonebcp for the purpose of the
perceived security you describe.  The advantage (and the reason it's in
phonebcp) to using the normal call path is due to it being the most likely
mechanism to work.  Unused/untested mechanisms are more likely to fail when
tried for the first time verses mechanisms that are used/tested daily.
Emergency time is not the time to test a new mechanism, hence use the normal
call path, the same one you just used to call grandma, to summons emergency
assistance. (This is a negative against this proposed mechanism.)

If you are evangelizing within the PS community that 'sip:[email-masked]' is
less of a threat than 'sip:[email-masked]', I suggest that is the
wrong message to be spreading. Please stop now. This will only lead to the
thousands of personal injury lawyers making big $$ at the expense of the PS
community.  

As you are intimately aware, there are millions of 'vanity' domains in use
and it's growing. Its growing not just in the individual market, but in the
small/medium business market. You also know there are thousands of hosting
companies providing services to the owners of vanity domains (email, web,
ftp, etc.).  I expect in the near future that hosting providers will add sip
proxy services to their list of wares.

My guess would be that PS officials would like to treat their customer known
as -'sip:[email-masked]' the same as their customer known as
-'sip:[email-masked]'.  The domain name does not dictate the level of
urgency in the request for emergency assistance, nor the veracity of the
caller.

When an overload of the ESInet exists, I would suggest to look for other
parameters to use in decision process of how to populate the various queues.

- Are the calls from all the same location?
- Is it reasonable that the IP address/network can be at the reported
location?
- How many calls have we received over a period of time from this AOR? IP
address/network? Location?

Simply using the domain/AOR as the black and white rule, as you suggest,
will lead to big problems.

Just my opinion,

-Marc-

On 10/30/09 9:47 AM, "Brian Rosen" <[email-masked]> wrote:

>>>>>>>>>>>> level of information about the caller.
>>>>>>>>>>>>

---

From: Brian Rosen <[email-masked]>
Date: Fri, 30 Oct 2009 14:29:29 -0400

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

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. 

In most cases we're going to have hard connections, or more likely VPNs from
service providers to the ESInet routers.  That will probably handle 90+
percent of calls, but we'll still have substantial numbers coming from the
big I Internet.  We do want to know where they are coming from, and we will
have SOME form of identity that we trust to separate those we know about
from those we don't.

This is a percentages game.  Most of the time, calls will be accepted no
matter how they get to the ESInet.  If you want your calls to get through
when things are bad, send them the way you send all your other calls; that
will work okay.  If you break that (by encouraging people to send them
direct), then we'll have more problems.

I'm back to the basic tenet: if you can use the service to create media
sessions to others, you can use it to send emergency calls, and we want the
calls sent the same path (because it will work).  If you can't use the
service (like, you can't register for one reason or another), we don't want
you to be able to make emergency calls.

To be fair, there is at least one country I know of that doesn't agree.
They have documented a small number of good calls in with the tens of
thousands of bad ones, and think its worth it to handle the bad ones in
order to get to the good ones.  Most PSAPs I know of don't.

And furthermore, there are some regulations around this that are nation
specific, and I think we don't need the IETF to wade into trying to figure
out how to meet those regulations.  In most cases, we don't really know how
the regulator intends the regulations to cover devices on the Internet.

Brian

On 10/30/09 1:46 PM, "Marc Linsner" <[email-masked]> wrote:

>>>>>>> 1)      they make that agreement with the PSAP providers they route
>>>>>>> calls
>>>>>>> to;
>>>>>>>

---

From: Marc Linsner <[email-masked]>
Date: Fri, 30 Oct 2009 16:14:47 -0400

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

> 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.
:^)

> these systems, we're unlikely to be able to have emergency services special

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: Fri, 30 Oct 2009 16:55:30 -0400

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

---

From: Marc Linsner <[email-masked]>
Date: Fri, 30 Oct 2009 18:12:13 -0400

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-

---

From: "Dawson, Martin" <[email-masked]>
Date: Sat, 31 Oct 2009 09:18:11 +0800

Hey Brian,

Maybe if you keep saying "service provider" we'll all start believing it means "VSP" and it really does have some quintessential significance to emergency calling...

However, to quote Watto (Phantom Menace):

   "What? You think you're some kind of Jedi, waving your
    hand around like that?"

:)

Sure PSAP providers like to have a "service provider" they can point their finger at. They like someone who might be a source of forensic information related to the source of nuisance calls. In particular, it's really useful if that provider is in the same jurisdiction that they are. That would be the 'I' SP rather than the 'V' SP that you keep trying to steer the focus back to.

Cheers,
Martin
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: Saturday, 31 October 2009 5:29 AM
To: Marc Linsner
Cc: [email-masked]
Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered

Brian

---

From: "Dawson, Martin" <[email-masked]>
Date: Sat, 31 Oct 2009 09:27:29 +0800

Indeed - and I think this actually militates against the only other argument for using the "normal" call path as described in phone BCP. "Normal" is effectively meaningless. Further, the proposition that this results in a more robust implementation is highly questionable.

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: [email-masked] [mailto:[email-masked]] On Behalf Of Marc Linsner
Sent: Saturday, 31 October 2009 9:12 AM
To: Brian Rosen
Cc: [email-masked]
Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered

-Marc-

---

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

There is no doubt that the PSAPs care about the access provider, because the
access provider is responsible for location.  They want a good identity from
that location provider, and they want the data that it provides to have some
kind of integrity protection.

It is an advantage that the access provider is local.

However, calls don't come from access providers, they come from service
providers who provide some sort of real time two way media session service
(recognizing that often the access network and the SP that provides the
calling service are the same entity).  That's the SP we're talking about.

Unlike the calling network, where there is at least a rudimentary
authentication system in place always, there are many access networks that
have no authentication at all, which gives rise to the abuse problem that
makes this idea not tenable.  There is no reason to believe that is going to
change.

I also point out, once again, that using the access network as the source of
authentication means that we are using an IP address as an identifier.  IP
addresses make lousy identifiers.  They are addresses, not identifiers.

Oh, one more thing about this idea:

It means that devices have to have a SIP stack, regardless of what they
actually use to place calls.   That's okay for some devices, but of course
there are many, many more devices and services that don't use SIP from the
device to the service provider.  It's one thing to say that the SP has to
gateway to SIP if its devices don't already speak SIP.  It's quite another
to say that every device has to be able to speak SIP for emergency calls
regardless of what it uses for everything else.  There would be similar
daunting problems for codecs.

On 10/30/09 9:18 PM, "Dawson, Martin" <[email-masked]> wrote:

> Hey Brian,
> 
> Maybe if you keep saying "service provider" we'll all start believing it means
> "VSP" and it really does have some quintessential significance to emergency
> calling...
> 
> Sure PSAP providers like to have a "service provider" they can point their
> finger at. They like someone who might be a source of forensic information
> related to the source of nuisance calls. In particular, it's really useful if
> that provider is in the same jurisdiction that they are. That would be the 'I'
> SP rather than the 'V' SP that you keep trying to steer the focus back to.
> 
> Cheers,
> Martin

---

From: "Winterbottom, James" <[email-masked]>
Date: Sun, 1 Nov 2009 05:44:43 +0800

I have puzzled over a number of the comments below and I think you just don't get what we mean by an access provider Brian.
Specific comments inline.
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Brian Rosen [[email-masked]]
Sent: Saturday, October 31, 2009 9:01 AM
To: Dawson, Martin; Marc Linsner
Cc: [email-masked]
Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered

[AJW] The access provider is actually THE BEST SOURCE of the identity information to the equivalent of what they get today for landline. The access provider knows in whose name the access service is provided. This is exactly the same as what happens with a landline today, or a mobile for that matter, or a public telephone. Making the assumption that the person that rents the line is the person that makes the call is a fundamentally flawed assumption, the best you can ever get is the identity of the person that rents the service.

[AJW] The access provider is ALWAYS LOCAL. i don't understand you comments here at all.

[AJW] Fundamentally wrong. ALL TRAFFIC comes via the access provider, that is why they are the access provider. Are you suggesting that calls somehow use a different path to enter the Internet than through the access provider's network, if so, isn't that second path also provided by an access provider?

[AJW] Are you saying that the person that ultimately provides the access service doesn't have to do any kind of authentication, contractually or cryptographically, in order to get their fibre connected into the Internet? I simply don't believe you, and if that is the case I want to move where this is possible. Ultimatley, if you provide an open Internet connection, and the users you allow to connect to it start making nuisance calls then you as the access provider will be held responsible. This is reasonable. And yes they will know where you are, and yes you will get hit with a big stick. I also think that there are enough logs in the system that if it is the same user doing it all the time you could take pretty reasonable steps to stop them from connecting to the network at all.

[AJW] I have a few comments on this. An address identifies where to send traffic, so it is an identifier, it identifies a device at a point in time. For the purpose of this discussion I am trying to get help to the person on the end of the device. I have absolutely no way of ever knowing precisely who they are, so this whole "person identity" discussion is entirely moot, the best I can EVER know, as I stated before, is who is paying for the service, access or phone. On my access provider, I can assure you that modem does need to authenticate, so my access provider absolutely knows that the modem on the end of this service is paid for by me. My wife and children live in this house too, and anyone of them can also use a computer connected to the network in my house, sometimes I let visitors use it too. This is no different to a conventional phone service, and the PSAP operator cannot assume that it is me that is calling, the only thing that they can be sure of is that it is a p
 hone in my house. Using the access provider to authenticate and provide information in this manner is a very good idea, and guess what, this is EXACTLY what ECRIT Direct is saying. Keep everything local!

[AJW] This is ONLY true is the device wants to be compliant with this specification. This specification builds on phone BCP and provides an end-game solution, it does not mean that things in Phone BCP cannot be used.

Cheers
James

---

From: "Dawson, Martin" <[email-masked]>
Date: Sun, 1 Nov 2009 08:47:04 +0800

Promoting unnecessary elements in architectures tends to result in weak arguments being made; I think this is a good example of that. Looking at each rhetorical device in turn:

> However, calls don't come from access providers, they come
> from service providers

No. They come from people making emergency calls.

> ...providers who provide some sort of real time two way
> media session service

You keep pushing this meme... but I don't get it. You demand an alternative example? There's this thing called the world wide web. It's in pretty common use; you may have heard of it. Services exist on the WWW; people interact in two way multimedia sessions with those services. There are certainly some "agencies" who would like all access to those services to be mediated and proxied by... well... themselves; and they'd like to pick up a tariff on the way through of course. It's not really working out because, as above, it's a unnecessary to the architecture. I'll repeat; there's no analogue for this from the PSTN/circuit-service world. People could dial whatever "address" on the PSTN they wanted without somebody "insisting" they had to be a gateway.

> Unlike the calling network, where there is at least a
> rudimentary authentication system in place always, there are many
> access networks that have no authentication at all

1. "Calling Network"? What is that exactly? There's just one network of interest here; it's the Internet. You appear to be elevating VSPs to "network" status.

2. You're saying it's impossible to have a VSP that doesn't require authentication?

3. Please list these "many" access networks that don't require authentication. Regrettably, there's a paucity of them and I think they are becoming less, not more, common. In any case, for every "free café hotspot" there's a public Internet provider on the other side that knows very well who owns that subscription - just as there was a LEC who knew who owned the diner payphone from which a 9-1-1 call could be made from.

> IP addresses make lousy identifiers.  They are addresses, not
> identifiers.

I'm not as steeped in phoneBCP as some. Where is the bit that says the ESRP sees a call from a proxy (VSP) as coming from anything other than an IP address? Where does phoneBCP enforce the A&A you appear to be kina sorta mandating? On the other hand, the thing that's nice about the access provider being the "identity" source is that, being in the same jurisdiction as the ESRP, it becomes a local jurisdiction issue as to how the interaction to obtain that "call related" information occurs. The IETF doesn't actually have to worry about that bit; NENA should for the US though. It also becomes a local jurisdictional issue as to how calls that originate from recognized local ISP address allocations are handled. It's much more tractable (tenable) than trying to apply a local policy to foreign proxy addresses that could be popping in from all over the planet. I suggest that these may be the calls that end up down the priority queue in the long run.

> It means that devices have to have a SIP stack, regardless of
> what they actually use to place calls.

"Have to"? Only if the device vendor wants to surely. Personally, I like the idea of being able to download an ECRIT-direct reference client implementation to my Android device and being able to use it however and wherever I connect to the Internet. And I like the idea that it'll work regardless of the numerous presence subscriptions that come and go on my device. Even better, I like the idea of it being baked into a future release of Android altogether. Same goes for iPhones... if they're your cup of tea.

You keep saying "SP", Brian. But there are at least an "I" SP, a "V" SP, and the "E" SP involved in the plot you describe. You are talking about the VSP; I wonder why you try so hard to avoid that specificity.

Cheers,
Martin