Subject: [Geopriv] (dis)connects in the location by reference discussion

From: Andrew Newton <[email-masked]>
Date: Fri, 15 Sep 2006 10:19:50 -0400

Our discussion on location by reference has been revealing in that we have 
found at least one point where we can all agree, and have identified a 
couple of other points that pivot opinions about this subject.  Here is what 
I gather from this discussion:

1) There seems to be near unanimous agreement that bandwidth savings and 
network efficiency are negligible with location by reference. (That's the 
easy one!)

2) In DSL and DSL-like environments, there are in many cases different 
entities running the layer 1 / layer 2 network and the layer 3 network.  As 
an example in my area, the copper lines are run by Verizon but a customer 
may get their IP from Speakeasy, which is literally on the other side of the 
continent.  The relationship between customer, layer 1 operator, and layer 3 
operator are not obvious, making location by reference easier to deploy.

I hope I got that right, because it does raise some questions on my part. 
Mainly, if a layer 3 operator knows enough to know LbyR( customer, layer 1), 
why can it not know enough to do the dereference?

3) Putting aside the various (mis)conceptions about NENA i2, some 
participants are focused on compatibility with NENA i2, while others see the 
mechanisms enabling compatibility with NENA i2 (mainly LbyR) as unnecessary 
complications and risks for per-IP deployments (GEOPRIV/ECRIT).  I'm pretty 
sure that we can all agree that there is no point in purposefully creating 
incompatibility with NENA i2 without good reason.  There are four things 
that would likely help this conversation:

a) Since this isn't a NENA list, not all GEOPRIV participants are familiar 
with NENA i2.  I still do not know what a VPC is.  A pointer to a clear and 
concise description of the NENA i2 architecture for non-NENA folks would be 
greatly beneficial.

b) My limited understanding of the purpose of NENA i2 is that it is an 
architecture designed to allow non-VoIP enabled PSAPS to receive VoIP calls 
  in much the same way they get PSTN calls today (i.e. with LI).  A 
description of how NENA i2 differs with respect to civic location vs. 
geodetic location would be beneficial.

c) Given that my limited understand of NENA i2 (as stated above) is correct, 
perhaps the opponents of LbyR for NENA i2 should attempt to offer an 
alternative that uses LbyV that works with NENA i2.

d) For the proponents of LbyR for NENA i2, it is very important to address 
the security and privacy concern regarding the widespread abuse that are 
possible with the distribution of thousands of PSAP credentials.

-andy

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

---

From: "Dawson, Martin" <[email-masked]>
Date: Fri, 15 Sep 2006 09:53:05 -0500

By way of response, and clarification, to item (d). There will not be
thousands of credentials required for the purpose of de-referencing. I
assume that number is based on the number of PSAPs. PSAPs request
location via a legacy interface through the VPC - E2 in the US, and MLP
in most of the rest of the world though I think Canada may be developing
their own. It is the VPC function that does the de-referencing. Comments
about thousands of certificate holders have been uninformed ones.

The number of VPCs, and certificates required, will be a few.
Potentially, the way the market is looking in the US, it will be two
(2). In other national jurisdictions where the emergency infrastructure
is much more centralized it will likely be one (1).

I think the security and manageability of the de-referencing in the real
world is quite straightforward. Now - a number of submissions on this
list (which I don't agree with) have stated that it's not even necessary
for authentication to occur at de-referencing. That is, the reference
should be treated like the object itself. If the reference is
time-limited such that the LIS expires it as directed by the device
(which I certainly do advocate), then this would certainly make the
LBRsec = LBVsec equation that has been bandied about true. I believe LBR
is actually more privacy-secure than LBV where authentication and
authorization also occurs as part of the de-referencing procedure. I
don't want to let Vonage know my exact location unless they need to
know. I want the emergency network to know - and the access network
already knows. LBR delivers that.

Cheers,
Martin

> -----Original Message-----
> From: Andrew Newton [mailto:[email-masked]]
> Sent: Saturday, 16 September 2006 12:20 AM
> To: 'GEOPRIV'
> Subject: [Geopriv] (dis)connects in the location by reference
discussion
> couple of other points that pivot opinions about this subject.  Here
is
> what
> entities running the layer 1 / layer 2 network and the layer 3
network.
> As
> may get their IP from Speakeasy, which is literally on the other side
of
> the
> continent.  The relationship between customer, layer 1 operator, and
layer
> 3
> Mainly, if a layer 3 operator knows enough to know LbyR( customer,
layer
> 1),
> participants are focused on compatibility with NENA i2, while others
see
> the
> with NENA i2.  I still do not know what a VPC is.  A pointer to a
clear
> and
> concise description of the NENA i2 architecture for non-NENA folks
would
> be

------------------------------------------------------------------------------------------------
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: Henning Schulzrinne <[email-masked]>
Date: Fri, 15 Sep 2006 10:59:12 -0400

> entities running the layer 1 / layer 2 network and the layer 3 network.  
> As an example in my area, the copper lines are run by Verizon but a 
> customer may get their IP from Speakeasy, which is literally on the 
> other side of the continent.  The relationship between customer, layer 1 
> operator, and layer 3 operator are not obvious, making location by 
> reference easier to deploy.
> 
> I hope I got that right, because it does raise some questions on my 
> part. Mainly, if a layer 3 operator knows enough to know LbyR( customer, 
> layer 1), why can it not know enough to do the dereference?

Question: While Speakeasy corporation may be located far away, do they 
run a nationwide DHCP (or RADIUS) server? They presumably also know your 
billing and service address, so I don't see how this has any impact on 
the ease of LbyV or LbyR.

> 
> c) Given that my limited understand of NENA i2 (as stated above) is 
> correct, perhaps the opponents of LbyR for NENA i2 should attempt to 
> offer an alternative that uses LbyV that works with NENA i2.

