Subject: [Geopriv] NENA Requirements

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 10 Mar 2007 21:47:21 +0200

Some reviewers of <draft-ietf-geopriv-l7-lcp-ps-00.txt> note that the 
requirements in
http://www.nena.org/media/files/08-505_20061221.pdf also have to be 
considered.

Interestingly, this document was published long after the design 
team work took place were these requirements could have been 
introduced.

Here are the requirements and I will copy them in a separate mail:

4 Requirements

These requirements are excerpted from the NENA TRD, NENA Requirements
for Location Information to Support Emergency Services, for the
convenience of the reader. If this document should inadvertently differ
from the TRD, the TRD is to be considered the normative reference.
As defined in the TRD, and as excerpted here, the terms "shall", "must ",
and "required" are used in this section to indicate requirements and
to differentiate from those parameters that are recommendations.

Recommendations are identified by the word “should.” Optional,
desirable capabilities are identified by the words "desirable" or
"preferably".

4.1 Location Determination and Acquisition

DA1 – The access network shall provide a mechanism for determination
and acquisition of location information, and support queries for
location.

DA2 – The location estimate used shall be that associated with the
physically (wire, fiber, air) connected network.

DA3 – Location may be requested at any time. Location information must
be associated with the device at the time the location is requested.

DA4 – Location acquisition should be provided by a consistent method
across all network configurations.

DA5 – Location determination and acquisition mechanisms must be
applicable to emergency calling, and may also be applicable to a wide
range of value-added location-based services.

DA6 – Location determination and acquisition techniques shall support
both NENA i2 and i3 network architectures.

DA7 (Location 1400-0100 from LTD WG i3 rqmts) – When measurement
based-location determination mechanisms fail, the most accurate
location information available should be provided. Examples include:
For mobile, the Wireless Service Provider might provide tower/Access
Point location, last known fix, etc. For wireline, a LIS might provide
a civic location that defines the serving area of an access point,
e.g., the State of Texas.

DA8 – Location determination and acquisition must provide minimal
impact to call setup time in the event that location is not known ahead
of time.

DA9 – Where a device is not location aware the IP Access network should
have the ability to provide a location estimate on behalf of the
device.

DA10 – Location acquisition methods should not require modification of
hardware/firmware in home-routers/modems.

DA11 – A location determination method must exist that does not require
network hardware replacement.

DA12 -- The location acquisition protocol shall allow the requesting
device to specify a response time requirement to the LIS when
requesting location information. The response time is expressed as the
maximum time that the requesting node is prepared to wait for location
information. The LIS is required to provide the most accurate location
fix it can within the specified response time.

4.2 Location Representation

Location Representation refers to the form and contents that are used
to represent the geographic location of an Endpoint.

Rep1 – Location information may be provided as location-by-value or
location-by-reference and the form is subject to the nature of the
request.

Rep2 – Location determination and acquisition mechanisms must support
all location information fields defined within a PIDF-LO.

Rep3 – Location acquisition mechanisms must allow for easy backwards
compatibility as the representation of location information evolves.

Rep4 – All representations of location shall include the ability to
carry altitude and/or floor designation. This requirement does not
imply altitude and/or floor designation is always used or supplied.

4.3 Location Security and Dependability

LocSec1 – Location information shall only be provided to authenticated
and authorized network devices. The degree of authentication and
authorization required may vary depending on the network.

LocSec2 – Location determination and acquisition methods should
preserve privacy of location information, subject to local laws and
regulations.

LocSec3 – The location or location estimate of a caller should be
dependable.

LocSec4 – The location acquisition protocol must support authentication
of the Location Information Server, integrity protection of the
Location Information, and protection against replay.

LocSec5 – The location source shall be identified and should be
authenticated. This includes manually entered location1.

LocSec6 – Where a location is acquired and cached prior to an emergency
call, it should be refreshed at regular intervals to ensure that it is
as current as possible, in the event location information cannot be
obtained in real time.

LocSec7 – Where location by-reference is used the appropriate privacy
policies must be implemented and enforced by the LIS operator.

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 10 Mar 2007 22:31:40 +0200

Hi all,

I went through the requirements and most of them seem to be pretty 
irrelevant. Please find a few minor comments below:

Hannes Tschofenig wrote:
> Interestingly, this document was published long after the design team 
> work took place were these requirements could have been introduced.
>
>

I think that this is the wrong concept.

I think what you really want is an indication about the granularity of 
the returned location information.

> authorization required may vary depending on the network.
I guess that this refers to location-by-reference only.

> LocSec3 – The location or location estimate of a caller should be
What does "dependable" mean in this context?

> authenticated. This includes manually entered location1.

I wonder how this would look like.

> as current as possible, in the event location information cannot be
This is not a security requirement.

> policies must be implemented and enforced by the LIS operator.

What does this mean in context of requirement LocSec2 ?

Ciao
Hannes

---

From: "Winterbottom, James" <[email-masked]>
Date: Sat, 10 Mar 2007 15:35:48 -0600

Hannes,

> fix it can within the specified response time.

"I think that this is the wrong concept.

I think what you really want is an indication about the granularity of
the returned location information."

Wireless systems today provide for several types of "quality of
service". They allow you to specify the horizontal and vertical accuracy
that you want determination within, and a time delay, no-delay,
low-delay, delay-tolerant. In reality most systems in the network use
only the latter 3. The problem with this approach is however that there
is no definitive value that you can place on what low-delay or
delay-tolerant means, they are arbitrary. This requirement seeks to
provide a LIS with a means of making a definitive choice. If there is an
alternative am pretty keen to hear it, but basing request purely on
accuracy only address half the problem, and probably not the critical
half.

Cheers
James
------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

---

From: "Dawson, Martin" <[email-masked]>
Date: Sat, 10 Mar 2007 21:03:38 -0600

Well, I do take exception to the suggestion that the NENA requirements
were introduced long after the design team work was done. The NENA
requirements were available in draft long before geopriv even came to
grips with beginning to accept the idea of an "L7" protocol.

I certainly tried to get people to consider the requirements from NENA -
but spent most of my time responding to arguments about why opinions
driven by the i2 architecture weren't relevant ("architecture is broken"
as one commentator put it). It's impossible to discuss requirements
productively if some group of people simply think the source is
unqualified to present any and spend all their time trying to discredit
proposals on that basis. Thank you for not smoking anyone? As I recall,
the specific point was about why LbyR was needed and it was before
geopriv had begun to assimilate the value of that concept as well.

I think all of the NENA requirements have been raised and discussed -
the latest concept to cause indigestion is location signing.

I will put together a list of what I think all the requirements are that
have been raised - including the NENA ones and others subsequently
mentioned and try to get it out in a succinct form this week.

Cheers,
Martin

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Sunday, 11 March 2007 6:47 AM
To: GEOPRIV
Subject: [Geopriv] NENA Requirements

4 Requirements

As defined in the TRD, and as excerpted here, the terms "shall", "must
",

Recommendations are identified by the word "should." Optional,
desirable capabilities are identified by the words "desirable" or
"preferably".

DA1 - The access network shall provide a mechanism for determination
and acquisition of location information, and support queries for
location.

DA2 - The location estimate used shall be that associated with the
physically (wire, fiber, air) connected network.

DA3 - Location may be requested at any time. Location information must
be associated with the device at the time the location is requested.

DA4 - Location acquisition should be provided by a consistent method
across all network configurations.

DA5 - Location determination and acquisition mechanisms must be
applicable to emergency calling, and may also be applicable to a wide
range of value-added location-based services.

DA6 - Location determination and acquisition techniques shall support
both NENA i2 and i3 network architectures.

DA7 (Location 1400-0100 from LTD WG i3 rqmts) - When measurement

DA8 - Location determination and acquisition must provide minimal
impact to call setup time in the event that location is not known ahead
of time.

DA9 - Where a device is not location aware the IP Access network should
have the ability to provide a location estimate on behalf of the
device.

DA10 - Location acquisition methods should not require modification of
hardware/firmware in home-routers/modems.

DA11 - A location determination method must exist that does not require
network hardware replacement.

Rep1 - Location information may be provided as location-by-value or
location-by-reference and the form is subject to the nature of the
request.

Rep2 - Location determination and acquisition mechanisms must support
all location information fields defined within a PIDF-LO.

Rep3 - Location acquisition mechanisms must allow for easy backwards
compatibility as the representation of location information evolves.

Rep4 - All representations of location shall include the ability to
carry altitude and/or floor designation. This requirement does not
imply altitude and/or floor designation is always used or supplied.

LocSec1 - Location information shall only be provided to authenticated
and authorized network devices. The degree of authentication and
authorization required may vary depending on the network.

LocSec2 - Location determination and acquisition methods should
preserve privacy of location information, subject to local laws and
regulations.

LocSec3 - The location or location estimate of a caller should be
dependable.

LocSec4 - The location acquisition protocol must support authentication
of the Location Information Server, integrity protection of the
Location Information, and protection against replay.

LocSec5 - The location source shall be identified and should be
authenticated. This includes manually entered location1.

LocSec6 - Where a location is acquired and cached prior to an emergency
call, it should be refreshed at regular intervals to ensure that it is
as current as possible, in the event location information cannot be
obtained in real time.

LocSec7 - Where location by-reference is used the appropriate privacy
policies must be implemented and enforced by the LIS operator.

---

From: "Dawson, Martin" <[email-masked]>
Date: Sat, 10 Mar 2007 21:54:49 -0600

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Sunday, 11 March 2007 7:32 AM
To: GEOPRIV
Subject: Re: [Geopriv] NENA Requirements

Hi all,

",

[[MCD]] That would be incorrect. The people who need to implement and
use this desire that they can prescribe a response time and the systems
provide *the best accuracy they can within the prescribed response
time*. I don't know if you're saying that the request should include a
guideline for preferred granularity or whether you are saying that
response should just indicate uncertainty. The latter is orthogonal and,
yes, it should return an indication of uncertainty. These considerations
are all especially pertinent to mobile wireless access. 

[[MCD]] No, it's really a generic requirement. A device asking for its
own location on the access network covered by the LIS may be implicitly
authorized, an OBO request for that same device may require a different
level of authorization and, as you say, it may also apply to the
dereferencing request applied for that target. The applicable degree of
authorization for each scenario may be domain-specific. 

[[MCD]] I am sure that this has been described numerous times already.
It's what we have been talking about viz location signing. It covers the
characteristics that the location information:

* Can be attributed to a recognized source
* Has not been tampered with since generated at that source
* Is applicable to a specific target identity
* Is applicable at a particular point in time

I wonder how this would look like.
[[MCD]] How what would look like? As discussed, the proposal is to
include certificate mechanisms to make the source of the location
information explicit. For location entered into a device, the assertion
mechanism may be used to have the LIS do this. More prosaically, and
consistent with the current FCC requirement that VoIP providers allow
their subscribers to enter their current location via a service provider
web page or equivalent, the location proffered on the call may similarly
identify the source of the location information. This is not actually a
LIS protocol requirement but I'm sure it was what was on a lot of
people's minds when the requirement was being discussed - you know what
committees are like.

This is not a security requirement.
[[MCD]] Yes, it's not very well categorized - can't argue with that.
Generally speaking, it's a function of LIS implementation as well and
tends to be independent of the acquisition protocol used - though not
completely.

What does this mean in context of requirement LocSec2 ?
[[MCD]] The device requesting the reference can provide its privacy
policies and LIS must honour them. LocSec2 acknowledges that certain
some jurisdictions may need to override these (e.g. location for
emergency services).

Ciao
Hannes

---

From: "Marc Linsner" <[email-masked]>
Date: Mon, 12 Mar 2007 11:49:47 -0400

Martin,

> 
> I think all of the NENA requirements have been raised and 
> discussed - the latest concept to cause indigestion is 
> location signing.

You have requirements mixed up with solutions.  Signing location objects is
a solution.  I believe Ted nailed the requirement.

-Marc-

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 12 Mar 2007 18:44:22 -0500

I have re-read Ted's email now several times, and it seems to
concentrate on being able to detect and potentially thwart denial of
service attacks. While this is one of the potential problem it is not
the only one, and I don't see the kind of thing Ted is talking about as
addressing the same problems that signatures will address.

Further more I did not seem to me to provide a concrete way of doing
what Ted was suggesting. Precisely how will this be done?  Without these
details it seems like smoke and mirrors and may not end up being
possible at all. But I don't discount it as helping.

I don't see DoS as being the only source of attack, and certainly don't
see signatures as the solution to the DoS problem. I do see signatures
as providing a good way to potentially screen crank-calls and avoiding
unnecessary use of public resources. 

The 4 requirements I am tabling are below. 

1) The only calls that SHALL be directed to a PSAP are those calls that
have been made by end-devices that are in the PSAP service jurisdiction
at the time a call is made. 

2) Any location used by routing services or subsequent dispatch services
MUST unequivocally represent the physical position of the end-device at
the time the location is proffered.

3) Any request for location made to a LIS MUST result in either an
error, or the current location of the target device being returned.

4) The source of the location information MUST be identifiable and is
accountable for the accuracy of the information provided.

Providing you try to meet these 4 requirements I am happy. Simply saying
they can't be done and so they are not requirements, as has been said in
the past, is not acceptable.

Cheers
James

> From: Marc Linsner [mailto:[email-masked]]
> Sent: Tuesday, 13 March 2007 2:50 AM
> To: Dawson, Martin
> Cc: 'GEOPRIV'
> Subject: RE: [Geopriv] NENA Requirements
> 
> Martin,
> 
> >
> You have requirements mixed up with solutions.  Signing location
objects
> is

---

From: "Marc Linsner" <[email-masked]>
Date: Mon, 12 Mar 2007 20:40:07 -0400

James,

> 1) The only calls that SHALL be directed to a PSAP are those 
> calls that have been made by end-devices that are in the PSAP 
> service jurisdiction at the time a call is made. 
> 
> 2) Any location used by routing services or subsequent 
> dispatch services MUST unequivocally represent the physical 
> position of the end-device at the time the location is proffered.
> 
> 3) Any request for location made to a LIS MUST result in 
> either an error, or the current location of the target device 
> being returned.
> 
> 4) The source of the location information MUST be 
> identifiable and is accountable for the accuracy of the 
> information provided.

Could you please cite the NENA document(s) that state these 4 requirements.

Thanks,

-Marc-

---

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 12 Mar 2007 19:55:46 -0500

I'm not sure what the purpose of the post is. No, the NENA requirements
don't specify signing, but the related discussion has led to the
discussion of that concept...

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]] 
Sent: Tuesday, 13 March 2007 2:50 AM
To: Dawson, Martin
Cc: 'GEOPRIV'
Subject: RE: [Geopriv] NENA Requirements

Martin,

> discussed - the latest concept to cause indigestion is 

You have requirements mixed up with solutions.  Signing location objects
is
a solution.  I believe Ted nailed the requirement.

-Marc-

---

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 12 Mar 2007 19:57:02 -0500

I must have missed the part where he said these were specifically quoted
from NENA requirements. Have we flipped to this being the sole source?

Cheers,
Martin

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]] 
Sent: Tuesday, 13 March 2007 11:40 AM
To: Winterbottom, James
Cc: 'GEOPRIV'
Subject: RE: [Geopriv] NENA Requirements

James,

> identifiable and is accountable for the accuracy of the 

Could you please cite the NENA document(s) that state these 4
requirements.

Thanks,

-Marc-

---

From: Ted Hardie <[email-masked]>
Date: Mon, 12 Mar 2007 21:34:34 -0700

>at the time a call is made.

This goes contrary to everything we have discussed before, where the
theory has been that the call taker would try to take a call in any
circumstance, and these indicators would be used at most for ranking.

To link this to the "warnings" thread on Ecrit right now, we're saying
there that there will be cases where a server should return a default,
a stale answer, or similar, because it cannot parse the request, cannot
reach an upstream for the data, or cannot confirm its freshness.  It
returns *a valid PSAP*, even if the request had an unresolvable
address, because doing so may save lives.  Sure, that call should
have health warnings and may affect the queuing by call takers,
but saying you won't deliver the call because *you cannot confirm
at call time that the end device is  within the PSAP jurisdiction* will
kill someone.  I reject such a requirement utterly, and I hope the WG
agrees with me.  Route the call, and let the local policy at the PSAP decide
if you have to, but failing to route the call via system design is not okay.

>the time the location is proffered.

This is a strawman, or at least I hope it is.  A device that got its location on
boot, cannot update it because of network issues, and presents its position
to this system is behaving  according to the best-effort nature of
the underlying network.  While the phone system is waiting for me to present
an "unequivocal" location, your strawman is burning up in the car fire
I was calling to report.

>error, or the current location of the target device being returned.

And if the LIS has the location of the attachment point, but not the
target device, who resolves the problem?  The end node, by presenting
the attachment point to the LIS for location (nice targeting system,
good luck!)?  Or the LIS, which should return the likely service area of the
attachment point as a non-point response?  If the latter, we may have
something useful for identifying useful PSAPs, but it is not the target device's
location for lots of systems in which the service area is large (think:  WiMAX).

>accountable for the accuracy of the information provided.

