Re: [Geopriv] Review of draft-ietf-geopriv-l7-lcp-ps-00

From: Hannes Tschofenig ^lt;Hannes.Tschofenig@gmx.net>
Date: Sat Feb 10 2007 - 15:14:42 EST

Hi Otmar,
Hi all,

Please find my response below:

Otmar Lendl wrote:
> Hannes,
>
> On 2007/02/08 23:02, Hannes Tschofenig <Hannes.Tschofenig@gmx.net> wrote:
>
>> Otmar Lendl wrote:
>>
>>> I could not find a definition of "Location Configuration Protocol (LCP)"
>>> in the referenced ([2] and [3]) documents. Google seems to indicate that
>>> the term appeared in draft-linsner-geopriv-lcp-01, but that document is
>>> not referenced. Is this a "Sighting" protocol according to RFC3693?
>>>
>>>
>> You are asking tough questions.
>>
>
> That's what last calls are for, aren't they?
>
>
>> I had some problems with the terminology used in RFC 3693.
>>
>
> I'm not particular fond of it either. It's just that you reference 3693
> in section 2. A quick recap of the few terms you really need in that
> section could help the readability.
>
>
Maybe I should just put some terminology there regardless whether it
reflects RFC 3693 or not.

>>> I'm missing a clear definition who will talk this "LCP" protocol. Per that
>>> abstract it's the "end host". Is this the "Target" according to RFC3693?
>>> Will there be LIS-LIS communication also using that LCP?
>>>
>>>
>> The LCP protocol runs between the LCP client and the LCP server. For our
>> investigations the Target played the role of the LCP client.
>> We didn't really investigate the "on-behalf-of" mode where an entity
>> other than the LCP client fetches the location information of the Target.
>>
>
> IMnsHO we need that for the DSL resale scenario which according to
> some estimates make up 10 to 30 % of the european broadband deployments.
>
>
That was a big problem with the work on this subject in the past. An
incomplete requirements list was presented and later, when proposals
were made some folks claim that it does not fulfill all the requirements
pointing to new topics.

>>> Section 4 talks about LIS discovery. Is this document also
>>> supposed to define the requirements for that?
>>>
>>>
>> I can only come with an obvious requirement, such as
>> "
>> The solution MUST define a discovery mechanism that is robust against
>> the security attacks listed in Section XYZ.
>> "
>>
>> The LIS discovery was a hot topic in the design team work since it is
>> rather difficult also from a security point of view.
>>
>
> The discovery algorithm is independent of the LCP, thus maybe we should
> treat these two problems as separate work-packages and thus separate
> drafts?
>
Maybe.

>
>>>> 4. Discovery of the Location Information Server
>>>>
>>> Where does this section fit in? Is this just informational? I neither see
>>> clear requirements nor a specific solution.
>>>
>>>
>> This is trying to capture design team discussions. I can move it to a
>> later section in the draft.
>>
>
> See above. I recommend to declare the discovery out-of-scope for this
> documents. It just distracts.
>
>

>>>> Security properties of the identifier:
>>>>
>>>> Misuse needs to be minimized whereby off-path adversary MUST NOT
>>>> be able to obtain location information of other hosts. A on-path
>>>> adversary in the same subnet SHOULD NOT be able to spoof the
>>>> identifier of another host in the same subnet.
>>>>
>>>>
>>> Basing the security only on the identifier is a bit short-sighted.
>>> This rules out any approach which handles security by any other means.
>>>
>>>
>>>
>> The security of the entire protocol is not only based on the identifier
>> but the identifier needs to have some security properties as well.
>>
>
> Correct. But once you take LIS-LIS use-cases into account, then
> the security background changes in a fundamental way and some
> identifiers which are unsuitable for Target-LIS communication
> are now perfect for LIS-LIS interactions.
>

I fully agree that the LIS-LIS (or "on-behalf-of" use case) has very
different security characteristics.

>
>>>> IP Address:
>>>>
>>>> The end host's IP address may be used for location determination.
>>>> This IP address is not visible to the LIS if the end host is
>>>> behind one or multipel NATs. This is, however, not a problem
>>>> since the location of a host that is located behind a NAT cannot
>>>> be determined by the access network. The LIS would in this case
>>>> only see the public IP address of the NAT binding allocated by the
>>>> NAT, which is the correct behavior.
>>>>
>>>>
>>> This is *not* a-priori OK. In that case the LIS will determine the
>>> location of the NAT device and not of the end-system.
>>>
>>>
>> That's OK. There is no way todo better than that unless the NAT device
>> also participates in the exchange which is not what the folks proposing
>> the Geopriv L7 LCP solution had in mind.
>>
>
> I agree, but that limitation needs to be documented.
>
>
I did that in the " IP Address:" paragraph of Section 5.

>> I thought that a discussion about the properties of the IP address is
>> quite useful
>>
>
> ... if you qualify it with "end-host - LIS" use-case.
>
>
That's the only use case we considered, if you refer to the
"on-behalf-of" use case.

>>>> Requirement L7-4: Layer 2 and Layer 3 Provider Relationship
>>>>
>>>> The design of the GEOPRIV Layer 7 Location Configuration Protocol
>>>> MUST assume that there is a trust and business relationship
>>>> between the L2 and the L3 provider. The L3 provider operates the
>>>> LIS and needs to obtain location information from the L2 provider
>>>> since this one is closest to the end host. If the L2 and L3
>>>> provider for the same host are different entities, they cooperate
>>>> for the purposes needed to determine end system locations.
>>>>
>>>>
>>> This addresses the DSL wholesale scenario.
>>>
>>> e.g. Telekom Austria forwards a DSL customer's connection to eTel as
>>> a L2TP session to be terminated within the eTel network. I guess that
>>> Telekom Austria is the L2 provider, and eTel the L3 provider.
>>>
>>> The LIS for the customer will be run by eTel, but they need some interface
>>> >from Telekom Austria to learn where this particular L2TP stream
>>> originates.
>>>
>>> It is my recommendation that this interface utilizes the same
>>> LCP protocol, but uses different "identifiers" and security procedures.
>>>
>>> Leaving this issue open ("they need to cooperate somehow") is not doing
>>> us a favor here.
>>>
>> Could you provide some text about what you want?
>>
>
> The various wholesale scenarios are documented in section 8 of
> http://www.nena.org/media/files/08-505_20061221.pdf
>
> I just boils down to the fact that the LCP needs to work in
> a LIS-LIS setting as well. Then we have an "on behalf of" lookup
> using different identifiers as the key to location.
>
> Is there agreement in this WG that we need to address wholesale
> scenarios, including LIS-LIS communication (the "they need to
> cooperate somehow" bit from the draft) ?
>
> I certainly think we need to.
>
>

Since this requirement was never proposed within the design team there
was no chance to reach a conclusion on it.

Ciao
Hannes

> /ol
>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Sat, 10 Feb 2007 21:14:42 +0100

This archive was generated by hypermail 2.1.8 : Sat Feb 10 2007 - 15:14:41 EST