A trivial alternative is that the "LIS" is operated by the VSP. The data 
in the LIS is maintained by the VSP, based on by-value data provided by 
the end system.

I suspect there are many other solutions, depending on the assumptions 
on the VPC. In particular, in some cases, I can imagine that the 
location dereferencing function disappears altogether, without changing 
the remainder of the architecture. After all, the PSAP does not do an 
IP-deref

The problem with citing the i2 example is that it needs to solve four 
problems:

(1) Current IP phones and ATAs do not include location in their 
signaling messages.

(2) PSAPs can't be modified.

(3) PSAPs need to deal with both traditional and VoIP calls in exactly 
the same manner.

(4) The PSTN side (selective routers and all the rest) can't be modified.

All of these are transient issues, and some of the LbyR motivation is 
primarily driven by (1), not (2) to (4).

Henning

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 15 Sep 2006 11:11:46 -0400

> why can it not know enough to do the dereference?
Agree that there are cases where Layer 1/2 provider is not Layer 3 provider.
In all such cases, there is a substantial contractual and technical
relationship between the providers which would make LbyV practical, but
would require a standardized mechanism by which the L3 provider could
exchange some identifier for the location held by the L1/l2 provider.  For
non-mobile situations, this is a provisioning interface.  For mobile
environments, it's more dynamic.

> concise description of the NENA i2 architecture for non-NENA folks would
The i2 spec can be found at:
http://www.nena9-1-1.org/media/files/NENA_08-001_V1_12-06-05.pdf

A VPC is a VoIP Positioning Center, and is a service provider contracted by
a VSP to provide it 9-1-1 services.  The VPC has connections to the database
the PSAPs make queries to (the ALI).  ALI queries are made with telephone
numbers, and can return a civic or a geo address.  The connection between
the VPC and the ALI database is called "E2" (or another interface, "PAM").

The VPC gets the address and decides which PSAP should get the call.  It
then allocates a phone number to the call that is area code appropriate for
the PSAP.  It can't use the real phone number, because the system does not
accommodate non-local area codes and the caller could be roaming.  These are
generically called "pseudoANIs" (pANIs) or, more specifically for i2,
Emergency Services Query Keys (ESQKs).  The ESQK is associated with a
specific PSAP.  When presented to the 9-1-1 tandem ("Selective Router"),
that number will cause the call to be routed to the right PSAP.

The VPC saves the location.  When the PSAP queries ALI with the ANI it gets
on the call (which in this case would be the ESQK the VPC allocated for it),
the query is "steered" to the VPC that owns it over the E2 interface.  When
the VPC gets the query, it responds with the location of the caller.  This
may be a civic or a geo.

The PSAP may repeat the same query, the same path will be followed, and the
VPC should send an updated location.