The second is not an engineering requirement, and the first would be
satisfied by a self-report for cases like enterprise networks.  That
might well be useful for tracking ill-described locations and similar
post-facto analyses.  But you're sprinkling crypto dust on it in the
hopes of recreating a system where the underlying mechanism is
totally different.  With enough thrust the pig may fly, but it spoils
the bacon and irritates the pig.

				Ted

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 13 Mar 2007 00:55:06 -0500

It's actually quite inappropriate for the IETF to be stating what the
policies for emergency services in global jurisdictions needs to be.
James' rules below may, indeed, be a strawman but they represent one
possible set of rules that one possible jurisdiction may wish to adopt.

It is an act of hubris for the IETF to deprive jurisdictions of these
mechanisms because individuals who aren't actually the ones who are
going to be the stakeholders didn't think it could be handled properly.

NENA - who do represent a very broad cross-section of genuine
stakeholders - do consider that they have the chops to institute
something like VESA and make it work for them. I have the utmost
confidence that they will be able to make it work and that it will
contribute to the integrity, in a significant way, of the emergency
service. There's a tendency to be dismissive of their skills and
knowledge in these areas which I think is similarly patronising and
quite incorrect. They have more experience in making complex networks,
organizations, and processes work than most of the commentators on this
list. I say give them the tools they are asking for.

Things evolve. In the long term it may actually be considered
unacceptable for an access network to not provide a robust mechanism for
instantaneous location determination rather than "attachment time"
location. I suggest that it will always be possible to do this,
regardless of access technology, given the right approach. Ideally the
capabilities of networks won't be frozen in time and they will become
more sophisticated in this respect as time goes by.

On point 4 - you may argue that the "accountability" aspect is not an
engineering requirement. Perhaps not; it's a service requirement and it
creates the opportunity to provide an engineering solution. There is
very real value in being able to reliably associate the location with
the source so that errors in the system can be traced to that source and
corrected. Closing the loop in this way for continuous improvement is
part of the existing switched circuit telephony emergency service
processes and there's no less of an imperative for it for IP telephony.
Yet another of the uses of signed location is in providing this robust
link back to the source for this purpose; it's an engineering solution
that suggests itself.

Cheers,
Martin

-----Original Message-----
From: Ted Hardie [mailto:[email-masked]] 
Sent: Tuesday, 13 March 2007 3:35 PM
To: Winterbottom, James; Marc Linsner; Dawson, Martin
Cc: GEOPRIV
Subject: RE: [Geopriv] NENA Requirements

agrees with me.  Route the call, and let the local policy at the PSAP
decide
if you have to, but failing to route the call via system design is not
okay.

>the time the location is proffered.

This is a strawman, or at least I hope it is.  A device that got its
location on
boot, cannot update it because of network issues, and presents its
position
to this system is behaving  according to the best-effort nature of
the underlying network.  While the phone system is waiting for me to
present
an "unequivocal" location, your strawman is burning up in the car fire
I was calling to report.

And if the LIS has the location of the attachment point, but not the
target device, who resolves the problem?  The end node, by presenting
the attachment point to the LIS for location (nice targeting system,
good luck!)?  Or the LIS, which should return the likely service area of
the
attachment point as a non-point response?  If the latter, we may have
something useful for identifying useful PSAPs, but it is not the target
device's
location for lots of systems in which the service area is large (think:
WiMAX).

				Ted

---

From: Andrew Newton <[email-masked]>
Date: Tue, 13 Mar 2007 10:23:23 -0400

Martin,

It is actually quite appropriate for the IETF to determine the scope  
of its own work.  The IETF is not at the beck and call of other  
organizations, just as they are not at the beck and call of the  
IETF.  And we do have the right to question requirements, and it says  
a lot if those requirements cannot stand up to scrutiny.  And the  
IETF does have a right to apply its broad collective of knowledge and  
experience on networking to a specific topic area, regardless of how  
you feel about any individual's investment in the problem space.

With respect to NENA, it is rude of you to suggest that others on  
this list are not respectful towards it. I and several others on this  
list are agents of entities that have contributed non-trivial amounts  
of funds to NENA so that it may continue its mission.  NENA has a  
very important role to fill, one which the IETF cannot and will not  
take on.

-andy, co-chair of GEOPRIV

On Mar 13, 2007, at 1:55 AM, Dawson, Martin wrote:

>> --------------------------------------------------------------------- 
>> --
> -------------------------
>> --------------------------------------------------------------------- 
>> --
> -------------------------
>> [mf2]
>>
>>

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 13 Mar 2007 09:40:34 -0500

And is it more appropriate that NENA establish the policies governing how and when emergency calls are treated, where they are directed, when they are answered and what criteria should be used to exercise those policies - or is it more appropriate for the IETF to do that. I don't intend to be rude but I do feel the need to point out that the arguments being made against the proposal appear to be based on the assumption that NENA are not capable of understanding the implications of the technologies involved - and I think that is incorrect.
 
I don't think that any of the NENA requirements have failed to stand up to scrutiny - there are just some people who don't want to accept them. I think their views are mistaken but, in any case, why should we not define protocols with the capabilities that the domain experts have requested?
 
Cheers,
Martin

________________________________

From: Andrew Newton [mailto:[email-masked]]
Sent: Wed 3/14/2007 1:23 AM
To: Dawson, Martin
Cc: Ted Hardie; Winterbottom, James; Marc Linsner; GEOPRIV
Subject: Re: [Geopriv] NENA Requirements

Martin,

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 13 Mar 2007 10:42:40 -0400

Martin

As a very frequent contributor to NENA, and specifically, someone who
participated, albeit somewhat intermittently in the development of the
requirements which you are referring to, I feel that we should point out
that these specific requirements come primarily from me (in the case of
several of the security related requirements) and James Winterbottom,
although there are several other people who were involved.  Although I have
been working with NENA for several years now, I personally feel like I'm
still the nethead in an otherwise bellhead environment there.  We're telling
them how IP networks behave and how they need to deal with them.  They
certainly tell us a lot about how the current system works, and how they use
it.  I don't think however, in this case, that you can really assert it is
NENA that brought forth these requirements.  We did it, and we pushed them
through NENA.  There isn't anything necessarily wrong with that; I just
think you need to lay off some of the "NENA is the expert here" rhetoric.  I
don't even (personally) agree with some of them as written.  It is, however,
undeniably an approved NENA work product.

I also feel somewhat uncomfortable with James' attempt to rewrite the NENA
requirements.  I wouldn't agree with how he characterizes them.  I'm
actually more on Andy's side with regard to what these mechanisms we are
talking about are used for.  

I would say, however, that there is policy that guides how the mechanisms
are used.  It may well be in normal circumstances that calls with missing or
invalid security checks are processed as a normal call, but with some alert
to the call taker to be more careful.  However, if the PSAP was under direct
DoS attack, then it may be policy that calls with missing or invalid
security checks are put on a queue that is answered less promptly than calls
that have all the security mechanisms in place and working, or those calls
may be chosen to be diverted to another PSAP.  That might depend on the
attack signature (and the policy).

Brian

> Sent: Tuesday, March 13, 2007 10:23 AM
> To: Dawson, Martin
> Cc: Ted Hardie; GEOPRIV; Marc Linsner

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 13 Mar 2007 10:11:27 -0500

I agree with everything you said Brian - with the exception that I
didn't think James was attempting to rewrite the NENA requirements; I
certainly didn't infer that he was quoting them; perhaps because I'm
familiar enough with them that I can see the difference. At some point
in time, in some jurisdiction, the policies he tabled may quite credibly
become that strict.

NENA is NENA and there are plenty of people who are only comfortable
with their own domain but there are also plenty of people who are
comfortable with IP - that is my assessment - after all, it is an old
protocol suite and it's been used for plenty of systems in the emergency
infrastructure before it ever became a voice trunking protocol. I have
never liked the nethead/bellhead language because I think it gives wings
to prejudice and clouds judgement. What I am saying is that I believe
there is sufficient body of knowledge and expertise in NENA to assess
for themselves the validity, value, and practicality of having signed
location. I think you do too. Particular individuals certainly did do a
lion's share or the work in the migratory and location working groups in
NENA but nothing was documented that wasn't fully discussed, assessed,
and agreed by the wider group.

NENA are "the experts here" when it comes to requirements. People in
this working group are trying to say what emergency services policy
should be and I believe that belongs with NENA for the US and equivalent
entities for other jurisdictions.

What you suggest with respect to call treatment is also perfectly valid
and I have cited the same policy in previous posts as an example of
something realistic that the emergency jurisdiction may want to apply.
It's all perfectly sensible and reasonable.

This debate isn't just about building up or putting down NENA - I am
trying to ensure that the requirements of real end users don't get
quashed because somebody felt those end users weren't qualified to
articulate their real needs. It goes directly to what relevant outputs
this working group is going to define.

Cheers,
Martin 

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Wednesday, 14 March 2007 1:43 AM
To: 'Andrew Newton'; Dawson, Martin
Cc: 'Ted Hardie'; 'GEOPRIV'; 'Marc Linsner'
Subject: RE: [Geopriv] NENA Requirements

Martin

As a very frequent contributor to NENA, and specifically, someone who
participated, albeit somewhat intermittently in the development of the
requirements which you are referring to, I feel that we should point out
that these specific requirements come primarily from me (in the case of
several of the security related requirements) and James Winterbottom,
although there are several other people who were involved.  Although I
have
been working with NENA for several years now, I personally feel like I'm
still the nethead in an otherwise bellhead environment there.  We're
telling
them how IP networks behave and how they need to deal with them.  They
certainly tell us a lot about how the current system works, and how they
use
it.  I don't think however, in this case, that you can really assert it
is
NENA that brought forth these requirements.  We did it, and we pushed
them
through NENA.  There isn't anything necessarily wrong with that; I just
think you need to lay off some of the "NENA is the expert here"
rhetoric.  I
don't even (personally) agree with some of them as written.  It is,
however,
undeniably an approved NENA work product.

I also feel somewhat uncomfortable with James' attempt to rewrite the
NENA
requirements.  I wouldn't agree with how he characterizes them.  I'm
actually more on Andy's side with regard to what these mechanisms we are
talking about are used for.  

I would say, however, that there is policy that guides how the
mechanisms
are used.  It may well be in normal circumstances that calls with
missing or
invalid security checks are processed as a normal call, but with some
alert
to the call taker to be more careful.  However, if the PSAP was under
direct
DoS attack, then it may be policy that calls with missing or invalid
security checks are put on a queue that is answered less promptly than
calls
that have all the security mechanisms in place and working, or those
calls
may be chosen to be diverted to another PSAP.  That might depend on the
attack signature (and the policy).

Brian

> >> they can't be done and so they are not requirements, as has been
said
> > in
----------------------------------------------------------------------
> > --------------------------
----------------------------------------------------------------------
> > --------------------------
> > [mf2]
> >
> >

---

From: Andrew Newton <[email-masked]>
Date: Tue, 13 Mar 2007 11:32:14 -0400

Martin,

I'm not sure what it is you are attempting to do, but to suggest that  
the IETF has no experts in the field of network security or Internet  
topology and cannot therefore apply that knowledge is quite simply  
wrong.

Location signing has been offered as a requirement.  It has been  
pointed out that location signing is a solution and not a  
requirement.  It has also been pointed out that the notion of network  
topology that is being applied to VoIP by this solution does not  
match the way the Internet works.

Also, it has been fair to question the actual use of location signing  
with respect to invalidly signed or unsigned location information.   
To date, nobody has offered an authoritative policy... it is all  
supposition.  It seems rather silly to claim to be the authoritative  
voice on this issue when you cannot give concrete policy examples.

-andy

---

From: Richard Barnes <[email-masked]>
Date: Tue, 13 Mar 2007 11:56:05 -0400

> Location signing has been offered as a requirement.  It has been pointed 
> out that location signing is a solution and not a requirement.  It has 
> also been pointed out that the notion of network topology that is being 
> applied to VoIP by this solution does not match the way the Internet works.

However, the security of voice services (emergency calling in 
particular) depends centrally on the trust relationships that are 
currently encoded in the topology of the PSTN.  These trust 
relationships are what need to persist through the transition to an 
IP-based infrastructure.  Public-key cryptography is how trust 
relationships are codified and communicated in the modern Internet 
community.  From the little I know about it, NENA's VESA effort seems 
like a good example of this translation.

--Richard

> with respect to invalidly signed or unsigned location information.  To 
> date, nobody has offered an authoritative policy... it is all 
> ------------------------------------------------------------------------
>

---

From: "Marc Linsner" <[email-masked]>
Date: Tue, 13 Mar 2007 12:08:09 -0400

Martin,

I think the disconnect lies between the understanding of IP and the
understanding of the Internet.

NENA's knowledge/experience is with 'closed' single purpose systems, the
Internet is an 'open' general use system.  Closed single purpose will always
perform the designed-for task better than a general purpose system.  So,
while lots of people clamor to additional attributes that IP can/will
deliver to a PSAP, most within NENA don't understand the Internet
architecture (note: IP knowledge does not equal Internet knowledge).  The
IETF can/will fill that knowledge void wrt how the Internet works.

IMO, as a long-time NENA member and limited participant/casual observer of
happenings inside NENA, several of the published NENA requirements were
reverse engineered from an understood solution.  Asking the IETF to
exonorate the NENA solution will not produce the desired outcome.  NENA MUST
convey their raw requirements (hopefully in an Internet context) in order to
foster a desire to solve their problems.  A great deal of frustration is
derived attempting to wade through the reverse engineered requirements to
try and understand the real underlying requirement.  And it is fact that not
every requirement has an Internet solution (or spam would cease to exist).

One large point that NENA has failed to admit in the Internet context is
they will not control what is launched at them on the Internet from afar.
This is not something they are used to in their current environment.

I have hope that we'll get there....but I sense more pain in the future.

-Marc-

> From: Dawson, Martin [mailto:[email-masked]] 
> Sent: Tuesday, March 13, 2007 11:11 AM
> To: Brian Rosen; Andrew Newton
> I agree with everything you said Brian - with the exception 
> that I didn't think James was attempting to rewrite the NENA 
> requirements; I certainly didn't infer that he was quoting 
> them; perhaps because I'm familiar enough with them that I 
> can see the difference. At some point in time, in some 
> jurisdiction, the policies he tabled may quite credibly 
> become that strict.
> 
> NENA is NENA and there are plenty of people who are only 
> comfortable with their own domain but there are also plenty 
> of people who are comfortable with IP - that is my assessment 
> - after all, it is an old protocol suite and it's been used 
> for plenty of systems in the emergency infrastructure before 
> it ever became a voice trunking protocol. I have never liked 
> the nethead/bellhead language because I think it gives wings 
> to prejudice and clouds judgement. What I am saying is that I 
> believe there is sufficient body of knowledge and expertise 
> in NENA to assess for themselves the validity, value, and 
> practicality of having signed location. I think you do too. 
> Particular individuals certainly did do a lion's share or the 
> work in the migratory and location working groups in NENA but 
> nothing was documented that wasn't fully discussed, assessed, 
> NENA are "the experts here" when it comes to requirements. 
> People in this working group are trying to say what emergency 
> services policy should be and I believe that belongs with 
> NENA for the US and equivalent entities for other jurisdictions.
> 
> What you suggest with respect to call treatment is also 
> perfectly valid and I have cited the same policy in previous 
> posts as an example of something realistic that the emergency 
> jurisdiction may want to apply.
> This debate isn't just about building up or putting down NENA 
> - I am trying to ensure that the requirements of real end 
> users don't get quashed because somebody felt those end users 
> weren't qualified to articulate their real needs. It goes 
> directly to what relevant outputs this working group is going 
> to define.
> 
> Cheers,
> Martin 
> 
> As a very frequent contributor to NENA, and specifically, 
> someone who participated, albeit somewhat intermittently in 
> the development of the requirements which you are referring 
> to, I feel that we should point out that these specific 
> requirements come primarily from me (in the case of several 
> of the security related requirements) and James Winterbottom, 
> although there are several other people who were involved.  
> Although I have been working with NENA for several years now, 
> I personally feel like I'm still the nethead in an otherwise 
> bellhead environment there.  We're telling them how IP 
> networks behave and how they need to deal with them.  They 
> certainly tell us a lot about how the current system works, 
> and how they use it.  I don't think however, in this case, 
> that you can really assert it is NENA that brought forth 
> these requirements.  We did it, and we pushed them through 
> NENA.  There isn't anything necessarily wrong with that; I 
> just think you need to lay off some of the "NENA is the expert here"
> rhetoric.  I
> don't even (personally) agree with some of them as written.  
> It is, however, undeniably an approved NENA work product.
> 
> I also feel somewhat uncomfortable with James' attempt to 
> rewrite the NENA requirements.  I wouldn't agree with how he 
> characterizes them.  I'm actually more on Andy's side with 
> regard to what these mechanisms we are talking about are used for.  
> 
> I would say, however, that there is policy that guides how 
> the mechanisms are used.  It may well be in normal 
> circumstances that calls with missing or invalid security 
> checks are processed as a normal call, but with some alert to 
> the call taker to be more careful.  However, if the PSAP was 
> under direct DoS attack, then it may be policy that calls 
> with missing or invalid security checks are put on a queue 
> that is answered less promptly than calls that have all the 
> security mechanisms in place and working, or those calls may 
> be chosen to be diverted to another PSAP.  That might depend 
> on the attack signature (and the policy).
> 
> Brian
> 
> > organizations, just as they are not at the beck and call of 
> the IETF.  
> > And we do have the right to question requirements, and it 
> says a lot 
> > if those requirements cannot stand up to scrutiny.  And the 
> IETF does 
> > have a right to apply its broad collective of knowledge and 
> experience 
> > on networking to a specific topic area, regardless of how you feel 
> > about any individual's investment in the problem space.
> > 
> > With respect to NENA, it is rude of you to suggest that 
> others on this 
> > list are not respectful towards it. I and several others on 
> this list 
> > are agents of entities that have contributed non-trivial amounts of 
> > funds to NENA so that it may continue its mission.  NENA has a very 
> > important role to fill, one which the IETF cannot and will not take 
> > on.
> > 
> > > organizations, and processes work than most of the 
> commentators on 
> > > this list. I say give them the tools they are asking for.
> > >
> > > unacceptable for an access network to not provide a 
> robust mechanism 
> > > for instantaneous location determination rather than "attachment 
> > > time"
> > > engineering requirement. Perhaps not; it's a service 
> requirement and 
> > > it creates the opportunity to provide an engineering 
> solution. There 
> > > is very real value in being able to reliably associate 
> the location
> with
> > > the source so that errors in the system can be traced to 
> that source 
> > > and corrected. Closing the loop in this way for continuous 
> > > improvement
> is
> > >> 1) The only calls that SHALL be directed to a PSAP are 
> those calls 
> > >> that have been made by end-devices that are in the PSAP service 
> > >> jurisdiction at the time a call is made.
> > >>
> > >
> > > a stale answer, or similar, because it cannot parse the request, 
> > > cannot reach an upstream for the data, or cannot confirm its 
> > > freshness.  It returns *a valid PSAP*, even if the request had an 
> > > unresolvable address, because doing so may save lives.  
> Sure, that 
> > > call should have health warnings and may affect the 
> queuing by call 
> > > takers, but saying you won't deliver the call because *you cannot 
> > > confirm at call time that the end device is  within the PSAP 
> > > jurisdiction* will kill someone.  I reject such a requirement 
> > > utterly, and I hope the
> WG
> > >> MUST unequivocally represent the physical position of the end- 
> > >> device at the time the location is proffered.
> > >>
> > >
> either an
> identifiable and

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 13 Mar 2007 20:44:21 +0100

