Re: [Ecrit] Location hiding: Consensus?

[Richard Barnes <rbarnes at bbn.com>]

Andy,

I think you're right that we're disagreeing about requirements.  With 
that in mind, here's another shot at requirements (below, and on the 
wiki page).  I think there's pretty broad consensus on the Required 
Components and Requirements.  But differences remaining on the Possible 
Requirements, and each of those could disqualify one or more solutions.

--Richard

Required components:
1. A mechanism to deliver to endpoints, at any time,
   1. All emergency dial strings for their location
   2. PSAP URIs (matched to service URNs) for all services available at 
their location
2. A mechanism to deliver endpoint location to PSAPs/emergency responders.
3. A mechanism by which a VSP can learn whether a URI is a PSAP URI

Requirements:
1. MUST NOT require the ISP to give precise location to the endpoint.
2. MUST NOT require the ISP to give rough location to an unauthorized party.
3. A party in possession of a URL MAY be considered authorized. However, 
in this case,
   1. The solution MUST specify which URLs are required to have this 
property, and
   2. URLs MUST have a cryptographically random component with a 
specified minimum size
4. MUST NOT require a business/trust relationship between ISP and VSP
5. MUST NOT require a business/trust relationship between VSP and PSAPs
6. MAY require a business/trust relationship between ISP and PSAPs
7. MUST NOT require any particular structure for the emergency response 
network
8. MUST NOT require any particular geometric propertise of PSAP boundaries

Possible requirements
1. MUST NOT require the ISP to give location of any granularity to the 
endpoint
2. MUST NOT require the use of a particular LoST resolver by the endpoint

Desiderata:
1. Minimal effect on call setup latency
2. Minimal changes from existing protocols & architectures
3. Minimal difference between provisioning by-value and by-reference
4. Minimal changes to UA configuration mechanisms
5. Maintain separation of protocols for location configuration and mapping
6. Independence of protocol used by the UA for calling / session 
establishment



Andrew Newton wrote:
> On May 10, 2007, at 4:22 PM, Matt Lepinski wrote:
> > 1) I believe James began by stating that there are business 
> > requirements for location hiding, and that these are real 
> > requirements. I believe everyone participating in this thread agrees 
> > on that point. (Ignoring any value judgement about whether these 
> > requirements are good or evil)
>
> Well, I thought Henning disagreed with there being real business 
> requirements.
>
> > 2) James seems to believe that providing "fuzzed" location to the 
> > end-point is a bad idea. This would seem to be a fundamental source of 
> > disagreement with Henning who has supported sending "fuzzed" location 
> > to the end-point.
> >
> > Henning's argument seems to be that PSAP URI is already a form of 
> > "fuzzed" location that we're already providing, and James seems to be 
> > concerned with the access network provider being held accountable for 
> > providing "low quality" location.
>
> I am not a particular fan of fuzzing either.  We've got little 
> deployment experience with this architecture and who knows what trouble 
> this will invite.
>
> And fuzzing adds fuel to the fire for those that say VoIP 9-1-1 doesn't 
> work or is not reliable.
>
> > Is this understanding correct?
> >
> > 3)The whole business relationships argument is especially confusing to 
> > me since it seems that both Henning and James agree that ISPs should 
> > not be required to have business relationships with VSPs. (I don't 
> > think I've heard anyone in this thread argue against that basic point).
> >
> > It is reasonable to say that a particular proposal is bad because it 
> > would require contractual relationships between ISPs and VSPs, but so 
> > far I don't think I've heard James argue in support of any particular 
> > proposal.
>
> I thought James was an advocate of #3.
>
> What we seem to have an issue with is the agreement on the requirements, 
> and this is causing people not to agree on a solution.
>
> -andy
>
>
>
> _______________________________________________
> Ecrit mailing list
> Ecrit at ietf.org
> https://www1.ietf.org/mailman/listinfo/ecrit



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