> geodetic location would be beneficial.
Yes, the dominating requirement that drove i2 was nothing in the PSAP could
be changed.  It adapts VoIP to existing systems.  Roughly, i2 uses the same
mechanism as wireless does (wireless has an "MPC" = Mobile Positioning
Centers, that allocated ESRKs (which are also pANIs), ...

There is no difference in how i2 handles geo or civic.  All the interfaces
accept either. 

> correct,
I did so.  Send LbyV the way it's defined now.  VPC gets the location, when
it wants an update, it sends a ReINVITE to get another.

> possible with the distribution of thousands of PSAP credentials.
NENA i2 has a CA called "VESA".  VESA is supposed to issue credentials to
PSAPs, VPCs, VSPs and gateway (ESGW) providers.  NENA was supposed to
contract to get the VESA going.  It is practical to create a PKI here:
NENA has a registry of PSAPs which can be a reasonable source of
verification information on PSAPs.  If it's not in NENA's registry, they
will have to go through the process to get in it.  There are other, very
practical ways of verifying that a PSAP is bona fide, because they are
government agencies.  There are a small number of VPCs, and VESA can
reasonably do a verification of bona fides for them.  Then the PSAPs can
provide authorization for access networks (LIS operators), and the VPCs can
provide authorization for VSPs.  It scales acceptably to do that.

My company has looked at the practicality of providing the CA service, and
what an acceptable CP/CPS for it would be.  We think it's reasonable.

Brian

Brian

---

From: Michael Haberler <[email-masked]>
Date: Fri, 15 Sep 2006 18:23:14 +0200

Henning Schulzrinne schrieb:
> A trivial alternative is that the "LIS" is operated by the VSP. The
> data in the LIS is maintained by the VSP, based on by-value data
> provided by the end system.
that is not good enough in the general case - the VSP cannot reliably
detect location without the L1/2 operator

not just a conjecture, I checked that already over here: this approach
would not get regulatory OK in Austria for using geographic numbers

This is however  a key reason why VSP's want exact location since that
has substantial business impact

-Michael
> location dereferencing function disappears altogether, without
> changing the remainder of the architecture. After all, the PSAP does
> not do an IP-deref
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 15 Sep 2006 13:33:38 -0400

> detect location without the L1/2 operator

I'm well aware of that fact. The mechanism is simple, but different from 
what you posit. In more detail:

- End system obtains location information in whatever way suits it, from 
the L1/2 operator.

- End system inserts location via SIP conveyance, by value.

- Call reaches VSP.

- VSP inserts location information, extracted from SIP message, into the 
LIS it operates.

- VCP contacts the VSP-operated LIS.

If the VCP and proxy are the same, they can obviously skip the last two 
steps.

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 15 Sep 2006 16:51:00 -0500

I don't agree with point 2, I will offer on this in a later email.

A VPC is like a centralized LoST server. Given a location it will find a
route to a PSAP. This route is made up of two numbers, one to get you to
a gateway (ESGW), and one to take you from the gateway through the ISUP
network to the selective router (class 5 switch) to the PSAP. This
second number is also used by the PSAP to query back through the ALI
network to get location from the VPC.

Trunks from the ESGW will more than likely run directly to the SR.
The i2 Architecture uses a PIDF-LO, or a reference to a LIS that can
provide a PIDF-LO.

Andy point d, seems to be where the primary misunderstanding with
regards to i2 comes into play. There quite simply aren't thousands of
VPCs, there will be maybe 10. PSAPs can only query the network through
the VPC. Are the opponents to LbR suggesting that certificates in the
order of 10's cannot be managed?

Have a good weekend all

James

discussion
is
network.
of
layer
> I hope I got that right, because it does raise some questions on my
part.
layer
see
clear
would

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 15 Sep 2006 18:01:38 -0400

> order of 10's cannot be managed?

The scaling issue was in the context of i3, not i2. Personally, I find 
an architecture where the 911 system of the whole US depends on O(10) 
sites a bit scary, as unavoidable as it may be for i2. In the i3 
context, there is no reason for such a concentration of functionality 
into a few sites.

As part of the requirements discussion, we had a fairly long discussion 
on the basic issue that we want things to continue to work as long as 
there's a direct IP path between caller and PSAP. LoST, in particular, 
is designed to make this reasonably easy, so that you can imagine 
operating in a scenario where the PSAP is connected to the DSL provider 
and 911 service continues to operate even if the rest of the Internet 
connectivity is completely unavailable or severely stressed.

Henning

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 15 Sep 2006 18:04:09 -0400

> order of 10's cannot be managed?
In i2, the VPCs, the VSPs and the LIS's need certs to meet the basic i2
requirements.

There are thousands of access networks.  There are hundreds of VSPs.  Are
you suggesting that the LIS can use any cert it would like, and we would
have a secure authentication system?

Whatever you do, you want to smoothly migrate to i3.  There, the PSAP does
query directly.  So, the solution has to scale to thousands of PSAPs.

Brian

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 15 Sep 2006 17:06:38 -0500

So you are saying that the PSAP based in NJ, can connect to the ISP in
Ca, but the VPC can't? That doesn't make a whole lot of sense. Remember
that in DSL there are multiple parties, and that the PSAP will only know
about the layer3 and above provider.

I guess I just don't buy this argument at all.

Cheers
James

> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Saturday, 16 September 2006 8:02 AM
> To: Winterbottom, James
> Cc: Andrew Newton; GEOPRIV
> Subject: Re: [Geopriv] (dis)connects in the location by reference
> discussion
> 
> >

---

From: Michael Haberler <[email-masked]>
Date: Sat, 16 Sep 2006 00:08:35 +0200

Henning Schulzrinne schrieb:
> I'm well aware of that fact. The mechanism is simple, but different
> from what you posit. In more detail:
>
> - End system obtains location information in whatever way suits it,
> from the L1/2 operator.
I think this would not work for L7 LCP in general - the L1/2 operator
(aka 'RANP' in i2) might not be able to key location on IP address (the
ISP can if he queries the RANP LIS). See for instance figure 8.5 L2TP
access segment scenario in the current 'NENA VoIP  Recommended Method(s)
for Determining Location to Support Emergency Calling Technical
Information Document (TID)' where the RANP LIS is agnostic WRT end
system IP address.

For that to work the end system would need to query the ISP LIS.
> - VSP inserts location information, extracted from SIP message, into
> the LIS it operates.
just pointing out that now we would have two servers holding location
for the same end system (ISP LIS, VSP LIS) conveyed through the end
system between them.

-Michael
> If the VCP and proxy are the same, they can obviously skip the last
> two steps.
>
>
>>

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 15 Sep 2006 18:19:13 -0400

I'm afraid I don't understand your paragraph. With 10 VPCs across the 
US, the VPC serving NJ would most likely be in some neighboring state. 
Thus, if long-distance connectivity is impaired, the emergency call fails.

A local PSAP could simply connect directly to the nearest cable headend 
and DSL DSLAM - after all, it's likely in the same community. (As for 
most towns in Bergen County, next to NYC, our PSAP is within a mile or 
two of most residences.)