Hi Martin,

> grips with beginning to accept the idea of an "L7" protocol.

NENA is slower than the IETF. Interesting :-)
In that case it could have even been easier to share the requirements a 
long time ago instead of letting an entire group discuss requirements 
for a long time.
> as one commentator put it).

I am sure it would have been possible to share a copy-and-paste version 
of the requirements as written in the document.

I also recall my statement regarding the broken architecture. That was 
targeting the way how authorization was supposed to work with location 
retrieval creating artificial relationships between every VoIP provider 
and every access network provider: What a deployment nightmare!

>  It's impossible to discuss requirements
> proposals on that basis.

I hope you understand that not everybody immediately shares your 
excitement with every proposal. This is quite common in standardization.

>  Thank you for not smoking anyone? As I recall,
Obviously not all of the requirements have been brought forward since 
some of them have been raised during the WGLC of the problem statement 
and the requirements document. Location signing is indeed still difficult.

> mentioned and try to get it out in a succinct form this week.
We just need to make sure that all the requirements are in the 
requirements document before we forward the document to the IESG. 
Doesn't that sound reasonable to you as well?

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 13 Mar 2007 20:44:42 +0100

Hi Martin,

> authorization for each scenario may be domain-specific. 
That's quite misleading. What type of authorization is "implicit 
authorization"?

I fear that if authorization is "domain specific" then emergency 
services might just not work.

> * Is applicable at a particular point in time
Wouldn't it be better to list these requirements instead of 
"dependability"?

>> LocSec4 - The location acquisition protocol must support
>>     
> authentication
>   
> [[MCD]] How what would look like
>  As discussed, the proposal is to
> mechanism may be used to have the LIS do this.
Does not make sense to me.

>  More prosaically, and
> consistent with the current FCC requirement

Which FCC requirement do you exactly refer to?

>  that VoIP providers allow
> identify the source of the location information.

Would a signature cover the location? Would the signature point to the 
user or to the VoIP provider?

What happens if I enter my location at my VoIP client that I use in my 
home network? Who would certify what?

>  This is not actually a

I think that the requirements need more text in order to be understood.

"The location source should be authenticated." could also mean that you 
have to authenticate the LIS as part of the LCP exchange.

>   
>> LocSec6 - Where a location is acquired and cached prior to an
>>     
> emergency
>   
> policies and LIS must honour them.

This sounds  a little bit like a requirement tailored to a solution.

>  LocSec2 acknowledges that certain

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 13 Mar 2007 20:46:13 +0100

Hi all,

since this discussion is ongoing for some time now I would like to 
better understand the relationship between location signaling and 
location-by-reference.
Let me make another strawman proposal:

* We don't do Location Signing at all.
* Access networks distribute location information to the end host at a 
granularity that allows location based routing (unsigned). For most 
countries this is in fact trivial.
* Access networks additionally provide a location-by-reference to the 
end host (if necessary and if they can do so)
This reference is resolved by the PSAP for detailed location information 
retrieval. The PSAP can therefore also authenticate the LIS and has the 
information about the access network.

As Henning pointed out there is some value in authenticating the 
emergency caller (directly or indirectly). Why did nobody investigate it 
since it also allows to get hold of the adversary? It might not look so 
nice from crypto point of view but it would provide a lot of help.

Ciao
Hannes

PS: I also believe that the PSAP operator would accept calls that don't 
have any location attached to it. How many calls today have location 
information available? Do we have some statistics about it?

---

From: "Stark, Barbara" <[email-masked]>
Date: Tue, 13 Mar 2007 16:06:04 -0400

Hannes,
I sympathize with your frustration, but I think that part of the
requirement sharing problem may lie with IETF processes. I know for a
fact that the draft NENA TID was liaised to the DSL Forum in June 2006,
and the final version was liaised in December 2006. I know there was
discussion around liaising to the IETF, and I'm not knowledgeable enough
to comprehend why the NENA liaison didn't make it to the geopriv WG.
Clearly, it was NENA's intention to try to share the draft and get
comments on it. June 2006 would also have given the LCP task force time
to consider those requirements.

I don't think there's anything to be done about the past, but for the
future, would it be possible to define a liaison process so
organizations such as NENA can properly share their drafts with IETF
WGs? 
Barbara 

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Tuesday, March 13, 2007 3:44 PM
<snip>
NENA is slower than the IETF. Interesting :-) In that case it could have
even been easier to share the requirements a long time ago instead of
letting an entire group discuss requirements for a long time.
<snip>

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA624

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 13 Mar 2007 15:51:23 -0500

Hi Hannes,

> countries this is in fact trivial.

[AJW] My discussions with carriers and infrastructure providers seems to
suggest that obtaining location information to provide to end hosts is
going to be far from trivial. When confronted with this hurdle I am not
so sure that adding signing is that much more work.

> information about the access network.

[AJW] It is not clear to me how I can use this approach to provide an
answering or priority policy for the PSAP. Do however agree that a
re-query mechanism as you suggest is useful where the PSAP wants
up-to-date or more accurate location information.

> nice from crypto point of view but it would provide a lot of help.

[AJW] It is not clear to me how authenticating millions of users and
their multitude of identity mechanisms is any less daunting than
providing accreditation to potentially thousands of access network
providers. But perhaps I am missing the point. That said, if you couple
this with signed location then you have the whole gamut. See location
dependability draft
http://tools.ietf.org/html/draft-thomson-geopriv-location-dependability-
00
 
> information available? Do we have some statistics about it?

[AJW] All emergency calls in the world have some degree of location
provided (inferred), though in some cases this may not be fantastically
accurate, country level. In the United States for wireline it is based
on the calling line ID, and either an ESRD (roughly representing a cell)
or an ESRK (representing a rough calling area) for wireless.

Perhaps, like some other working groups we need to make the distinction
between support and implement. I am asking that the requirements include
support for it, I think that implementation will be something that
jurisdictions have the option to do or not.

Cheers
James

> > they can't be done and so they are not requirements, as has been
said in
> ------------------------
> ------------------------

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 13 Mar 2007 16:52:19 -0400

Why couldn't the NENA chair simply send an email with a publicly  
accessible URL to the GEOPRIV or ECRIT working groups? I don't think  
we need a full-time standardization diplomatic corps.

---

From: "Marc Linsner" <[email-masked]>
Date: Tue, 13 Mar 2007 16:58:13 -0400

Barbara,

Yes, the IETF liaison process is frustrating.  But I attribute this partly
to my own laziness/lack of desire to learn it.  I did attempt to track the
NENA document, at your earlier suggestion/request, starting at the NENA end
since that seemed less intimidating than the IETF end.  Unfortunately, I got
a resounding 'no response' on my query on the NENA end which drove me to
drop it as I see the IETF end as the bigger of the two dragons.  I didn't
get results from the little dragon, chances are the bigger one will be even
less helpful.

In defense of the IETF, NENA certainly knows how to submit/track a draft,
which is the proven mechanism in the case of LoST and the NENA LTD wg.

-Marc-

> From: Stark, Barbara [mailto:[email-masked]] 
> Sent: Tuesday, March 13, 2007 4:06 PM
> To: Hannes Tschofenig; Dawson, Martin
> Cc: GEOPRIV
> I sympathize with your frustration, but I think that part of 
> the requirement sharing problem may lie with IETF processes. 
> I know for a fact that the draft NENA TID was liaised to the 
> DSL Forum in June 2006, and the final version was liaised in 
> December 2006. I know there was discussion around liaising to 
> the IETF, and I'm not knowledgeable enough to comprehend why 
> the NENA liaison didn't make it to the geopriv WG.
> Clearly, it was NENA's intention to try to share the draft 
> and get comments on it. June 2006 would also have given the 
> LCP task force time to consider those requirements.
> 
> I don't think there's anything to be done about the past, but 
> for the future, would it be possible to define a liaison 
> process so organizations such as NENA can properly share 
> their drafts with IETF WGs? 
> Barbara 
> 
> NENA is slower than the IETF. Interesting :-) In that case it 
> could have even been easier to share the requirements a long 
> time ago instead of letting an entire group discuss 
> requirements for a long time.
> <snip>
> 
> *****
> 
> The information transmitted is intended only for the person 
> or entity to which it is addressed and may contain 
> confidential, proprietary, and/or privileged material. Any 
> review, retransmission, dissemination or other use of, or 
> taking of any action in reliance upon this information by 
> persons or entities other than the intended recipient is 
> prohibited. If you received this in error, please contact the 
> sender and delete the material from all computers. GA624
> 
> 
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 13 Mar 2007 17:17:18 -0400

> so sure that adding signing is that much more work.

I agree with Hannes that location granularity matters. Having a  
single LO for the whole DSLAM (or DHCP server) that says "XYZ County"  
is a whole lot easier than tracking the wiring panel changes as lines  
get moved.

Signing is not the big deal - getting valid CA-certified signatures  
is. We all know how many web servers have bogus, expired or self- 
signed certificates, and not just Joe's Barber Shop and Delicatessen.

Take a large campus with thousands of offices. Unless you have a  
fairly elaborate delegation mechanism, somebody externally will have  
to sign for each and every room. This means that the organization has  
to operate a CA that is trusted by the proposed VESA entity, for  
example. We can't even get delegation to work within Internet2 and  
Columbia.

> their multitude of identity mechanisms is any less daunting than

We have such a mechanism, e.g., within IMS, namely P-Asserted-ID,  
which is very widely deployed, from what I can tell. Or the SIP  
identity mechanism, although that seems to just start getting  
traction. The PSAP wouldn't care whether and how the VSP verified the  
customer identity; it just gets a single client cert from the VSP in  
a TLS connection.

You probably missed the discussion on this years ago, but your  
concern and the perceived difficulties of a global PKI motivated the  
current mechanism, as it only requires what customers must have  
already, namely a shared secret with their VSP, and web-style cross- 
provider trust with a single cert  for each provider.

> jurisdictions have the option to do or not.

This doesn't quite work, given that phones need to work universally.  
I don't want to buy a phone in Prague, say, that suddenly can't make  
an emergency call in New York city.

Henning

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 13 Mar 2007 16:21:51 -0500

It's hard for me to believe we can MUST strength any signing - 
because of the difference in being idealistic and pragmatic about 
service delivery.  While reviewing the migratory nature of change 
from the existing systems to an IP based on.  There are a lot of IP 
devices out there right now that can make IP calls to a PSAP, if that 
PSAP were IP enabled. MUSTing their upgrade in SW is gonna be a hard 
sell to some/most (everyone?).  So do we want to be relevant or not 
implemented because we set our own bar too high?

I don't think any of us want bad guys to clog up the systems, yet we 
need to support unregistered emergency callers.  Presumably some 
(all?) of the unregistered emergency caller attempts wouldn't pass 
any authentication challenge.  So what happens then, the unregistered 
caller gets denied when calling a PSAP?  This is close to us making a 
legal decision (i.e. defining how jurisdictions interpret wrt whether 
or not to allow certain calls).  That's out of scope from my pov.

At 02:46 PM 3/13/2007, Hannes Tschofenig wrote:
>* Access networks distribute location information to the end host at 
>a granularity that allows location based routing (unsigned). For 
>most countries this is in fact trivial.
>* Access networks additionally provide a location-by-reference to 
>the end host (if necessary and if they can do so)
>This reference is resolved by the PSAP for detailed location 
>information retrieval. The PSAP can therefore also authenticate the 
>LIS and has the information about the access network.
>
>emergency caller (directly or indirectly). Why did nobody 
>investigate it since it also allows to get hold of the adversary? It 
>might not look so nice from crypto point of view but it would 
>provide a lot of help.
>
>
>Ciao
>Hannes
>
>PS: I also believe that the PSAP operator would accept calls that 
>don't have any location attached to it. How many calls today have 
>location information available? Do we have some statistics about it?
>
>

---

From: Richard Barnes <[email-masked]>
Date: Tue, 13 Mar 2007 17:25:18 -0400

> Take a large campus with thousands of offices. Unless you have a fairly 
> elaborate delegation mechanism, somebody externally will have to sign 
> for each and every room. This means that the organization has to operate 
> a CA that is trusted by the proposed VESA entity, for example. We can't 
> even get delegation to work within Internet2 and Columbia.

Location granularity and certification granularity are two orthogonal 
issues.  If there's one server that knows the geography of the whole 
Columbia campus, then there's only one certificate to manage.  If you 
have one per building, then you have might a few more, or you might have 
each server reach back to a central signing server for a signature.

--RB

> We have such a mechanism, e.g., within IMS, namely P-Asserted-ID, which 
> is very widely deployed, from what I can tell. Or the SIP identity 
> mechanism, although that seems to just start getting traction. The PSAP 
> wouldn't care whether and how the VSP verified the customer identity; it 
> just gets a single client cert from the VSP in a TLS connection.
> 
> You probably missed the discussion on this years ago, but your concern 
> and the perceived difficulties of a global PKI motivated the current 
> mechanism, as it only requires what customers must have already, namely 
> a shared secret with their VSP, and web-style cross-provider trust with 
> a single cert  for each provider.
> 
> 
>> don't
> This doesn't quite work, given that phones need to work universally. I 
> don't want to buy a phone in Prague, say, that suddenly can't make an 
> emergency call in New York city.
> 
> Henning
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 13 Mar 2007 22:40:23 +0100

Hi James,

> so sure that adding signing is that much more work.
If operators don't want to make location information available to the 
end host then location signing is not helpful for them either.
I also know that the same operators want to stick with the IMS approach 
where they neither need the LCP nor the location signing approach.

> information
>> retrieval. The PSAP can therefore also authenticate the LIS and has
>>     
> the
>   
> answering or priority policy for the PSAP.

I don't know what the last part of the sentence means.
>  Do however agree that a
What is the re-query in this context?

The PSAP fetches the location for the first time (given that only coarse 
grained  location information is available for routing). Nothing else is 
needed. That's already far more than they have today. ;

>> emergency caller (directly or indirectly). Why did nobody investigate
>>     
> it
>   
>> since it also allows to get hold of the adversary? It might not look
>>     
> so
>   
I agree it is useful to provided authenticated emergency calls in all 
cases.
Mechanisms like P-Asserted-ID or SIP Identity will be useful in many 
other cases, not just for emergency service calls. Being able to trace a 
caller back to its real identity is really, really helpful. Location 
signing cannot provide you with this functionality.

> accurate, country level.

I don't think that this is true. I have heard from cases where the 
location information is only retrieved when absolutely needed.

>  In the United States for wireline it is based

Ciao
Hannes

