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

From: Richard Barnes ^lt;rbarnes@bbn.com>
Date: Thu Feb 08 2007 - 21:09:02 EST

Hannes,

The WGLC inspired me to take a more thorough look at this document. :)

I'll send more detailed comments later, but my overall impression is
that this document is trying to do too much stuff:
1. State the L7LCP problem and requirements [e.g. Sec 1, 9]
2. Discuss possible solutions [interspersed throughout]
3. Propose new GEOPRIV threats (beyond RFC 3694) [e.g., Sec 8.1, 10.1]
4. Propose a GEOPRIV security architecture [e.g., Sec 8.2, 10.2]

I think this confusion makes the document really hard to read, as
Ottmar's comments suggest. Has there been any though of trying to tease
these parts out into separate documents?

Cheers,
--Richard

Hannes Tschofenig wrote:
> Hi Otmar,
>
> thanks a lot for your review. Please find my response below:
>
> Otmar Lendl wrote:
>> Here are my comment to draft-ietf-geopriv-l7-lcp-ps-00. I skipped the
>> security and VPN stuff, and will focus on other aspects instead.
>>
>>
>>> Abstract
>>>
>>> This document provides a problem statement, lists requirements and
>>> captures discussions for a GEOPRIV Layer 7 Location Configuration
>>> Protocol (LCP). This protocol aims to allow an end host to obtain
>>> location information, by value or by reference, from a Location
>>> Information Server (LIS) that is located in the access network. The
>>> obtained location information can then be used for a variety of
>>> different protocols and purposes. For example, it can be used as
>>> input to the Location-to-Service Translation Protocol (LoST) or to
>>> convey location within SIP to other entities.
>>>
>>
>> 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.
>
>
> I had some problems with the terminology used in RFC 3693.
>
> For example, one could discuss what the "non-public information" means
> in this context:
>
> "
> Sighting: The initial determination of location based on non-public
> information (as discussed in the definition of Location Information),
> and the initial creation of Location Information.
> "
>
> The reason for us using the title as indicated was that this was the
> name of the design team, as set by the working group chairs.
>
>
>> The term "Location Information Server (LIS)" is used. Is this identical
>> to RFC3693's "Location Server (LS)"?
>>
>
> We had a long discussion about the relationship between the term "LS"
> and the term "LIS". See here:
> http://zeke.ecotroph.net/pipermail/geopriv_lbyr_dt/2006-November/000038.html
>
>
>
> Unfortunately, I don't recall that there was a consensus.
>
>> 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.
>
>> 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.
>
>
>
>>
>>> 3. Scenarios
>>>
>>> The following network types are within scope:
>>>
>>
>> I expected some examples of networks which are not in scope here
>> as well. VPNs are mentioned explicitly later in the draft. Are they
>> in scope or not?
>>
>>
>
> Solutions need to consider VPNs.
>
>
> Actually, we want to have the solution to work everywhere. Hence, we
> couldn't exclude networks.
>
>> [...]
>>
>>
>>> It is possible for the NTE and the home router to physically be in
>>> the same box, or for there to be no home router, or for the NTE and
>>> end host to be in the same physical box (with no home router). An
>>>
>>
>> That sentence is a bit awkward.
>>
>>
>>> example of this last case is where Ethernet service is delivered to
>>> customers' homes, and the Ethernet NIC in their PC serves as the NTE.
>>>
>>> Current Customer Premises Network (CPN) deployments frequently show
>>> the following characteristics:
>>>
>>
>> It is not immediately clear whether this is a list is to be read as
>> "and" or "or". What about "... frequently fall in either one of these
>> two categories:"?
>>
>>
>>> 1. CPE = Single PC
>>>
>>
>>
>>> 2. One or more hosts with at least one router [DHCP Client or PPPoE,
>>> DHCP server in router; VoIP can be soft client on PC, stand-alone
>>> VoIP device, or Analog Terminal Adaptor (ATA) function embedded
>>> in router]
>>>
>>
>>
>>> 3.3. Wireless Access
>>>
>>> Figure 3 shows a wireless access network where a moving end host
>>> obtains location information or references to location information
>>> from the LIS. The access equipment us, in many cases, link layer
>>> devices. This figure represents a hotspot network found in hotels,
>>> airports, coffee shops.
>>>
>>>
>>>
>>> +--------------------------+
>>> | Access Network Provider |
>>> | |
>>> | +----------+|
>>> | +-------| LIS ||
>>> | | | ||
>>> | +--------+ +----------+|
>>> | | Access | |
>>> | | Point | |
>>> | +--------+ |
>>> | | |
>>> +------+-------------------+
>>> |
>>> +------+
>>> | End |
>>> | Host |
>>> +------+
>>>
>>> Figure 3: Wireless Access Scenario
>>>
>>
>> That's too simple. Larger WiFi installations use multiple access
>> points (all with the same SSID). The client will connect to the
>> nearest one, if he moves there will be hand-offs to other APs.
>> Is this supposed to be handled like 3.2?
>>
>>
> For editorial reasons I wanted to keep it as simple as possible.
> I know that a larger WLAN, including the IETF meeting network, has more
> than one access point.
>
>>> 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.
>
>>
>>> When an end host wants to retrieve location information from the LIS
>>> it first needs to discover it. Based on the problem statement of
>>>
>>
>> "discover it"? It needs to learn a way how to contact it.
>>
>>
> Fine for me.
>
>>
>>> determining the location of the end host, which is known best by
>>> entities close to the end host itself, we assume that the LIS is
>>> located in the access network. Several procedures have been
>>> investigated that aim to discovery the LIS in such an access network.
>>>
>>>
>>
>>
>>> The LIS discovery procedure raises deployment and security issues.
>>>
>>
>> Are these to points part of the official requirements of the LCP?
>> Some generic comments?
>>
>>
> I should remove this sentence.
>
>
>
>>> When an end host discovers a LIS,
>>>
>>> 1. it does not talk to a man-in-the-middle adversary, and
>>>
>>
>> something is missing in this sentence.
>>
>>
>>> 2. it needs to ensure that the discovered entity is indeed an
>>> authorized LIS.
>>>
>>
>>
>>
>>> 5. Identifier for Location Determination
>>>
>>
>> Now we're jumping back to the LCP.
>>
>>
>>> The LIS returns location information to the end host when it receives
>>> a request. Some form of identifier is therefore needed to allow the
>>> LIS to determine the current location of the target or a good
>>> approximation of it.
>>>
>>>
>>
>> Ok, so this identifier is the primary key with the LIS will use
>> to do it's magic. ok:
>>
>>
> Yes.
>
>>
>>> The chosen identifier needs to have the following properties:
>>>
>>> Ability for end host to learn or know the identifier:
>>>
>>> The end host MUST know or MUST be able to learn the identifier
>>> (explicitly or implicitly) in order to send it to the LIS.
>>> Implicitly refers to the situation where a device along the path
>>> between the end host and the LIS modifies the identifier, as it is
>>> done by a NAT when an IP address based identifier is used.
>>>
>>>
>>> Ability to use the identifier for location determination:
>>>
>>> The LIS MUST be able to use the identifier (directly or
>>> indirectly) for location determination. Indirectly refers to the
>>> case where the LIS uses other identifiers locally within the
>>> access network, in addition to the one provided by the end host,
>>> for location determination.
>>>
>>>
>>> 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.
>
>
>>
>>> The problem is further complicated by the requirement that the end
>>> host should not be aware of the network topology and the LIS must be
>>>
>>
>> should not need to be aware ..
>>
>>
> OK
>
>>
>>> placed in such a way that it can determine location information with
>>> the available information. As shown in Figure 1 the host behind the
>>> NTE/NAPT-DHCP device is not visible to the access network and the LIS
>>> itself. In the DSL network environment some identifier used at the
>>> NTE is observable for by the LIS/access network.
>>>
>> ~~~~~~
>>
>>
>>> The following list discusses frequently mentioned identifiers and
>>> their properties:
>>>
>>>
>>
>> It is not clear how the end system communicates that identifier to the
>> LIS.
>>
>>
> Which one? The MAC address?
> Within the payload of the message.
>
>>
>>> Host MAC address:
>>>
>>> The host MAC address is known to the end system, but not carried
>>> over an IP hop.
>>>
>>>
>>
>> e.g. sending the MAC address in the LCP request is trivial (it just fails
>> the criteria 2 and 3 from above).
>>
>>
> Generally speaking you are certainly right.
>
>
>>> ATM VCI/VPI:
>>>
>>> The VPI/VCI is generally only seen by the DSL modem. Almost all
>>> routers in the US use 1 of 2 VPI/VCI value pairs: 0/35 and 8/35.
>>> This VC is terminated at the DSLAM, which uses a different VPI/VCI
>>> (per end customer) to connect to the ATM switch. Only the network
>>> provider is able to map VPI/VCI values through its network. With
>>> the arrival of VDSL, ATM will slowly be phased out in favor of
>>> Ethernet.
>>>
>>>
>>
>> I'll come back to that later.
>>
>>
>>> Cryptographically Generated Address (CGA):
>>>
>>> The concept of a Cryptographically Generated Address (CGA) was
>>> introduced by [8]. The basic idea is to put the truncated hash of
>>> a public key into the interface identifier part of an IPv6
>>> address. In addition to the properties of an IP address it allows
>>> a proof of ownership. Hence, a return routability check can be
>>> omitted.
>>>
>>
>> I can guess what the authors meant by "return routability check", but
>> this document should define that term.
>>
>>
> I could do that. I thought it is already a well-established term.
>
>
>>
>>> 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.
>
>> We might agree that this error is negligible in a lot of cases, but we
>> shouldn't labor under the misapprehension that there is no difference at
>> all.
>>
>>
> There is no doubt a problem that a Wimax behind a home DSL router that
> runs a NAT.
>
>>
>>> The property of the IP
>>> address for a return routability check is attractive as well to
>>> return location information only to a device that transmitted the
>>> request. The LIS receives the request and provides location
>>> information back to the same IP address. If an adversary wants to
>>> learn location information from an IP address other than its own
>>> IP address then it would not see the response message (unless he
>>> is on the subnetwork or at a router along the path towards the
>>> LIS) since the LIS would return the message to the address where
>>> it came from.
>>>
>>
>> IMHO this list should be done in a less slanted way. This is a
>> requirements document, not the solution specification.
>>
>>
> I thought that a discussion about the properties of the IP address is
> quite useful
>
>>
>>> 6. Virtual Private Network (VPN) Considerations
>>>
>>
>> (I'm skipping this section in this review. I found no obvious flaws,
>> but the text is not very accessible.)
>>
>>
>>> If the VPN client device does not participate in location
>>> acquisition, then location acquisition will either fail or provide
>>> the wrong location, with the same results as described in section X.2
>>>
>>
>> xref missing.
>>
>>
>>> 8. Preventing Faked Location based DoS Attacks
>>>
>>
>> I'm wondering why the long discussion in this section doesn't
>> result in hard requirements in section 9?
>>
>>
> I included it because the security stuff is really hard to capture. Even
> with this brief discussion it is difficult to capture all the complexity.
>
>>
>>> 9. Requirements
>>>
>>> The following requirements and assumptions have been identified:
>>>
>>> Requirement L7-1: Identifier Choice
>>>
>>> The LIS MUST be presented with a unique identifier of its own
>>> addressing realm associated in some way with the physical location
>>> of the end host.
>>>
>>
>> I'm not sure what "addressing realm" is supposed to mean.
>>
>>
> Maybe I need to use a different terminology here but I meant to address
> the aspect that some identifiers are only valid in some context.
> Consider public and private IP addresses. A LIS cannot associate an
> private IP address behind my NAT since it is from a different realm not
> resolvable.
>
>>
>>> An identifier is only appropriate if it is from the same realm as
>>> the one for which the location information service maintains
>>> identifier to location mapping.
>>>
>>>
>>>
>>> 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?
>
>>
>>> 10. Security Considerations
>>>
>>
>> skipped again.
>>
>>
>>> 10.3. Requirements
>>>
>>> The following requirements are placed on the location-by-value
>>> approach:
>>>
>>> o No conclusion was reached whether a PIDF-LO or just location
>>> information has to be signed.
>>>
>>
>> This is a second list of requirements. Shouldn't that be integrated
>> into section 9
>> or at least give nice codes like "L7-S1"?
>>
>>
> I could do that.
>
>> -----------------
>>
>> Summary:
>>
>> Good document for a -00 version.
>
> Well, we already had 4 versions prior to the WG document
>
>> Needs some editorial work to harmonize
>> the parts from different authors. Needs to be clearer on the scope of
>> what it tries to do and what not. There is too much focus on possible
>> solutions for a requirements document.
>>
> I will try to clarify the scope a bit, reorganize some sections and
> potentially remove some stuff from the doc.
>
>
>> This is not yet ready for publication.
>>
>>
> :I hope that the next version is closer to completion.
>
>> But if the WGLC just was intended to stimulate responses, then it
>> succeeded.
>>
>>
> :-)
>
> Ciao
> Hannes
>
>> /ol
>>
>
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www1.ietf.org/mailman/listinfo/geopriv
>
>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Thu, 08 Feb 2007 21:09:02 -0500

This archive was generated by hypermail 2.1.8 : Thu Feb 08 2007 - 21:08:59 EST