Re: [Ecrit] Discussion on draft-winterbottom-ecrit-priv-loc-04

["Rosen, Brian" <[e-mail]>]

Getting a bit deep, but I’ll keep playing along.

\LbyR in LoST allows the VSP to acquire an endpoint location reference and
obtain routing information to the correct ESRP.  It does¹t require a trust
relationship between the LS and the VSP.
[AJW] Huh??  Which LoST server does the VSP contact in your scenario? The ANP won’t have put any record into the DNS for its domain and even if it did that domain span several geographic areas LbyR in LoST can’t recurse or redirect.. BREAK.. The only way that it could work would require the ANP to establish its own LoST server and simply spit back the records from the LS anyway. Why is this being made as two queries again?

<br>The VSP contacts any LoST server.  Using recursion or iteration, it gets to the authoritative one.  If LoST does LbyR, then the VSP gets an LbyR by querying the LS.  It then queries any LoST server to get route.
[AJW] FAIL… How does the LoST server know where to go? It only has a location URI and doesn’t have permission to dereference it so it can’t determine where the authoritative server is using either recursion or redirect. The model is broken.
This is the fundamental way LoST works.  The LbyR has to return something (country is okay), if the result is within it’s authoritative area, it can return the response.  If not, it has a path to get resolution (up it’s local tree, across the forest via FG, down the authoritative tree.

You remind me of arguments against DNS.  DNS does work right?  You have heard all the “security in obscurity” stuff about knowing IP addresses of various things, right?  For those who still have these fears, they have external resolution trees that have public addresses so the query can get to something that gives them an externally accessible address.  This is directly analogous to how that’s done.




LoST using LbyR would work just fine with forest guides.  The forest guide
would have to accept LbyR, but since it uses LoST as its interface, no
problem if that¹s the way we decide to do it.
[AJW] This means that any forest guide anywhere in the world is allowed to get location from any LS in the world using an LbyR. This has huge security and privacy implications apart from the fact imposing certain constraints in countries that may well not want or need these constraints.
The problem with deciding to it that was is that you will end up in the same position as with rough location after 2 years of debate, by which time an alternative will have been found an used.
<br>Spare me the polemics.  Yes, the route infrastructure has to be trusted.  The LS can return something appropriately rough, with no standardization, to an FG or a LoST server it doesn’t recognize, if it wants to.  Any point in the country, for example.  Recursion would probably be required if everyone was paranoid about location.  Note that the VSP can figure out location to a country with the route URI, no leakage there.
[AJW] So you are re-advocating rough location? Hmm.. I though that that option was just dropped. This doesn’t provide the same benefits at all of what is in the draft I proposed. The proposal in the draft only requires the ANP, PSAP or entities inside the emergency network to have access to location values. Requiring a global route server network to have access to this is simply not join to meet the security/privacy requirements in some countries.
Rough location was dropped because we could not come up with an algorithm to return a rough location that would not leak actual location.  Here, we’re only trying to get to the authoritative FG, and country is okay.  That leaks information, but country is readily determined by existing methods.  If nothing else, domain of route would provide such information.





You need an authoritative route server that accepts geo and civic
addresses and returns SIP URIs.  If your interface to that server isn¹t
LoST, it has to be something that duplicates it pretty closely.
[AJW] No, we don’t really need that. In the US you have highly-structured civic addresses, for most of the rest of the world they don’t. In countries like German, ESRP addresses will be based on who the ANP is, not necessarily the area served by the ANP. In the mobile case, point of attachment is good enough usually to get to the ESRP, again, I don’t need a complex route server, just a table.
<br>In the US, like most places, you route by cell and sector, but the way that is mechanized is the cell and sector is turned into some kind of location – a civic or a geo.  The LoST database can be a simple table if you only have a small range of addresses.  We’re discussing the protocol, not the complexity of the data.
[AJW] You conflating the route issue and the location display issue. I don’t need to turn the cell-id to location at routing time, the route was predetermined. I only need a table, this cell-id maps to this URI. Whether the PSAP gets the cell-id and then converts that into a area to display, or it gets an area from the GMLC is immaterial. I only need a table for routing.
No.  The ROUTE is determined by looking up a cell-associated location in a location database.  The location is selected so that it is within the service area of the PSAP that serves it.  In some systems, the route query is done in advance of the call, but in others, it’s done at call time.



I’ll agree that if the VSP has the entire route table for all the jurisdictions it operates in, then it doesn’t need LoST for query and could use something proprietary.  Not sure what will happen in 3GPP, which is taking that approach.  I think that is a big mistake, but you still need a protocol that is queried with location and delivers URI.

Civic addresses validation can change, and the fact that we don¹t have a
way to push a change from the validation server back to the entity that
validated is a problem.  -planned-changes addresses that.  Of course, you
are only discussing civic addresses (geos don¹t get validated), so using
the validation query to obtain route doesn¹t work with geos.
[AJW] The route is no more static in the proposal I have made than it would using forest guides or ached data sets.
<br>If you accept the binding time as the validation period, okay, but I don’t think that is what you meant.

[AJW] You are right, I didn’t. But in most cases the kind of catastrophe you describe can and will be done using a different approach.
In emergency calling “most” is a word we use to describe optimization.  We don’t design systems that literally fail a small percentage of the time.  Static routes fail often enough in the real world that you should not depend on the ability to manipulate the destination of the static route.  Failure here is not misroute, it’s failure to be able to get to someone that can help.




None of this changes anything.  LoST LbyR is as least as good of a
solution as HELD-returns-route.  HELD-returns-route has to have the TTL,
the boundary, and the other LoST return things to be useful.

[AJW] See above, I have still not heard from anyone how the will work despite having asked a number of times.

[AJW] Question still answered, I provided the failure in LbyR for LoST and it has not been addressed.
Don’t agree.  See above.