>>> service attacks. While this is one of the potential problem it is
>>>       
> not
>   
>>> the only one, and I don't see the kind of thing Ted is talking about
>>>       
> as
>   
>>> what Ted was suggesting. Precisely how will this be done?  Without
>>>       
> these
>   
>>> I don't see DoS as being the only source of attack, and certainly
>>>       
> don't
>   
>>> see signatures as the solution to the DoS problem. I do see
>>>       
> signatures
>   
>>> as providing a good way to potentially screen crank-calls and
>>>       
> avoiding
>   
>>> 1) The only calls that SHALL be directed to a PSAP are those calls
>>>       
> that
>   
>>> have been made by end-devices that are in the PSAP service
>>>       
> jurisdiction
>   
>>> 2) Any location used by routing services or subsequent dispatch
>>>       
> services
>   
>>> MUST unequivocally represent the physical position of the end-device
>>>       
> at
>   
>>> 4) The source of the location information MUST be identifiable and
>>>       
> is
>   
>>> Providing you try to meet these 4 requirements I am happy. Simply
>>>       
> saying
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 13 Mar 2007 22:43:04 +0100

I cannot agree more. We don't need complicated liaison processes if a 
number of people participate in both groups and are familiar with the work.
Unless the requirements were extremely confidential it would have 
trivial to share them with GEOPRIV.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 13 Mar 2007 22:53:42 +0100

We mentioned the idea of putting two PIDF-LOs into a SIP signaling 
message, namely one for routing and another one for consumption at the PSAP.
The one for routing does not need to provide a perfect precision, as we 
know. For some countries it would be sufficient to use state granularity 
to hit the correct PSAP.

I am also addressing those people who argue that "Operators will never 
provide location information to the end host because they want to make 
money with location-based applications. Hence, they can only use 
location-by-reference".

I don't want to create relationships between every VoIP provider and 
every access network provider in the world because I believe that this 
will do a lot of harm to the Internet. I am OK with a relationship 
between access network provider and PSAPs even though I see a lot of 
problems there as well.

If we have to use a location-by-reference mechanism for these operators 
then we don't need location signing.

I doubt that signed location information can be demanded for all 
emergency service calls since we will even see calls with absolutely no 
location information at all. Furthermore, we would have to tell the IEEE 
to go home since none of their solution does any sort of signing.

Ciao
Hannes

Richard Barnes wrote:
> have one per building, then you have might a few more, or you might 
> have each server reach back to a central signing server for a signature.
>
> --RB
>
>>
>>
>>
>>
>>>
>> already, namely a shared secret with their VSP, and web-style 
>> cross-provider trust with a single cert  for each provider.
>>
>>

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 13 Mar 2007 17:14:56 -0500

This is very well stated and I completely agree with you Richard.

> From: Richard Barnes [mailto:[email-masked]]
> Sent: Wednesday, 14 March 2007 2:56 AM
> To: Andrew Newton
> Cc: Ted Hardie; Dawson, Martin; Marc Linsner; GEOPRIV
pointed
> > with respect to invalidly signed or unsigned location information.
To

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 13 Mar 2007 17:26:14 -0500

Let me put a very real case out there, and see if it can be overcome
just using location by reference and no signing.

I have two entities that are required to provide my access network. And
ISP and a region access network provider (RANP). The ISP cannot
determine location, yet any location reference will point to him, in LIS
terms it is a gateway LIS. The ISP must get location from the RANP. When
location is requested from the ISP by a reference, the ISP presents its
own certificate to the LR, yet it is not the ultimate source of the
location information. How does a certificate from the ISP link back to
location being provided by the RANP in this case?

I guess I don't see a certificate used to establish a TLS session with a
LIS as being the necessarily of the same stock as a certificate used to
sign a location. But maybe it is just me.

> Sent: Wednesday, 14 March 2007 8:54 AM
> To: Richard Barnes
> Cc: GEOPRIV; Dawson, Martin; Marc Linsner; Henning Schulzrinne
> Subject: Re: [Geopriv] RE: Strawman Proposal
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 13 Mar 2007 17:28:45 -0500

> location information is only retrieved when absolutely needed.

[AJW] If you don't even have country level (inferred by something), then
you can't route the call at all. So while location may not be displayed
to the operator, the operator can be pretty sure that you are in the
same country, and in some places the inferred granularity is much
greater.
------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 13 Mar 2007 17:55:20 -0500

The discourse has been rife with concrete policy examples - and Brian
just added his version two posts ago.

The arguments against location signing have been "Certificate management
is too complicated - people won't succeed" and "PSAPs answer all the
calls anyway so there's no point".

In the case of the former, I accept NENA's word for it that they
understand the problem space and can make a successful judgement with
respect to succeeding. The membership consists of everyone from the
carrier space through to the PSAPs. The constant repetition of the
second point only emphasises that people don't understand how the
credentials can be used.

The requirements have been spelt out - and location signing has been
proffered as the solution. The nay-sayers position is that the
requirement should be discounted - they should offer a superior solution
if they have one.

I have never said that the IETF has no experts in the identified fields
- have I?

Cheers,

Martin

From: Andrew Newton [mailto:[email-masked]] 
Sent: Wednesday, 14 March 2007 2:32 AM
To: Dawson, Martin
Cc: Brian Rosen; Ted Hardie; GEOPRIV; Marc Linsner
Subject: Re: [Geopriv] NENA Requirements

Martin,

Location signing has been offered as a requirement.  It has been pointed
out that location signing is a solution and not a requirement.  It has
also been pointed out that the notion of network topology that is being
applied to VoIP by this solution does not match the way the Internet
works.

-andy

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 13 Mar 2007 18:33:21 -0500

Yes, I understand what you're saying - I just think it is wrong. I think
the requirements really are borne of genuine operational and application
domain specific requirements - not from a mindless attempt to retro-fit
convention from switched circuit to Internet.

Cheers,
Martin

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]] 
Sent: Wednesday, 14 March 2007 3:08 AM
To: Dawson, Martin
Cc: 'GEOPRIV'
Subject: RE: [Geopriv] NENA Requirements

Martin,

NENA's knowledge/experience is with 'closed' single purpose systems, the
Internet is an 'open' general use system.  Closed single purpose will
always
perform the designed-for task better than a general purpose system.  So,
while lots of people clamor to additional attributes that IP can/will
deliver to a PSAP, most within NENA don't understand the Internet
architecture (note: IP knowledge does not equal Internet knowledge).
The
IETF can/will fill that knowledge void wrt how the Internet works.

IMO, as a long-time NENA member and limited participant/casual observer
of
happenings inside NENA, several of the published NENA requirements were
reverse engineered from an understood solution.  Asking the IETF to
exonorate the NENA solution will not produce the desired outcome.  NENA
MUST
convey their raw requirements (hopefully in an Internet context) in
order to
foster a desire to solve their problems.  A great deal of frustration is
derived attempting to wade through the reverse engineered requirements
to
try and understand the real underlying requirement.  And it is fact that
not
every requirement has an Internet solution (or spam would cease to
exist).

One large point that NENA has failed to admit in the Internet context is
they will not control what is launched at them on the Internet from
afar.
This is not something they are used to in their current environment.

-Marc-

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 13 Mar 2007 18:29:39 -0500

The word "conflates" has been getting a good airing lately, so I'll give
it another shake.

The problem I have with this thread is that it is conflating the process
of subscriber identity and location.

One requirement that hasn't come out of NENA in this forum is that the
subscriber identity be delivered with some kind of strong credentials.
The reasons for this are at least twofold.

Firstly, the requirements were about location - so why would subscriber
identity turn up at all?

Secondly, one of the things that emergency services don't concern
themselves with in responding to callers is whether you really are the
individual they claim to be. Anonymous emergency calling via public
payphones, SIMless mobiles, and any other point a caller can lay their
hands on a device is an accepted feature of the service.

Cheers,
Martin

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Wednesday, 14 March 2007 8:17 AM
To: Winterbottom, James
Cc: Hannes Tschofenig; GEOPRIV; Dawson, Martin; Marc Linsner
Subject: Re: [Geopriv] RE: Strawman Proposal

Henning

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 13 Mar 2007 18:33:22 -0500

I don't think there's anything substantial to respond to below. Except
to go on the record and say that I wasn't actually attributing the
"broken architecture" comment to you Hannes. Now you've let another cat
out of the bag :)

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Wednesday, 14 March 2007 6:44 AM
To: Dawson, Martin
Cc: GEOPRIV
Subject: Re: [Geopriv] NENA Requirements

Hi Martin,

Obviously not all of the requirements have been brought forward since 
some of them have been raised during the WGLC of the problem statement 
and the requirements document. Location signing is indeed still
difficult.

Ciao
Hannes

authentication
emergency

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 13 Mar 2007 18:33:24 -0500

Yes - I think James P is also pointing out that the subscriber identity
is not the same as location information. Not trying to put words in your
mouth James, just indicating that the caller's identity isn't the thing
that the PSAP is really after. The fundamental point isn't about chasing
down "adversaries" as it is about ensuring the best emergency service is
available for those that actually need it.

Cheers,
Martin

-----Original Message-----
From: James M. Polk [mailto:[email-masked]] 
Sent: Wednesday, 14 March 2007 8:22 AM
To: Hannes Tschofenig
Cc: GEOPRIV
Subject: Re: [Geopriv] Strawman Proposal

as
these
don't
that
jurisdiction
services
at
saying

---

From: "Marc Linsner" <[email-masked]>
Date: Tue, 13 Mar 2007 19:36:58 -0400

James, Richard,

We are not moving to an IP-based infrastructure.  We are moving to the
Internet, where the are dragons and lots of scary things.

-Marc- 

> From: Winterbottom, James [mailto:[email-masked]] 
> Sent: Tuesday, March 13, 2007 6:15 PM
> To: Richard Barnes; Andrew Newton

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 13 Mar 2007 18:46:51 -0500

Comments inline.

Cheers,
Martin

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Wednesday, 14 March 2007 8:54 AM
To: Richard Barnes
Cc: Henning Schulzrinne; GEOPRIV; Dawson, Martin; Marc Linsner
Subject: Re: [Geopriv] RE: Strawman Proposal

We mentioned the idea of putting two PIDF-LOs into a SIP signaling 
message, namely one for routing and another one for consumption at the
PSAP.
The one for routing does not need to provide a perfect precision, as we 
know. For some countries it would be sufficient to use state granularity

to hit the correct PSAP.

[[MCD]] 
[[MCD]] Absolutely agree. It seems that IMS actually makes that
assumption - using the traditional "roaming partner" model that assumes
the voice service *is* the access service. It misses the major point of
using the Internet. Imagine being told you could only use your email or
Internet banking from "partner" access providers.

[[MCD]] 
[[MCD]] No, I disagree. Signed location - even obtained via reference -
should still have the characteristics identified by the requirements.
Imagine a dereferencing done to an ISP LIS, but the location-determiner
and signer is actually a DSL infrastructure operator. About the only
characteristic that could probably be ignored is the temporal component.
That is, since I'm only asking right now, I know that the location is
being provided right now.

to go home since none of their solution does any sort of signing.
[[MCD]] 
[[MCD]] I doubt that it can to - especially in the short term. I see
this as providing the tools that can begin to be applied now but which
will really come into their own over the next ten years as the PSTN
begins to drag its other foot into the grave.

Ciao
Hannes

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 13 Mar 2007 18:48:59 -0500

You must be getting the good stuff... :)

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]] 
Sent: Wednesday, 14 March 2007 10:37 AM
To: Winterbottom, James; 'Richard Barnes'
Cc: 'GEOPRIV'
Subject: RE: [Geopriv] NENA Requirements

James, Richard,

-Marc-

---

From: "Marc Linsner" <[email-masked]>
Date: Tue, 13 Mar 2007 20:02:59 -0400

Martin,

Since you obviously missed the inference, I'll explain.  It isn't the NENA
general population that I witnessed reverse engineering requirements from
their solution, it was YOU reverse engineering requirements from YOUR
solution.  This is something you have become proficient at as you forum
shop.

-Marc-

> Sent: Tuesday, March 13, 2007 7:33 PM
> To: Marc Linsner
> Cc: GEOPRIV
> Yes, I understand what you're saying - I just think it is 
> wrong. I think the requirements really are borne of genuine 
> operational and application domain specific requirements - 
> not from a mindless attempt to retro-fit convention from 
> switched circuit to Internet.
> 
> Cheers,
> Martin
> 
> I think the disconnect lies between the understanding of IP 
> and the understanding of the Internet.
> 
> NENA's knowledge/experience is with 'closed' single purpose 
> systems, the Internet is an 'open' general use system.  
> Closed single purpose will always perform the designed-for 
> task better than a general purpose system.  So, while lots of 
> people clamor to additional attributes that IP can/will 
> deliver to a PSAP, most within NENA don't understand the 
> Internet architecture (note: IP knowledge does not equal 
> Internet knowledge).
> The
> IMO, as a long-time NENA member and limited 
> participant/casual observer of happenings inside NENA, 
> several of the published NENA requirements were reverse 
> engineered from an understood solution.  Asking the IETF to 
> exonorate the NENA solution will not produce the desired 
> outcome.  NENA MUST convey their raw requirements (hopefully 
> in an Internet context) in order to foster a desire to solve 
> their problems.  A great deal of frustration is derived 
> attempting to wade through the reverse engineered 
> requirements to try and understand the real underlying 
> requirement.  And it is fact that not every requirement has 
> an Internet solution (or spam would cease to exist).
> 
> One large point that NENA has failed to admit in the Internet 
> context is they will not control what is launched at them on 
> the Internet from afar.
> > in time, in some jurisdiction, the policies he tabled may quite 
> > credibly become that strict.
> > 
> comfortable 
> > comfortable with IP - that is my assessment
> for plenty 
> > of systems in the emergency infrastructure before it ever became a 
> > voice trunking protocol. I have never liked the nethead/bellhead 
> > language because I think it gives wings to prejudice and clouds 
> > judgement. What I am saying is that I believe there is 
> sufficient body 
> > of knowledge and expertise in NENA to assess for themselves the 
> > validity, value, and practicality of having signed 
> location. I think 
> > you do too.
> > Particular individuals certainly did do a lion's share or 
> the work in 
> > the migratory and location working groups in NENA but nothing was 
> > documented that wasn't fully discussed, assessed, and agreed by the 
> > wider group.
> > 
> > People in this working group are trying to say what 
> emergency services 
> > policy should be and I believe that belongs with NENA for 
> the US and 
> > equivalent entities for other jurisdictions.
> > 
> > What you suggest with respect to call treatment is also perfectly 
> > valid and I have cited the same policy in previous posts as 
> an example 
> > of something realistic that the emergency jurisdiction may want to 
> > apply.
> users don't 
> > get quashed because somebody felt those end users weren't 
> qualified to 
> someone who 
> > requirements which you are referring to, I feel that we 
> should point 
> > out that these specific requirements come primarily from me (in the 
> > case of several of the security related requirements) and James 
> > Winterbottom, although there are several other people who were 
> > involved.
> > Although I have been working with NENA for several years now, I 
> > personally feel like I'm still the nethead in an otherwise bellhead 
> > environment there.  We're telling them how IP networks 
> behave and how 
> > they need to deal with them.  They certainly tell us a lot 
> about how 
> > the current system works, and how they use it.  I don't 
> think however, 
> > in this case, that you can really assert it is NENA that 
> brought forth 
> > these requirements.  We did it, and we pushed them through NENA.  
> > There isn't anything necessarily wrong with that; I just think you 
> > need to lay off some of the "NENA is the expert here"
> > rhetoric.  I
> rewrite the 
> > NENA requirements.  I wouldn't agree with how he 
> characterizes them.  
> > I'm actually more on Andy's side with regard to what these 
> mechanisms 
> > we are talking about are used for.
> > 
> > mechanisms are used.  It may well be in normal circumstances that 
> > calls with missing or invalid security checks are processed as a 
> > normal call, but with some alert to the call taker to be 
> more careful.  
> > However, if the PSAP was under direct DoS attack, then it may be 
> > policy that calls with missing or invalid security checks 
> are put on a 
> > queue that is answered less promptly than calls that have all the 
> > security mechanisms in place and working, or those calls 
> may be chosen 
> > to be diverted to another PSAP.  That might depend on the attack 
> > signature (and the policy).
> > 
> > Brian
> > 
> > > > It's actually quite inappropriate for the IETF to be 
> stating what
> > the
> > > > possible set of rules that one possible jurisdiction 
> may wish to 
> > > > adopt.
> > > >
> > > > regardless of access technology, given the right 
> approach. Ideally
> > the
> > > > On point 4 - you may argue that the "accountability" 
> aspect is not
> > an
> > > > if you have to, but failing to route the call via 
> system design is
> > not
> > > > okay.
> > > >
> > > > position to this system is behaving  according to the 
> best-effort 
> > > > nature of the underlying network.  While the phone system is
> > waiting for me to
> > > > present
> > > > an "unequivocal" location, your strawman is burning up 
> in the car
> > fire
> > > > I was calling to report.
> > > >
> > > > good luck!)?  Or the LIS, which should return the 
> likely service 
> > > > area of the attachment point as a non-point response?  If the 
> > > > latter, we may
> > have
> > > > something useful for identifying useful PSAPs, but it 
> is not the 
> > > > target device's location for lots of systems in which 
> the service 
> > > > area is large
> > > > (think:
> > > > WiMAX).
> > > >
> > > >>>> discussed - the latest concept to cause indigestion 
> is location 
> > > >>>> signing.
> > > >>>
> > > >>>
> > > >> This message is for the designated recipient only and 
> may contain 
> > > >> privileged, proprietary, or otherwise private
> > information.
> > > > This message is for the designated recipient only and 
> may contain 
> > > > privileged, proprietary, or otherwise private information.
> > > > immediately and delete the original.  Any unauthorized 
> use of this 
> > > > email is prohibited.
> > > >
> > 
> > This message is for the designated recipient only and may contain 
> > privileged, proprietary, or otherwise private information.
> immediately 
> > and delete the original.  Any unauthorized use of this email is 
> > prohibited.

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 13 Mar 2007 19:34:45 -0500