For emergency calls, I don't need a VSP, just my local cable or DSL 
headend or DSLAM (and associated IP equipment).

Requiring national infrastructure to be up to place a local phone call 
is not a great design, in my book. As some people like to say, we 
shouldn't do worse than the old system.

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 15 Sep 2006 18:22:00 -0400

> Information Document (TID)' where the RANP LIS is agnostic WRT end

If this is a problem, it is independent of architecture and LbyR/V. I 
assume you have read the L7 document, which talks about the various 
identifiers and their trade-offs. Are you disagreeing with those 
conclusions? Are you proposing a different end system identifier as more 
suitable?

---

From: Michael Haberler <[email-masked]>
Date: Sat, 16 Sep 2006 00:39:12 +0200

Henning Schulzrinne schrieb:
> conclusions? Are you proposing a different end system identifier as
> more suitable?
You are right - this is independent of LbyR vs V.

All I said that your flow queries the wrong server in step 1 - at least
in the scenario I mentioned.

Other than that, I just feel conveying location from server2 (learned by
help of server1) through the device to server3 where it is queried by
server4 fails the Occam's razor test for me from an architecture pov,
whoever's fault that is.

wrt identifiers - I am not proposing a different one, however I would
like to see a l7 protocol which can deal with a multivariate key type,
not just IP address, so we dont have to turn around and reinvent when
some other identifier appears desirable - possibly for a completely
different application than 911.

-Michael

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 15 Sep 2006 20:31:37 -0400

> server4 fails the Occam's razor test for me from an architecture pov,

I agree. That's why I prefer that the device queries the location (if  
it doesn't have it already), and nobody else does.

By either LbyR or LByV, the device queries (and gets back a V or R),  
just that the reference needs to be resolved in a later step. Thus,  
the total number of steps in LbyR is always LByV + 1 (for the single  
reference case in routing).

> different application than 911.

Indeed. Some of the proposed L7 protocols incorporate the ability to  
resolve other identifiers, beyond IP addresses.

---

From: "Dawson, Martin" <[email-masked]>
Date: Fri, 15 Sep 2006 20:08:54 -0500

Henning - do you really think that the number of certificates issued
equates directly to the number of sites?

> Cc: GEOPRIV; Andrew Newton

---

From: "Dawson, Martin" <[email-masked]>
Date: Fri, 15 Sep 2006 20:14:23 -0500

I assume you'll want to request updates directly from the terminal in
i3. Shouldn't you get on with specifying a protocol for that? (just
saying sub/not is barely a start).

Cheers,
Martin

> From: Brian Rosen [mailto:[email-masked]]
> Sent: Saturday, 16 September 2006 8:04 AM
> To: Winterbottom, James; 'Andrew Newton'; 'GEOPRIV'
> Subject: RE: [Geopriv] (dis)connects in the location by reference
> discussion
>

---

From: "Dawson, Martin" <[email-masked]>
Date: Fri, 15 Sep 2006 20:17:41 -0500

Yippee - we're going to have dedicated IP trunks for emergency services
just like we did for local exchanges.

> Sent: Saturday, 16 September 2006 8:19 AM
> To: Winterbottom, James