[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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:

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


On 10/29/09 3:27 PM, "Marc Linsner" <mlinsner at cisco.com> wrote:

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" <br at brianrosen.net> wrote:

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)" <drage at alcatel-lucent.com >
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:

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

-----Original Message-----
From: ecrit-bounces at ietf.org [mailto:ecrit-bounces at ietf.org]
On Behalf Of Marc Linsner
Sent: Thursday, October 29, 2009 12:32 PM
To: Brian Rosen
Cc: ecrit at ietf.org
Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct
considered

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-



On 10/28/09 11:17 PM, "Brian Rosen" <br at brianrosen.net> wrote:

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


On 10/28/09 6:51 PM, "Marc Linsner" <mlinsner at cisco.com> wrote:

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?

Joey at miscreant.org 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
John.Q.Public at ordinary_citizen.com.

Granted, nobody here is looking to cause harm to a PSAP.  But
Joey at miscreant.org 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-



On 10/27/09 11:00 AM, "Brian Rosen" <br at brianrosen.net> wrote:

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


On 10/27/09 10:39 AM, "Richard Barnes" <rbarnes at bbn.com> wrote:

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:

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




On 10/27/09 9:02 AM, "Marc Linsner" <mlinsner at cisco.com> wrote:

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-


On 10/26/09 8:59 PM, "Brian Rosen" <br at brianrosen.net> wrote:

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"
<Martin.Dawson at andrew.com>
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

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

FYI: feedback from Brian regarding a recent ECRIT
contribution.

-----Original Message-----
From: geopriv-bounces at ietf.org
[mailto:geopriv-bounces at ietf.org] On Behalf Of Rosen, Brian
Sent: 26 October, 2009 23:10
To: geopriv at ietf.org
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
Geopriv at ietf.org
https://www.ietf.org/mailman/listinfo/geopriv


_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www.ietf.org/mailman/listinfo/ecrit


_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www.ietf.org/mailman/listinfo/ecrit




_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www.ietf.org/mailman/listinfo/ecrit









_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www.ietf.org/mailman/listinfo/ecrit







_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www.ietf.org/mailman/listinfo/ecrit