Well thanks for putting your cards on the table. I prefer to be able to
defend myself from direct comment than continually having to deal with
insinuation.

What you say is quite incorrect. We worked with NENA to understand their
requirements and designed the best solution we could to meet those
requirements; that's why HELD looks the way it does. The only forum we
have tabled HELD in for specification so far is the IETF.

What you are using is called "ad hominem rhetoric". Look it up. People
don't need to have an opinion of me to have an opinion on the protocols
and to assess the arguments with respect to requirements.

There are folk who are responsible for deploying solutions *now*. Look
at the Canadian situation with respect to the CRTC ruling on
implementing i2. The requirements for the location acquisition protocol
are as described, but they need an actual specification now - not "some
time"; that's why I'm anxious to move a specification forward that will
meet the immediate requirements.

Cheers,
Martin

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]] 
Sent: Wednesday, 14 March 2007 11:03 AM
To: Dawson, Martin
Cc: 'GEOPRIV'
Subject: RE: [Geopriv] NENA Requirements

Martin,

Since you obviously missed the inference, I'll explain.  It isn't the
NENA
general population that I witnessed reverse engineering requirements
from
their solution, it was YOU reverse engineering requirements from YOUR
solution.  This is something you have become proficient at as you forum
shop.

-Marc-

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 13 Mar 2007 19:41:30 -0500

I just remembered, there was a request for a reference to the FCC ruling
on VoIP 911 below. I'm never sure about support for attachments on these
lists - but here's the docket number information and a summary.

In the Matters of IP-Enabled Services 

E911 Requirements for IP-Enabled Service Providers	))))))	

WC Docket No. 04-36 

WC Docket No. 05-196

In summary, the FCC docket states:

* Interconnected VoIP service providers must provide E911, with location
and callback number, within 120 days of publication of the FCC's order
in the Federal Register. By interconnected VoIP providers, the FCC is
singling out those service providers who can originate or complete a
call to the PSTN.  (paragraph 37)

* The calls are to be routed through ANI or pseudo ANI. 

* Much like wireless E911, the interconnected VoIP service providers
obligations are dependent upon the capability of the PSAP to use the
information (paragraphs 37 and 42). The interconnected VoIP service
provider, though, must transmit all 911 calls to the appropriate PSAP
via the Wireline E911 network.  

* Location information is initially user generated (paragraph 46)

* The Commission does not dictate how the interconnected VoIP provider
achieves the mandate - whether through connection to the wireline E911,
through a competitive LEC or some other mechanism. 

* It is the obligation of each interconnected VoIP service provider to
understand what type of information that each PSAP is capable of
receiving and using. (Paragraph 43).

* No time limit exists on the time between updating of the location
information and any action necessary by the service provider to achieve
full E911 capabilities (paragraph 44).

* A Further Notice of Proposed Rulemaking seeks comment on location of
callers without user intervention. 

* The Commission notes with favor the standards work orchestrated by
NENA. 

The notice of "Proposed Rulemaking" augers the point where access
providers will be required to provide automatic location information for
use by VoIP devices.

Cheers,
Martin

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Wednesday, 14 March 2007 6:44 AM
To: Dawson, Martin
Cc: GEOPRIV
Subject: Re: [Geopriv] NENA Requirements

Hi Martin,

Ciao
Hannes

authentication
emergency

---

From: "Marc Linsner" <[email-masked]>
Date: Tue, 13 Mar 2007 23:22:49 -0400

Martin,

You are correct, your efforts to meet NENA desires are valiant.  And during
that process you disregarded all warnings that your solution would not be
successful on the Internet, afterall, it works in the lab.  Now in this
venue, you are still disregarding such warnings.

The speed at which this venue completes work is directly related to everyone
agreeing that the solution, not only fulfills the requirements, but has a
half a chance of success on the Internet.  

I apologize for the forum shopping statement, I applied the 'score sheet
that lacks engineering' project in ATIS to you, I could be wrong.

-Marc-

> Sent: Tuesday, March 13, 2007 8:35 PM
> To: Marc Linsner
> Cc: GEOPRIV
> Well thanks for putting your cards on the table. I prefer to 
> be able to defend myself from direct comment than continually 
> having to deal with insinuation.
> 
> What you say is quite incorrect. We worked with NENA to 
> understand their requirements and designed the best solution 
> we could to meet those requirements; that's why HELD looks 
> the way it does. The only forum we have tabled HELD in for 
> specification so far is the IETF.
> 
> What you are using is called "ad hominem rhetoric". Look it 
> up. People don't need to have an opinion of me to have an 
> opinion on the protocols and to assess the arguments with 
> respect to requirements.
> 
> There are folk who are responsible for deploying solutions 
> *now*. Look at the Canadian situation with respect to the 
> CRTC ruling on implementing i2. The requirements for the 
> location acquisition protocol are as described, but they need 
> an actual specification now - not "some time"; that's why I'm 
> anxious to move a specification forward that will meet the 
> immediate requirements.
> 
> Cheers,
> Martin
> 
> Since you obviously missed the inference, I'll explain.  It 
> isn't the NENA general population that I witnessed reverse 
> engineering requirements from their solution, it was YOU 
> reverse engineering requirements from YOUR solution.  This is 
> something you have become proficient at as you forum shop.
> 
> -Marc-
>  
> 
> > Yes, I understand what you're saying - I just think it is wrong. I 
> > think the requirements really are borne of genuine operational and 
> > application domain specific requirements - not from a 
> mindless attempt 
> > to retro-fit convention from switched circuit to Internet.
> > 
> > Cheers,
> > Martin
> > 
> systems, 
> > the Internet is an 'open' general use system.
> task better 
> > than a general purpose system.  So, while lots of people clamor to 
> > additional attributes that IP can/will deliver to a PSAP, 
> most within 
> > NENA don't understand the Internet architecture (note: IP knowledge 
> > does not equal Internet knowledge).
> > The
> > IMO, as a long-time NENA member and limited participant/casual 
> > observer of happenings inside NENA, several of the published NENA 
> > requirements were reverse engineered from an understood solution.  
> > Asking the IETF to exonorate the NENA solution will not produce the 
> > desired outcome.  NENA MUST convey their raw requirements 
> (hopefully 
> > in an Internet context) in order to foster a desire to solve their 
> > problems.  A great deal of frustration is derived 
> attempting to wade 
> > through the reverse engineered requirements to try and 
> understand the 
> > real underlying requirement.  And it is fact that not every 
> > requirement has an Internet solution (or spam would cease to exist).
> > 
> > One large point that NENA has failed to admit in the 
> Internet context 
> > is they will not control what is launched at them on the 
> Internet from 
> > afar.
> > > > > It is an act of hubris for the IETF to deprive 
> jurisdictions of
> > > these
> > > > > Yet another of the uses of signed location is in 
> providing this
> > > robust
> > > > > To link this to the "warnings" thread on Ecrit right 
> now, we're
> > > saying
> > > > > agrees with me.  Route the call, and let the local 
> policy at the
> > > PSAP
> > > > > decide

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 13 Mar 2007 22:41:20 -0500

Marc,

Your statement below is not really correct. The IETF only requires a
rough consensus to carry a motion. The only people that are really
objecting to this concept are you are Andy. Most the other vocal people
largely seem to be in agreement that it has merit. On that score I would
say that we have a rough consensus and that the sausage is sizzled!

Cheers
James

> Sent: Wednesday, 14 March 2007 2:23 PM
> To: Dawson, Martin
> Cc: 'GEOPRIV'
perfectly
> > > > > > going to be the stakeholders didn't think it could be
handled
> > > > > > properly.
> > > > > > capabilities of networks won't be frozen in time and they
will
> > > > become
> > > > > > link back to the source for this purpose; it's an
engineering
> > > > solution
> > > > > > there that there will be cases where a server should return
a
> > > > default,
> > > > > > might well be useful for tracking ill-described locations
and
> > > > similar
> > > > > > totally different.  With enough thrust the pig may fly, but
it
> > > > spoils
contain

---

From: Ted Hardie <[email-masked]>
Date: Tue, 13 Mar 2007 21:02:50 -0700

At 5:55 PM -0500 3/13/07, Dawson, Martin wrote:
>In the case of the former, I accept NENA's word for it that they understand the problem space and can make a successful judgement with respect to succeeding. The membership consists of everyone from the carrier space through to the PSAPs. The constant repetition of the second point only emphasises that people don't understand how the credentials can be used.

At least some of the examples that have been cited as challenges come from the
enterprise space.  Enterprises can and do select to use VoIP, and they can provide
location to end-users (one original point of the DHCP option work was to allow
wiremap database information to be transmitted easily to enterprise customers).
There are many more enterprises than carriers (and there are, at least if I understand
what you mean by carrier, many more network access providers in general).
You have restated some complex discussion of the trade-offs as:

"Certificate management is too complicated - people won't succeed"

If you aren't planning to extend certificates to everyone who would need one in
your model, you either won't succeed or you will cause a regulator to eliminate
a market to achieve your goal.  Neither would be, in my estimation, a good course of
action.  If you are going to extend certificates only to transit upstreams, then you
have to include in your model how the transitive trust works from that transit
upstream to the entity which provides location (e.g. the enterprise from its
wiremap) and/or to the customer.  Henning has suggested one possibility; I haven't
considered it carefully yet, but the suggestion points in the right direction:  re-use
existing relationships to get where you need to go, don't try to create new ones.
I am afraid that this challenges Richard's view, which states that trust relationships
must persist through this transition, without recognizing that the parties to the
relationships are increasing exponentially as we move to an Internet-based
infrastructure.  It says instead: build the infrastructure out of the trust relationships
that are present in the Internet model, rather than trying to cut the old ones
into the new cloth.

You've also taken statements about the security trade-offs and filtered them down to:
"PSAPs answer all the calls anyway so there's no point".  Among the things you
have removed from the soup of discussion were some pretty hearty chunks:
that there may be other forms of protection that would achieve the same goals
without the need for entering into the CA business; the idea that where the location
signing proposal is adopted, it would be to inform the calltaker or manage the
queue, rather than drop the call; and the clear statements that the kinds of location
which are sufficient for call routing may be the only ones available in many
circumstances and that these may be so coarse as to eliminate the perceived value
of the signature even in the case where the signature guarantees that the call
should go to that psap as it does not provide the traceability aspect that Henning
notes also came with the previous system.  I'm not sure that what's left is
going to nourish discussion very well.

We've all been at this for a long time, and some frustration at the pace of progress
is natural.  But if we stop listening to each other entirely, we're not going to get
faster.  I will commit to listening as carefully as I can to the issues you raise; I
hope you do the same.

				Ted

> 
>The requirements have been spelt out - and location signing has been proffered as the solution. The nay-sayers position is that the requirement should be discounted - they should offer a superior solution if they have one.
> 
>I have never said that the IETF has no experts in the identified fields - have I?
> 
>Cheers,
>Martin
> 
>
>I'm not sure what it is you are attempting to do, but to suggest that the IETF has no experts in the field of network security or Internet topology and cannot therefore apply that knowledge is quite simply wrong.
> 
>Location signing has been offered as a requirement.  It has been pointed out that location signing is a solution and not a requirement.  It has also been pointed out that the notion of network topology that is being applied to VoIP by this solution does not match the way the Internet works.
> 
>Also, it has been fair to question the actual use of location signing with respect to invalidly signed or unsigned location information.  To date, nobody has offered an authoritative policy... it is all supposition.  It seems rather silly to claim to be the authoritative voice on this issue when you cannot give concrete policy examples.
> 
>-andy
>
>
>

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 14 Mar 2007 01:19:46 -0500

Most certainly Ted - thanks for the mutual respect.

On the enterprise issue and the possibility of using transitive trust -
Yes, I posted a description the other day of how the assertion mechanism
could be used in conjunction with the existing trust relationship
between an Internet carrier and enterprises to minimize the population
of certificate owners. That was the one that does come under the Nortel
IPR that was raised.

I know I do a lot of posts - the subject was "RE:
[Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures)
" and it was posted on the 9th of March (though my posts were held up
for about 24 hours for some reason around that day). Rather than paste
it all into this thread, I can send you a copy if you like.

This situation has a precedent that predates Internet telephony as well.
Large (physically/geographically) enterprises have always had an issue
with the location associated with their outgoing trunk being a coarse
one relative to their actual geographic footprint. In many jurisdictions
- most states of the US even I think - this is just accepted. In some
jurisdictions sufficiently large "establishments" are required to
provide more precise location information - to a given area or number of
floors. This has been a challenge in those jurisdictions and the
solutions used involves a thing called PS-ALI, which is where the
enterprise actually purchases an external database system and can
configure the location associated with things called ELANs which end up
being associated with the outgoing CLI as it is set by the PABX. This is
clearly quite complex and costly - and I would suggest it is more so
than using assertion via a transitive trust relationship on an existing
LIS interface.

I think jurisdictions could choose between the following with respect to
enterprises:

* Just use the carrier level location, signed by the provider. As above,
this is if the additional precision doesn't represent a statutory
requirement.

* Provide a CA program that does cover large enterprises. There's a
strict requirement on enterprises keeping their key information secure.
It becomes part of their identity so it should be subject to much the
same level of regulatory oversight as Sarbanes-Oxley applies to
financial information. That's just IMHO of course.

* Use a transitive trust mechanism via something like assertion as
described above. It's very much the analog of PS-ALI (which may even be
argued to be prior art - just a thought) but it's a lot more light
weight from an implementation perspective.

* Something else - and I'm genuinely open to suggestions.

Between all these options, I think there is something workable for any
given global jurisdiction. I'd prefer an option that supported the
signing of the precise information that an enterprise can determine for
itself. Credentialed location has value beyond emergency services
whatever the jurisdiction requires for that particular application.

I didn't understand the comment about "...location being so coarse as to
eliminate the perceived value of signing..." Can you elaborate on what
you mean? I didn't understand how a coarse location used for routing
eliminated the tracability. The signature still identifies the source of
the location whatever the precision of the information is.

You had made the statement

"... there may be other forms of protection that would achieve the same
goals without the need for entering into the CA business."

There may be - but I haven't seen a proposal. Hannes suggested that
location by reference might do this, but I countered that a location
obtained that way won't have the same characteristics as a signed
location after all.

The characteristics desired - that provide the hearty chunks for
discussion are, as I've posted previously, that the location
information:

Can you propose something alternative to KPI to provide this?

Cheers,
Martin

-----Original Message-----
From: Ted Hardie [mailto:[email-masked]] 
Sent: Wednesday, 14 March 2007 3:03 PM
To: Dawson, Martin; Andrew Newton
Cc: Brian Rosen; GEOPRIV; Marc Linsner
Subject: RE: [Geopriv] NENA Requirements

At least some of the examples that have been cited as challenges come
from the
enterprise space.  Enterprises can and do select to use VoIP, and they
can provide
location to end-users (one original point of the DHCP option work was to
allow
wiremap database information to be transmitted easily to enterprise
customers).
There are many more enterprises than carriers (and there are, at least
if I understand
what you mean by carrier, many more network access providers in
general).
You have restated some complex discussion of the trade-offs as:

If you aren't planning to extend certificates to everyone who would need
one in
your model, you either won't succeed or you will cause a regulator to
eliminate
a market to achieve your goal.  Neither would be, in my estimation, a
good course of
action.  If you are going to extend certificates only to transit
upstreams, then you
have to include in your model how the transitive trust works from that
transit
upstream to the entity which provides location (e.g. the enterprise from
its
wiremap) and/or to the customer.  Henning has suggested one possibility;
I haven't
considered it carefully yet, but the suggestion points in the right
direction:  re-use
existing relationships to get where you need to go, don't try to create
new ones.
I am afraid that this challenges Richard's view, which states that trust
relationships
must persist through this transition, without recognizing that the
parties to the
relationships are increasing exponentially as we move to an
Internet-based
infrastructure.  It says instead: build the infrastructure out of the
trust relationships
that are present in the Internet model, rather than trying to cut the
old ones
into the new cloth.

You've also taken statements about the security trade-offs and filtered
them down to:
"PSAPs answer all the calls anyway so there's no point".  Among the
things you
have removed from the soup of discussion were some pretty hearty chunks:
that there may be other forms of protection that would achieve the same
goals
without the need for entering into the CA business; the idea that where
the location
signing proposal is adopted, it would be to inform the calltaker or
manage the
queue, rather than drop the call; and the clear statements that the
kinds of location
which are sufficient for call routing may be the only ones available in
many
circumstances and that these may be so coarse as to eliminate the
perceived value
of the signature even in the case where the signature guarantees that
the call
should go to that psap as it does not provide the traceability aspect
that Henning
notes also came with the previous system.  I'm not sure that what's left
is
going to nourish discussion very well.

We've all been at this for a long time, and some frustration at the pace
of progress
is natural.  But if we stop listening to each other entirely, we're not
going to get
faster.  I will commit to listening as carefully as I can to the issues
you raise; I
hope you do the same.

				Ted

- have I?
>Location signing has been offered as a requirement.  It has been
pointed out that location signing is a solution and not a requirement.
It has also been pointed out that the notion of network topology that is
being applied to VoIP by this solution does not match the way the
Internet works.

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 14 Mar 2007 01:33:56 -0500

Hi Marc,

Thank you - though don't feel worried that I missed the barbs in the
proffered hand of friendship. :) I assume you mean the recent liaison
document. Yes, I've been working on it - but it's not a specification
document. HELD isn't being pursued for specification anywhere else at
this stage. It probably depends what you mean by "forum shopping" but I
suggest we take that conversation down the bar - or at least off line.

There was indeed a lot of discussion about "location dependability" as
it was labelled in the NENA forum. However, what you're characterizing
as warnings are just the same points that are being made on the same
topic in this forum. I wouldn't characterize them as unheeded warnings -
just the same points that are being discussed now and ones I still have
contrary views on.

I don't know what the whole "It doesn't work on the Internet" thing is
supposed to convey. For me it doesn't convey any particular point - so
just saying it doesn't move my opinion either way. I don't think the
Internet is a mystery... maybe I just haven't been inducted into the
inner sanctum.

Cheers,
Martin

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]] 
Sent: Wednesday, 14 March 2007 2:23 PM
To: Dawson, Martin
Cc: 'GEOPRIV'
Subject: RE: [Geopriv] NENA Requirements

Martin,

You are correct, your efforts to meet NENA desires are valiant.  And
during
that process you disregarded all warnings that your solution would not
be
successful on the Internet, afterall, it works in the lab.  Now in this
venue, you are still disregarding such warnings.

The speed at which this venue completes work is directly related to
everyone
agreeing that the solution, not only fulfills the requirements, but has
a
half a chance of success on the Internet.  

-Marc-

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 14 Mar 2007 01:39:16 -0500

Definitely - most certainly. And Australia does support SIMless calling,
the emergency services would like to turn it off. New Zealand did, in
fact, turn it off in the last 18 months.

My point, however, is that the actual identity of the caller isn't the
gating factor. Indeed, the question of whether you're using your phone
or someone else's doesn't come up.

The fact that the specific issue of SIMless calling policy varies from
jurisdiction to jurisdiction just goes to show that different
jurisdictions do have different policies and the networks need to
provide the hooks for those policies that each one does consider
necessary.

Cheers,
Martin

-----Original Message-----
From: Haberler Michael [mailto:[email-masked]] 
Sent: Wednesday, 14 March 2007 5:25 PM
To: Dawson, Martin
Cc: Henning Schulzrinne; Winterbottom, James; GEOPRIV WG; Marc Linsner;
[email-masked]

> hands on a device is an accepted feature of the service.

just noting SIMless 911 seems to be not universally accepted -

Switzerland explicitely denies SIMless emergency calls

in Austria recommended procedure for mountaineers is to remove the  
SIM before the hike to get better coverage for 140 (mountain rescue)

downside of this is - Vienna police gets a surge of SIMless 112 calls  
every saturday as stolen mobiles are tested for functionality on the  
flea markets by calling 112

more relevant (possibly to ECRIT towards PSAP contact publishing  
requirements) is - Switzerland publishes *routing numbers* as PSAP  
destinations which are meaningful only in a national interconnect  
scenario

-Michael

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 14 Mar 2007 08:41:30 +0100

Hi James,

The TLS server-side authentication would identify the ISP in this 
scenario and the PIDF-LO would contain a provided 'provided-by' element 
that contains the identity of the RANP. Unless you suddenly assume that 
the RANP might be the adversary and that there is no trust relationship 
between the ISP and RNAP everything just works fine. In previous 
discussions with LIS-to-LIS communication we just made these assumptions.

I see no problem.

Ciao
Hannes

Winterbottom, James wrote:
>> The one for routing does not need to provide a perfect precision, as
>>     
> we
>   
>> know. For some countries it would be sufficient to use state
>>     
> granularity
>   
>> to hit the correct PSAP.
>>
>> If we have to use a location-by-reference mechanism for these
>>     
> operators
>   
>> emergency service calls since we will even see calls with absolutely
>>     
> no
>   
>> location information at all. Furthermore, we would have to tell the
>>     
> IEEE
>   
>>>> fairly elaborate delegation mechanism, somebody externally will
>>>>         
> have
>   
>>>> to sign for each and every room. This means that the organization
>>>>         
> has
>   
>>> Location granularity and certification granularity are two
>>>       
> orthogonal
>   
>>> Columbia campus, then there's only one certificate to manage.  If
>>>       
> you
>   
>>> have each server reach back to a central signing server for a
>>>       
> signature.
>   
>>> --RB
>>>
>>>       
>>>>
>>>>
>>>>         
>>>>> [AJW] It is not clear to me how authenticating millions of users
>>>>>           
> and
>   
>>>> traction. The PSAP wouldn't care whether and how the VSP verified
>>>>         
> the
>   
>>>> customer identity; it just gets a single client cert from the VSP
>>>>         
> in
>   
>>>> a TLS connection.
>>>>
>>>> concern and the perceived difficulties of a global PKI motivated
>>>>         
> the
>   
>>>>> providers. But perhaps I am missing the point. That said, if you
>>>>>           
>> couple
>>     
>>>>> this with signed location then you have the whole gamut. See
>>>>>           
> location
>   
>>>>> dependability draft
>>>>> http://tools.ietf.org/html/draft-thomson-geopriv-location-
>>>>>           
>> dependability-
>>     
>>>>> 00
>>>>>
>>>>>           
>>>>>> have any location attached to it. How many calls today have
>>>>>>             
> location
>   
>>>>> [AJW] All emergency calls in the world have some degree of
>>>>>           
> location
>   
>>>>> provided (inferred), though in some cases this may not be
>>>>>           
>> fantastically
>>     
>>>>> accurate, country level. In the United States for wireline it is
>>>>>           
> based
>   
>>>>> Perhaps, like some other working groups we need to make the
>>>>>           
>> distinction
>>     
>>>> This doesn't quite work, given that phones need to work
>>>>         
> universally.
>   
>>>> I don't want to buy a phone in Prague, say, that suddenly can't
>>>>         
> make
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 14 Mar 2007 08:44:34 +0100

Hi Martin,

> calls anyway so there's no point".
I hope you understand that with security there are a lot of tradeoffs. 
There is no free lunch with security.
We are trying to balance the perceived security advantages to the costs.

When I worked on other security protocols I had to look at this tradeoff 
quite often. At the beginning I often noticed that people get excited 
when developing new security mechanisms but there is also a downside.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 14 Mar 2007 08:56:50 +0100

Hi Martin,

> subscriber identity be delivered with some kind of strong credentials.
I don't understand this sentence.

> Firstly, the requirements were about location - so why would subscriber
In the past a lot of discussions circled around the idea of putting the 
subscriber identity into the PIDF-LO (entity attribute) and then to tie 
it to subsequent authentication of the emergency caller to the PSAP to 
mitigate some replay attacks.

> hands on a device is an accepted feature of the service.
I don't know why you think that the true identity of the emergency 
caller is not relevant for emergency services.
The public payphone has been a source for misuse even. Some countries 
don't allow SIMless emergency calls exactly for the misuse purpose.

For the Internet, it is not even clear what "SIMless" emergency calls 
means. Does it mean "unauthenticated network access", emergency calls 
without authentication,  no authorization, etc?

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 14 Mar 2007 08:59:45 +0100

My previous comments on various aspects can be found in the mailing list 
archives. There is no secret here.

I would like to hear from you whether you would like to see an 
architecture where VoIP providers need to establish relationships with 
access providers.

Ciao
Hannes

Dawson, Martin wrote:
>> I certainly tried to get people to consider the requirements from NENA
>>     
> -
>   
>> driven by the i2 architecture weren't relevant ("architecture is
>>     
> broken"
>   
>> unqualified to present any and spend all their time trying to
>>     
> discredit
>   
>> proposals on that basis.
>>     
>
>> I will put together a list of what I think all the requirements are
>>     
> that
>   
>> convenience of the reader. If this document should inadvertently
>>     
> differ
>   
>> impact to call setup time in the event that location is not known
>>     
> ahead
>   
>> of time.
>>
>> DA9 - Where a device is not location aware the IP Access network
>>     
> should
>   
>> DA11 - A location determination method must exist that does not
>>     
> require
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 14 Mar 2007 09:05:23 +0100

Hi Martin,

please find some comments below:

Dawson, Martin wrote:
> the voice service *is* the access service.

IMS assumes that the access provider is the VoIP provider. That's a bit 
different.

Both views are unrealistic (my personal opinion).

>  It misses the major point of
Today it, however, seems that the 3GPP does not even consider a 
location-by-reference nor a location signing approach.
They are just happy with their emergency service architecture as is.

> should still have the characteristics identified by the requirements.
Why would you want to protect location twice?
To me this looks like using HTTPS and S-HTTP together.

> being provided right now.
I don't agree that this is a realistic threat scenario based on what I 
replied to James.

> begins to drag its other foot into the grave.
I hope you are going to be at the IEEE / ECRIT information sharing 
meeting in Prague.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 14 Mar 2007 09:55:03 +0100

Hi Raymond,

one issue that is quite important to me is whether regulators will demand

* "unauthenticated network access" for emergency calls
This means that an emergency caller can attach to a network even though 
it does not have credentials for this network. For example, someone 
might just use Ericsson enterprise network (or my private WLAN DSL home 
network) for an emergency call.

* authenticated (but unauthorized) emergency calls where some form of 
authentication of the emergency caller needs to take place.

None of these two aspect directly correspond the concept of SIMless 
emergency calls since the credentials for the two mechanisms are 
typically different.
So, it remains open what it means to have SIM-less emergency calls on 
the Internet, from a technical and from a regulatory side. It might well 
be that the trend for a more restrictive user identification makes the 
entire subject irrelevant.

Ciao
Hannes

Raymond Forbes (CV/ETL) wrote:
>  
> We have had similar discussion in ETSI many Times, I can confirm that
> Currently, Two Countries mandate by law that SIM-less Emergency Calls
> Shall be allowed. In Germany these calls are still traceable though the
> Mobile may not be uniquely identifiable, as a dummy CLI is allocated to
> the call, the actual Mobile Equipment may also be traced as the IMEI may
> be sent over the air. In Austria I am not aware of the solution.
>
> In the UK, Eire, Switzerland, and increasingly in other EU countries;
> SIM-Less Emergency Calls are forbidden as the Mobile traceability is
> mandated by law. In a number of countries like France and Portugal that
> did allow SIM-less Emergency calls though not by mandate the laws and
> systems now (or soon will) forbid them. The reason for this change is
> that the Emergency services were flooded with Anonymous calls from
> second hand traders of Mobile handsets. 
>
> Regards,
>
> Ray Forbes
> Ericsson Limited
> BU Networks (CV/ETL/BBC/D)
> Telephone: +44 (0) 24 7656 3106
> Mobile: +44 (0) 771 851 1361
> Email: [email-masked]
>
> Registered Office: Unit 4, Midleton Gate, Guildford Business Park,
> Guildford, Surrey, GU2 8SG.  Registered Number in England and Wales:
> 942215
>
> This communication is confidential and intended solely for the
> addressee(s). Any unauthorised review, use, disclosure or distribution
> is prohibited. If you believe this message has been sent to you in
> error, please notify the sender by replying to this transmission and
> delete the message without disclosing it. Thank you. 
>
> Ericsson Limited does not enter into contracts or contractual
> obligations via electronic mail, unless otherwise agreed in writing
> between the parties concerned.
>
> E-mail including attachments is susceptible to data corruption,
> interruption, unauthorised amendment, tampering and viruses, and we only
> send and receive e-mails on the basis that we are not liable for any
> such corruption, interception, amendment, tampering or viruses or any
> consequences thereof. 
>
> Sent: 14 March 2007 06:25
> To: Dawson, Martin
> Cc: GEOPRIV WG; [email-masked]
> Subject: [Ecrit] Re: [Geopriv] RE: Strawman Proposal
>
>
> in Austria recommended procedure for mountaineers is to remove the SIM
> before the hike to get better coverage for 140 (mountain rescue)
>
> Ecrit mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ecrit
>
> Ecrit mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ecrit
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 14 Mar 2007 10:09:33 +0100

Hi James,

I see only three options when operators only want to provide location 
information to authorized nodes:

* IMS based approach where the access network runs the SIP proxy
* Location-by-reference with the major deployment drawback of having 
relationships between access networks and VoIP providers

Both approaches are not desirable since they are not deployment friendly 
(personal opinion).

I don't see how location signing would provide any help here.

As an only way out I believe that location information sufficient for 
routing has to be made available to the end host together with a 
reference that can then be retrieved by the PSAP operator.

Ciao
Hannes

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 14 Mar 2007 04:35:18 -0500

I think the costs are:
 
* Ensure the location acquisition protocol definition can support delivery of a signed location
* Define a common specification for what a signed location is
 
Implementation costs vary from jurisdiction to jurisdiction and how far they want to go with CA infrastructure. All I have ever said is don't deprive them of the option.
 
Yes, I do appreciate that optimal also means compromise. Indeed, that cuts both ways in this discussion, and I think it's the implementors who will be in the best position to evaluate the compromises for their application domain.
 
Cheers,
Martin

From: Hannes Tschofenig [mailto:[email-masked]]
Sent: Wed 3/14/2007 6:44 PM
To: Dawson, Martin
Cc: Andrew Newton; Ted Hardie; GEOPRIV; Marc Linsner
Subject: Re: [Geopriv] NENA Requirements

Hi Martin,

Ciao
Hannes

---

From: Andrew Newton <[email-masked]>
Date: Wed, 14 Mar 2007 05:47:25 -0400

James,

You probably need to reread the mailing list again, because the count  
against your measurement is inaccurate.

I tried to summarize the various positions as I saw them in a  
previous thread, and the breakdown did not fall into two simple camps.

All of the probing questions are useful if we go forward with  
location signing, because we will be forced to create a threats  
analysis document to get past the IETF.  And it will have to be  
honest and upfront about all these issues.  Hell hath no furry like a  
Security AD; I can tell you from experience.

-andy

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 14 Mar 2007 04:48:22 -0500

Presumably you have seen my other post stating my position with respect to linking access providers and voice service providers. There is absolutely no technical imperative to do this. I said at the SDO meeting in Columbia that the biggest delta in the room was between ECRIT/NENA and 3GPP/2. The IMS architecture appears to require that the access network requires the presence of P-CSCF (and an emergency E-CSCF) before the IMS VoIP service can be used. Indeed, it requires the visited network operator to authenticate the home IMS subscriber identity. It's exactly the same model that applied to cellular for roaming.
 
If I'm not being clear enough: "I do not think VoIP service access should depend on what Internet access provider is being used."
 
Are we on the same page there?
 
This is actually important - because I think it directly highlights the difference between the identity a device has from the network perspective to the identity associated with a VoIP service subscription.
 
I definitely think that physics dictates that the access network is the right entity to provide the location information. At the same time, I do not think that the access network should have to know anything about what the device user's VoIP subscription identity is.

> subscriber identity be delivered with some kind of strong credentials.

I was saying that the NENA location requirements do not state that the location information needs to be delivered with the subscriber information. As above, the two pieces of information should come from orthogonal and unrelated systems - they might be the same system because of some specific implementation scenario constraint (e.g. IMS) but not for the general model (e.g. Skype).
 
Cheers,
Martin

From: Hannes Tschofenig [mailto:[email-masked]]
Sent: Wed 3/14/2007 6:59 PM
To: Dawson, Martin
Cc: GEOPRIV
Subject: Re: [Geopriv] NENA Requirements

Ciao
Hannes

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 14 Mar 2007 05:05:19 -0500

It is absolutely not the same as unauthenticated network access. It can be construed to mean that in a cellular enviornmoent because network access and voice service are lumped together as the same thing. In the Internet, the equivalent of a "SIMless" VoIP call would be one where the VoIP service could be used without needing any kind of subscriber authentication and authorization to use the service.
 
I actually think that the ECRIT and i3 models approach the SIMless situation. After all, the idea is that no VoIP provider is needed any more. I go to a LoST server, get the route to the emergency call center and initiate the call independently without subscriber authentication even coming into it.
 
Yes, payphones and SIMless phones are sources of nuisance calls and so, indeed, are calls from phones with a subscription. I hope you don't infer from my comments that I don't think these are of concern to the emergency services community. I'm saying that one thing the system doesn't do at the moment is gate service on the pre-supposed identity of the human caller. I have not seen any standard call taker procedures that cover establishing the identity of the caller.
 
I think it's very interesting that subscriber identity and access identity are treated interchangeably in the discussion. I think they are completely different - and they are actually different again to the actual identity of the person making the call.
 
Cheers,
Martin

From: Hannes Tschofenig [mailto:[email-masked]]
Sent: Wed 3/14/2007 6:56 PM
To: Dawson, Martin
Cc: Henning Schulzrinne; Winterbottom, James; GEOPRIV; Marc Linsner
Subject: Re: [Geopriv] RE: Strawman Proposal

Hi Martin,

Ciao
Hannes

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 14 Mar 2007 05:39:43 -0500

Hi Hannes,
		 
		My further comments below.
		 
		Cheers,
		Martin

		From: Hannes Tschofenig [mailto:[email-masked]]
		Sent: Wed 3/14/2007 7:05 PM
		To: Dawson, Martin
		Cc: Richard Barnes; Henning Schulzrinne; GEOPRIV; Marc Linsner
		Subject: Re: [Geopriv] RE: Strawman Proposal

Hi Martin,

[MCD] I think we are saying the same thing

[MCD] I could go on about how an ESRK actually is a location reference or that the cypher mechanisms used to identify the SUPL server are examples of these things but there's no real point because we've already established that the Internet service model is what introduces the specific issues - and these didn't exist in the same sense for cellular.

[MCD] Imagine a VPC (or a PSAP if that simplifies the model) receives a location reference as part of a call. Now it is going to go to the URI indicated by that reference. How is it going to know that the LIS serving that URI is trusted? I think the answer is that it needs to be certified by some recognized authority. Finally, since the dereferencer may still not be the ultimate consumer of the location object, I'd still prefer to keep the option of getting a signed LO via this interface as well.

[MCD] I wish. Unfortunately it's enough of a challenge to get travel funding just for James.

Ciao
Hannes

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 14 Mar 2007 08:28:42 -0400

> second hand traders of Mobile handsets.

I don't know what kind of location conveyance is used there (the  
equivalent of Phase II wireless seems less common in Europe), but it  
is pretty clear that reliable location delivery would help very  
little. It would be interesting to see where most of today's crank  
calls are coming from; if they are from pay phones on strip malls,  
location reporting isn't exactly going to help with that problem, as  
the location information for these is not in doubt.

I agree with Hannes that we need an overall threat model, not just a  
threat model for conveying location. After all, I suspect that NENA  
and PSAP don't really care whether bogus calls are prevented by some  
fancy crypto math or some truth inducer in handsets that makes it  
impossible for callers to lie when dialing 911.

Like I said before, I'm not opposed to investigating the role of  
signing location information, but I believe that it is being oversold.

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 14 Mar 2007 08:44:28 -0400

> or someone else's doesn't come up.

The whole point of disallowing SIMless emergency calls is that

- it makes it impossible to find and fine the nuisance caller

- the caller knows that and acts accordingly

I believe that traceable identity largely addresses the individual  
nuisance call problem. (Unlike for SIMless phones, where the SIM is  
tied to having a contract and paying, it is much easier to imagine no- 
fee, verified SIP accounts that only do emergency calling.)

Just like location signing, this does not have to be perfect to be  
useful. Most everyone seems to agree that not all calls will have  
signed locations, so, with any assurance scheme, PSAPs will have to  
deal with unauthenticated and unsigned calls, using the  
prioritization mechanisms Brian keeps talking about.

The advantage of verified identity is that it works today, without a  
new infrastructure or a new national CA. Thus, I see it as an  
important part of the tool kit that will lower the deployment hurdles  
and will allow us to avoid having to build a perfect location signing  
system.

Thus, I can imagine four levels of calls:

(1) assured identity and assured fine-grained location

(2) assured identity and unsigned location -> unlikely to be spoofed;  
equivalent to a large fraction of today's wireless calls

(3) no traceable identity and signed location -> equivalent to a  
payphone or SIMless wireless call today, i.e., treat with caution

(4) no identity assurance, no location signing -> suspicious, handle  
with care and drop during overload

Here, identity can be either a L2/L3 identity or a VSP identity; it  
really doesn't much matter, although VSP identity is the one that's  
currently available without extra mechanism.

The "bot net" out of area attack vector is a different issue and  
should be discussed separately.

Henning

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 14 Mar 2007 08:10:30 -0500

Viz:

     " Here, identity can be either a L2/L3 identity or a VSP identity;
it  
       really doesn't much matter..."

On the one hand, the VSP doesn't know about the point of access used by
the subscriber - so it can't actually say anything about the call's
point of origin. It doesn't matter if you can identify the person's
Skype account if they live in Madagascar but are calling a Manhattan
PSAP anyway. And you're not going to be able to use the information for
any kind of real time policy activation - Madagascan's are allowed to
visit Manhattan and make emergency calls after all and you can't tell
the difference with this scheme.

On the other hand, you generally state that VSPs are a transient
phenomenon and there won't be any subscriber identity to utilize anyway.
So I infer that, in the long run, you don't actually think VoIP service
subscriber identity will be useful?

And, on yet another hand (oops - must have been those Pacific nuclear
tests), the use of L2/L3 identity either ties the voice service together
with the access service (see the IMS discussion) or it actually requires
some sort of signed blob to be provided by the access network to the
device for conveyance in the VoIP signalling channel or by dereferenced
retrieval from some access-located service - which sounds kind of
familiar right? That is, the same implications as signed location.

If people really do want to include the ability to convey some sort of
secure subscriber identity with emergency calls, then I have no
objections to that being part of the toolkit for VoIP emergency calling.
It's certainly not a requirement that I have brought from the NENA
working group - though maybe some other committee has requested it and
I'm sure PSAP operators would vote in favour of having it. I think it's
a quite independent concept to signed location information even if they
feel like they belong in the same part of the zoo - and I don't think it
offers the same utility. I'm quite comfortable with a LIS being
responsible for providing the location credential component. As long as
nobody is saying it would be responsible for this subscriber identity
function as well then go ahead with my blessings.

Cheers,
Martin

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Wednesday, 14 March 2007 11:44 PM
To: GEOPRIV
Cc: ECRIT
Subject: Re: [Geopriv] RE: Strawman Proposal

Henning

---

From: "Marc Linsner" <[email-masked]>
Date: Wed, 14 Mar 2007 09:44:39 -0400

James, Martin

Your total disregard of the information from those that have experience in
the solution space you are suggesting is amazing.  Andy has actual
experience (made a living doing such) in digital signatures and certificate
management, your experience in this area is not apparent.  But yet your
attitude of 'Don't confuse me with the facts my mine's made up!' seems very
odd to many people.

Like Andy stated, you think it's rough now, wait till your proposal gets to
the IESG.  I'm only glad that it won't be shepherded by an ECRIT chair.  :^)

-Marc-

> Sent: Tuesday, March 13, 2007 11:41 PM
> To: Marc Linsner; Dawson, Martin
> Cc: GEOPRIV
> Your statement below is not really correct. The IETF only 
> requires a rough consensus to carry a motion. The only people 
> that are really objecting to this concept are you are Andy. 
> Most the other vocal people largely seem to be in agreement 
> that it has merit. On that score I would say that we have a 
> rough consensus and that the sausage is sizzled!
> 
> Cheers
> James
> 
> > during that process you disregarded all warnings that your solution 
> > would not
> be
> > everyone agreeing that the solution, not only fulfills the 
> > requirements, but
> has a
> > > Well thanks for putting your cards on the table. I prefer 
> to be able 
> > > to defend myself from direct comment than continually 
> having to deal 
> > > with insinuation.
> > >
> understand 
> > > their requirements and designed the best solution we 
> could to meet 
> > > those requirements; that's why HELD looks the way it 
> does. The only 
> > > forum we have tabled HELD in for specification so far is the IETF.
> > >
> > > What you are using is called "ad hominem rhetoric". Look it up. 
> > > People don't need to have an opinion of me to have an 
> opinion on the 
> > > protocols and to assess the arguments with respect to 
> requirements.
> > >
> > > There are folk who are responsible for deploying solutions *now*. 
> > > Look at the Canadian situation with respect to the CRTC ruling on 
> > > implementing i2. The requirements for the location acquisition 
> > > protocol are as described, but they need an actual 
> specification now 
> > > - not "some time"; that's why I'm anxious to move a specification 
> > > forward that will meet the immediate requirements.
> > >
> > > Cheers,
> > > Martin
> > >
> > > Since you obviously missed the inference, I'll explain.  It isn't 
> > > the NENA general population that I witnessed reverse engineering 
> > > requirements from their solution, it was YOU reverse engineering 
> > > requirements from YOUR solution.  This is something you 
> have become 
> > > proficient at as you forum shop.
> > >
> > > -Marc-
> > >
> > >
> > > > I have hope that we'll get there....but I sense more 
> pain in the 
> > > > future.
> > > >
> > > > -Marc-
> > > >
> > > > > > > quite incorrect. They have more experience in 
> making complex
> > > > > networks,
> > > > > > > processes and there's no less of an imperative 
> for it for IP 
> > > > > > > telephony.
> > > > > > > circumstance, and these indicators would be used 
> at most for
> > > > > ranking.
> > > > > > >

---

From: "Stark, Barbara" <[email-masked]>
Date: Wed, 14 Mar 2007 13:44:59 -0400

> It seems that IMS actually makes that 
> assumption - using the traditional "roaming partner" model that 
> assumes the voice service *is* the access service.

Just as an aside, please be careful as to whose view of IMS you're
referring to. While this may be the view of 3GPP, where GSM is an
integral part of IMS, it is not the view of telcos who are actually
implementing IMS. The view of telcos is that GSM is just another access
technology. In this telco view, connectivity to the IMS core will
generally occur over the public Internet, and there is absolutely no
correlation between access provider and IMS provider in that case.
---------
Also, while requiring SIMS will take care of authentication in a cell
phone world, it does nothing about people who launch point-to-point SIP
calls. Given the architecture we're creating, it will be very simple for
someone with a simple SIP client to create a PIDF-LO, do a LoST sos
query, and make a call over the Internet to the result of that query,
without ever touching a VSP. The access network will not be in a
position to screen such calls, and (from what I've seen) there would
probably be a public outcry if people were actually required to have a
"real" VSP, before making a SIP call.

If the PSAP wants to refuse to accept such calls, then that will be a
national/jurisdictional decision.

Then again, there are VSPs that offer free calling over the Internet,
that don't really care about the identities of their users, and would
have difficulty tracking these users if pressed to do so. There can be
fly-by-night VSPs (it's not really that hard to create your own VSP for
your own use, and set it up in a hotel room somewhere), and there can be
VSPs in countries with lax laws. VSPs, as a generalization, are just as
trustworthy as end users.

Which means that the PSAP who wants to really restrict calls to those
that are properly "authenticated", would have to only accept calls from
VSPs that they know they can trust. Which is a very limiting
proposition, and I don't think that's where we want to go.

If PSAPs are permitted to do a LbyR lookup related to the IP address,
then the attacker will at least have to be able to pretend to be at that
IP address (through something physical at that IP address, or that can
intercept all traffic to that IP address, and not simple spoofing). This
is definitely a critical capability, though it's not perfect. 

I don't think that signatures needs to be a part of an LCP (I agree that
it's distinct from the protocol), but I think it would be useful to have
a standard means defined for signing PIDF-LOs. I also think that the LCP
needs to support location assertion for the purpose of getting a PIDF-LO
signed, in the event that a jurisdiction or country wants to go that
route. Assertion is also useful as a means of providing a presence
server with a GPS-calculated location.
Barbara

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA622

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 14 Mar 2007 20:08:53 +0100

Hi Barbara,

thanks for your input. Please find a few responses below:

> correlation between access provider and IMS provider in that case.
With this view of IMS their emergency service architecture does not work.

> without ever touching a VSP.

That's true. The problem is only that the 3GPP has not specified a 
protocol for the end host to retrieve location information.
Hence, it would be difficult for the client to create a PIDF-LO (unless 
it is equipped with a GPS device).

>  The access network will not be in a

> national/jurisdictional decision.
I agree.

> have difficulty tracking these users if pressed to do so.

That's not true. Even with free calling over the Internet almost all VSP 
require some form of authentication. The same is true with email 
providers today. Some require a quite strong assurance that you are 
indeed the person you claim to be.

Obviously it would be possible to create a legal framework around this 
for emergency services (as we assume it with everything else as well).

>  There can be
That might be true.

> proposition, and I don't think that's where we want to go.
You have just described the SPIT problem, btw.

Why do you think it would be better to
* use signed location information (if you also claim that operators 
don't want to distribute location information to the end hosts), and
* resolving a location-by-reference is only allowed by authorized entities

> is definitely a critical capability, though it's not perfect. 

I don't understand what that means? How does a LbyR lookup based on the 
IP address work? I thought we said that the lookup would work by using 
the HTTPS or SIPS URI.

The IP address that is seen by the PSAP will not be the IP address of 
the end host in most cases anyway since there are so many tunneling, 
NAT, VPN, mobility solutions out there that you just block something.

> it's distinct from the protocol),

What does that mean? I thought that the idea was to use the LCP to 
request a signed LO.

>  but I think it would be useful to have
> a standard means defined for signing PIDF-LOs.
With SIP Location Conveyance you already have a way todo so, although it 
is not really useful since you have to resolve the reference via TLS and 
the signed PIDF-LO would just do the same thing essentially twice -- my 
HTTPS/S-HTTP description applies.

>  I also think that the LCP
> signed,
This statement does not align nicely with the previous sentence.

>  in the event that a jurisdiction or country wants to go that
But in this case you would really want to use an S/MIME signed PIDF-LO.

Ciao
Hannes

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Wed, 14 Mar 2007 15:21:56 -0400

The liaison process to the IETF is simple enough. It passes through the WG 
Chair(s), preferably with additional notice to the list. See RFC 4053 for a 
complete description.

---

From: Otmar Lendl <[email-masked]>
Date: Thu, 15 Mar 2007 17:46:35 +0100

[Unrelated to ecrit/geopriv, but I'm curious.]

> second hand traders of Mobile handsets. 

If these anonymous test calls are reason for disabling a possible
life-saving feature (emergency calls from SIM-less phones), why didn't
the regulator instead force carriers to implement a simple test-number
which could be used by those second hand traders without bothering PSAPs?

It's not like these traders _want_ to harrass the PSAPs.

/ol
-- 
< Otmar Lendl ([email-masked]) | nic.at Systems Engineer >

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 15 Mar 2007 14:16:39 -0400

I have pointed out the flaw in the transitive trust model, where the access
network carrier vouches for the location of one of its customers.  The
problem is liability.  The access carrier gets to take on the liability of
the information being wrong, and gets no value in return.  It seems so
unlikely to me that we could compel them to do it in a way that makes their
liability go away.  

Imagine the following: an enterprise has a main campus and a satellite
campus.  It has a T3 or Metro Ethernet service into its main campus, and it
has a dark fiber between the main campus and the satellite.  Are you going
to demand that the T3 carrier serving 123 Main St sign a location for 456
Locust?  AT BEST, all the access carrier could do is sign something that
says "I have a customer I know as Ajax Manufacturing, and I serve him at 123
Main Street".  You can't assert that he is actually Ajax, and you sure won't
sign something that says 456 Locust.

Brian

> Sent: Wednesday, March 14, 2007 2:20 AM
> To: Ted Hardie; Andrew Newton

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 15 Mar 2007 14:09:13 -0400

I've been trying to figure out where to insert my thoughts on this issue,
this is as good a place as any.

I think that the problem we are trying to solve is diversion of resources,
and I think Henning's classification (lone hacker remote, lone hacker local,
and organized DDoS) is about right.  It is true that we tend to focus on the
solutions more than the problems, and it is true that we look at the loss of
a reasonably secured location source as the problem, rather than a symptom.

That being said, I do think that the advantage of focusing on the location
is a more tractable solution because they are always local, whereas the call
network is often not.  We can reasonably expect to be able to develop trust
relationships between entities that are local to one another more than we
can reasonably expect entities that are quite diffuse, and have no other
reasons to interact in ways which would allow trust relationships to be
formed.

I also think there is a pretty substantive difference between a lie of the
form "I am Joe Blow" and one of the form "I am at 123 Main St".  In the end,
we really don't care who you are, and we really do care where you are.

I do recognize that enterprise is the largest problem for developing trust
relationships, because there are so many of them.  This is indeed the
challenge.  It's also true that at least for the foreseeable future, there
will be many more enterprises with their own location infrastructure than
enterprises with their own path to introduce calls to the emergency calling
system, rather than using a carrier. 

I have pointed out before that with a little work, we can exploit an
existing "validation" mechanism and extend it to validation of credentials
for enterprise.  Every enterprise receives, approximately yearly in most
jurisdictions, a physical visit from someone in the public safety community.
It's a "fire marshal" in the U.S.  They make a physical inspection of the
facility.  If, among the fire marshal's duties on such visits, there was a
call to a test number from any phone, we could validate credentials.  This
level of validation exceeds nearly every form of PKI that has been fielded.
You have an actual visit by a person to the facility and s/he verifies that
the credential's identification information is valid ("Yep, I am in Ajax
Manufacturing, and it does report its address as 123 Main St").

Brian

> Sent: Wednesday, March 14, 2007 12:03 AM
> carrier space through to the PSAPs. The constant repetition of the second
> point only emphasises that people don't understand how the credentials can
> be used.
> 
> proffered as the solution. The nay-sayers position is that the requirement
> should be discounted - they should offer a superior solution if they have
> one.
> >
> >I'm not sure what it is you are attempting to do, but to suggest that the
> IETF has no experts in the field of network security or Internet topology
> and cannot therefore apply that knowledge is quite simply wrong.
> >
> date, nobody has offered an authoritative policy... it is all supposition.
> It seems rather silly to claim to be the authoritative voice on this issue
> when you cannot give concrete policy examples.
> >
> >-andy
> >
> >
> >

---

From: "Marc Linsner" <[email-masked]>
Date: Thu, 15 Mar 2007 14:34:46 -0400

Brian,

At this point in the process, we need consensus on the requirement.  I'm not
the chair, but I haven't seen it.

> 
> I've been trying to figure out where to insert my thoughts on 
> this issue, this is as good a place as any.
> 

We need to stop here and see if everyone agrees this is the requirement?

 and I think Henning's classification (lone 
> hacker remote, lone hacker local, and organized DDoS) is 
> about right.  

These are architectures by which the above requirement can be rendered
broken.  Is there consensus that this is inclusive?

I think additional mitigating factors deserve consideration (and agreement)
like (non-inclusive):

No assumption there will be regulation forcing compliance.
No assumption that regulation can enforce compliance.

It is true that we tend to focus on the 
> solutions more than the problems, and it is true that we look 
> at the loss of a reasonably secured location source as the 
> problem, rather than a symptom.

Nice words for a segway to your next step.

Now, your following words are in the solution space.  Premature to talk
about until consensus on the above.

> 
> That being said, I do think that the advantage of focusing on 
> the location is a more tractable solution because they are 
> always local, whereas the call network is often not.  We can 
> reasonably expect to be able to develop trust relationships 
> between entities that are local to one another more than we 
> can reasonably expect entities that are quite diffuse, and 
> have no other reasons to interact in ways which would allow 
> trust relationships to be formed.
> 
> I also think there is a pretty substantive difference between 
> a lie of the form "I am Joe Blow" and one of the form "I am 
> at 123 Main St".  In the end, we really don't care who you 
> are, and we really do care where you are.
> 
> I do recognize that enterprise is the largest problem for 
> developing trust relationships, because there are so many of 
> them.  This is indeed the challenge.  It's also true that at 
> least for the foreseeable future, there will be many more 
> enterprises with their own location infrastructure than 
> enterprises with their own path to introduce calls to the 
> emergency calling system, rather than using a carrier. 
> 
> I have pointed out before that with a little work, we can 
> exploit an existing "validation" mechanism and extend it to 
> validation of credentials for enterprise.  Every enterprise 
> receives, approximately yearly in most jurisdictions, a 
> physical visit from someone in the public safety community.
> It's a "fire marshal" in the U.S.  They make a physical 
> inspection of the facility.  If, among the fire marshal's 
> duties on such visits, there was a call to a test number from 
> any phone, we could validate credentials.  This level of 
> validation exceeds nearly every form of PKI that has been fielded.
> You have an actual visit by a person to the facility and s/he 
> verifies that the credential's identification information is 
> valid ("Yep, I am in Ajax Manufacturing, and it does report 
> its address as 123 Main St").
> 
> Brian

-Marc-

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 15 Mar 2007 14:50:30 -0400

Brian,

I probably didn't make this clear enough before, but I believe that  
the two assertions (identity and location) are complementary, in  
that, very roughly, in any particular circumstance, one tends to be  
easy and the other harder. I also believe that, together with coarse- 
grain location assertion that does not require cryptography, that  
this offers a mechanism that offers "as good as today" protection,  
which seems to be the rough yard stick of success.

For residential (DSL/cable/FTTH) users, location signing is probably  
workable, as long as the big residential network providers play  
along. I'm not convinced that street-address-level signing is going  
to happen immediately, simply because of the difficulties of  
connecting pieces of equipments, such as DHCP servers and DSLAMs, to  
OA&M systems that know about wire locations. Even if the DSL Forum  
specifies how to do this, equipment won't get replaced overnight and  
OA&M systems seem to be particularly resistant to change, judging  
from the integration difficulties experienced during carrier mergers.  
(Rumor has it that MCI collapsed partially because of these problems,  
once the accounting tricks could no longer mask these failures.) For  
the same residential users, they will likely use commercial VSPs,  
usually within the same country, such as SunRocket and Vonage, as  
well as ISP-provided offerings such as FiOS. Again, identity  
assertion is relatively easy and mostly reliable. The number of  
providers that serve 90%+ of the customers is also modest.

For larger enterprises, the problem is the opposite: identity  
assertion is easy and the enterprise is local to the PSAP, but  
location signing requires all kinds of acrobatics, as other  
mechanisms (such as LLDP-MED) are far more natural than multiple  
identifier mappings and hierarchical trust delegation. Yes, there are  
VPNs, but the number of people placing emergency calls through their  
corporate VPN while using some Sierra Leonian VSP is likely to be so  
small that it can easily be part of the unavoidable "needs special  
care" category. Enterprises also already have TLS certificates or can  
easily get them. No new national PKI needed here.

Also, as I pointed out, location assertion, however good, does not  
prevent or mitigate many of the lone hacker cases that actually  
predominate today.

One thing missing, I think, is an overall "performance" goal.  
Perfection isn't in the cards, and, as with everything, the last 0.1%  
cost the most. I think the goal should be that some large fraction  
(pick 95% or 99% or any other reasonable number) of legitimate calls  
should be recognizable, by either traceable identity or location or  
preferably both. After all, this is what we do today, given that a  
large fraction of cell phones don't have assured fine-grained  
location reaching the PSAP.

As a side note, I would find it extremely useful if NENA could  
provide information on the rough relative frequency of the different  
types of crank calls. Most of this is driven by human behavior (and  
alcohol...), not technology, after all.

Henning

---

From: "Stark, Barbara" <[email-masked]>
Date: Thu, 15 Mar 2007 15:55:19 -0400

Comments inline.
Barbara 

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Wednesday, March 14, 2007 3:09 PM
To: Stark, Barbara
Cc: GEOPRIV; Dawson, Martin; Marc Linsner; Henning Schulzrinne
Subject: Re: [Geopriv] RE: Strawman Proposal

Hi Barbara,

Stark, Barbara wrote:
>> It seems that IMS actually makes that assumption - using the 
>> traditional "roaming partner" model that assumes the voice service 
>> *is* the access service.
>>     
>
> implementing IMS. The view of telcos is that GSM is just another 
> access technology. In this telco view, connectivity to the IMS core 
> will generally occur over the public Internet, and there is absolutely

> no correlation between access provider and IMS provider in that case.
>   
With this view of IMS their emergency service architecture does not
work.

[BHS] Agreed. I don't think telco implementations expect to use the
3GPP-defined emergency service architecture. I think they will use ATIS
to fully define the emergency service architecture, and I think it would
use the work done by NENA and IETF (ecrit and geopriv). That's why it's
important not associate all IMS with 3GPP and GSM. They are NOT
synonymous.

> phone world, it does nothing about people who launch point-to-point 
> SIP calls. Given the architecture we're creating, it will be very 
> simple for someone with a simple SIP client to create a PIDF-LO, do a 
> LoST sos query, and make a call over the Internet to the result of 
> that query, without ever touching a VSP.

[BHS] Sorry I wasn't clear -- I wasn't referring to SIP over cellular
networks. I was referring to SIP phones on generic broadband
connections.

[BHS] Again, I'm referring to generic broadband access networks. My
reading of the state of VoIP today is that there exists a number of
people who want to use SIP as it was originally designed -- a
point-to-point protocol, without all these intermediary softswitches,
feature servers, etc. They can be very vocal when threatened. When it
just takes a uri to get to the PSAP, it will be simple, when connected
to a generic Internet connection, to send a SIP invite directly to the
PSAP, without being registered with any VSP. For an access or backbone
provider to try to prevent this (unless there's a regulatory mandate to
do so) would go completely against all "net neutrality" attempts.

I agree.

[BHS] Unfortunately, it's fairly impossible for the US to create a legal
framework for VSPs in the Bahamas or Nigeria or elsewhere. If we start
requiring trust of VSPs and their processes, then countries will only be
able to trust VSPs that they can regulate, either directly or by treaty.
Which breaks the utopian model that we're aiming for, of anyone from any
country being able to take his phone anywhere in the world and trusting
that it can make an emergency call. I think your email example is
perfect -- considering the volume of spam I get, I'd say it's pretty
easy to set up your own email domain and server and send whatever email
you like.

>  There can be
> fly-by-night VSPs (it's not really that hard to create your own VSP 
> for your own use, and set it up in a hotel room somewhere), and there 
> can be VSPs in countries with lax laws. VSPs, as a generalization, are

> just as trustworthy as end users.
>   
That might be true.

> that are properly "authenticated", would have to only accept calls 
> from VSPs that they know they can trust. Which is a very limiting 

Why do you think it would be better to
* use signed location information (if you also claim that operators
don't want to distribute location information to the end hosts), and
* resolving a location-by-reference is only allowed by authorized
entities

[BHS] I really don't know what the right answer is, or that there's a
single right answer. I think we're going to see a variety of solutions
attempted, in different jurisdictions and different countries. So long
as they don't try to put country specific requirements on the SIP
endpoint, I think that will be ok. We need to make sure the protocols
give the countries the ability to try a variety of solutions, to see
what works best (i.e., don't design the protocol to preclude a potential
solution).

[BHS] Yes, there exist cases where lookup by IP address won't help. It's
just another part of the overall toolkit. The question on the uri, is
how is it formed, in the case of OBO or LIS-LIS (assuming LbyR is used
for these)? The uri is not provided by the end device in these cases --
the uri must use a well-known format that includes the "identity" of the
device whose location is requested. 

[BHS] The LCP must be able to carry a signed PIDF-LO. But the LCP
doesn't have to know that the PIDF-LO it is carrying is signed, or not,
or what the mechanism is for signing. The LCP has to support assertion.
Personally, I'm not sure of the value of having endpoints request
signing. The LIS will know whether local PSAPs require signed location
-- the endpoint will be clueless. A LIS in a PSAP jurisdiction where
signing is required should always sign, according to local rules. A LIS
that doesn't need to sign, probably won't even support the ability. But
I can understand that there may be usefulness in having the request
supported in the LCP, and it's not difficult to do. So I support
providing the ability to request signing.

Ciao
Hannes

> Barbara
>
>
> *****
>
> The information transmitted is intended only for the person or entity
to which it is addressed and may contain confidential, proprietary,
and/or privileged material. Any review, retransmission, dissemination or
other use of, or taking of any action in reliance upon this information
by persons or entities other than the intended recipient is prohibited.
If you received this in error, please contact the sender and delete the
material from all computers. GA622

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA625

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 15 Mar 2007 15:23:18 -0500

The question of liability goes to the regulatory environment of the
jurisdiction. PS-ALI is actually the same - the enterprise is not the
PS-ALI operator and, yet, the PS-ALI operator is who provides the
location information used for the call but they are not subject to
liability.

In practice, the carrier will have a query record associated with the
request - and that will include the specific random client identifier
associated with the request and the time corresponding to the call.
They'll be able to point directly at the source of the location
assertion request and show what their assertion test rules were. It's a
pretty strong non-repudiation arrangement.

I think there are plenty of environments in which transitive trust can
be used without liability being the impediment. Perhaps in others it
can't be. It's just another candidate for dealing with the enterprise
certification issue. I also like your description of how existing
"audit" requirements associated with local emergency authority can
underpin a process that permits enterprises to have their own
certificates.

We've both said in the past that the good thing about location is that
the source of location information, by definition, should be in the
geographical area of concern of the emergency authority that deals with
them. The emergency call center is able to understand what certification
process is applicable in their area. It's even possible, in the US, for
some call centers to understand certificates that are issued and
recognisable at a county level while other PSAPs expect location
providers to carry a nationally recognized certificate.

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Friday, 16 March 2007 5:17 AM
To: Dawson, Martin; 'Ted Hardie'; 'Andrew Newton'
Cc: 'GEOPRIV'; 'Marc Linsner'
Subject: RE: [Geopriv] NENA Requirements

I have pointed out the flaw in the transitive trust model, where the
access
network carrier vouches for the location of one of its customers.  The
problem is liability.  The access carrier gets to take on the liability
of
the information being wrong, and gets no value in return.  It seems so
unlikely to me that we could compel them to do it in a way that makes
their
liability go away.  

Imagine the following: an enterprise has a main campus and a satellite
campus.  It has a T3 or Metro Ethernet service into its main campus, and
it
has a dark fiber between the main campus and the satellite.  Are you
going
to demand that the T3 carrier serving 123 Main St sign a location for
456
Locust?  AT BEST, all the access carrier could do is sign something that
says "I have a customer I know as Ajax Manufacturing, and I serve him at
123
Main Street".  You can't assert that he is actually Ajax, and you sure
won't
sign something that says 456 Locust.

Brian

> ----------------------
> ----------------------

---

From: "Marc Linsner" <[email-masked]>
Date: Thu, 15 Mar 2007 18:09:22 -0400

Barbara,
 
> 
> If PSAPs are permitted to do a LbyR lookup related to the IP 
> address, then the attacker will at least have to be able to 
> pretend to be at that IP address (through something physical 
> at that IP address, or that can intercept all traffic to that 
> IP address, and not simple spoofing). This is definitely a 
> critical capability, though it's not perfect.

The only issue that bothers me with this is tying it to IP address.  It
appears you share some of my concerns with using IP address as an
identifier, nats, vpns, IN-ADDR.ARPA issues, etc.  I had recently proposed
to Brian that the provided-by in the pidf-lo become a LbyR uri.  Something
along the line of pres:[email-masked].  Admittedly, a
pidf-lo that contained such a provided-by uri could be 'stolen' by a bot or
something similar.  But a bot could also launch a sip call setup from an
unsuspecting/infected endpoint.  So regardless if the PSAP use the source IP
address as the identifier or the provided-by LbyR uri, the PSAP *could* be
spoofed.  I don't think attackers have a preferred method, so one provides
no more deterrence than the other.

What if during dereferencing of my proposed LbyR-in-the-provided-by element
the IP address that the LIS knew the end-point residing at was in a NET-LOC
pidf-lo element.  Hence the NET-LOC element would become
<NETLOC>192.168.0.1</NETLOC>.  This would allow the PSAP to trigger one
additional flag, matching source IP with NET-LOC, although nats/vpns could
trigger a false positive.

I think the LbyR-in-the-provided-by element mechanism provides like
functionality with less machinery.

More analysis required.

-Marc-

---

From: Haberler Michael <[email-masked]>
Date: Wed, 14 Mar 2007 07:24:40 +0100

-Michael

---

From: "Raymond Forbes \(CV/ETL\)" <[email-masked]>
Date: Wed, 14 Mar 2007 09:44:52 +0100

Regards,

Ray Forbes
Ericsson Limited

-----Original Message-----
From: Haberler Michael [mailto:[email-masked]] 
Sent: 14 March 2007 06:25
To: Dawson, Martin
Cc: GEOPRIV WG; [email-masked]
Subject: [Ecrit] Re: [Geopriv] RE: Strawman Proposal

-Michael

---

From: "Raymond Forbes \(CV/ETL\)" <[email-masked]>
Date: Wed, 14 Mar 2007 10:21:17 +0100

Hannes,

Currently By analogy with the GSM Regulation, The German and Austrian
Regulators Demand Unauthenticated access on Publicly Licensed networks.
The Private Corporate Networks (CSP IP access; in the IP context) are
not subject to this regulation. 

This will be confusing to the IETF as they do not differentiate between
CSP networks and ISP networks. In their relationship with 3GPP the IETF
considered 3GPP network as Private Enterprise networks. Some Private
Enterprise Networks are nationally Licensed to Sell services to the
Public (T-Mobil-D1 or Vodafone-D2), and subject to regulation [they must
provide unauthenticated access, but authorise its use with IMEIs and
Dummy CLIs; analogous to P_Asserted_Identies in Validated in Proxies],
others Only provide corporate access (Siemens or Ericsson) and have a
closed community and less or no regulation in this context).

Germany and Austria are the only countries that mandate Unauthenticated
Access you may be closer to what their governments are thinking about IP
access

In Other Countries the regulation may be exactly the Opposite un UK,
Eire, Private Enterprise Networks are nationally Licensed to Sell
services to the Public (T-Mobile-UK or Vodafone-UK), and subject to
regulation they must forbid unauthenticated access.

You do not need to consider the case of Corporate CSP access, But
Publicly Incensed Enterprise Networks.

In All cases calls have to be authorised calls to allow traceability.

I am not sure that this helps except to say the technology need to
provide all cases, except unauthorised.

Currently the only Authentication Provide on VoIP Emergency calls is to
the ISP/CSP access using Radius or IPSec.

Regards,

Ray Forbes
Ericsson Limited

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: 14 March 2007 08:55
To: Raymond Forbes (CV/ETL)
Cc: Dawson, Martin; GEOPRIV WG; [email-masked]
Subject: Re: [Ecrit] Re: [Geopriv] RE: Strawman Proposal

Hi Raymond,

one issue that is quite important to me is whether regulators will
demand

* "unauthenticated network access" for emergency calls This means that
an emergency caller can attach to a network even though it does not have
credentials for this network. For example, someone might just use
Ericsson enterprise network (or my private WLAN DSL home
network) for an emergency call.

Ciao
Hannes