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

From: Tschofenig, Hannes ^lt;hannes.tschofenig@siemens.com>
Date: Fri Feb 09 2007 - 10:28:38 EST

Hi Richard,

The subject of the Geopriv L7 LCP work has seen a lot of discussions
over the past two years.
We have discussed this topic on the mailing list, in design teams, on
IETF meetings and during interim meetings.

However, prior to this draft nobody tried to summarize the discussions
within a document. That caused us to repeately investigate the same
aspects again and again.

Writing about this subject turned out to be quite difficult given that
there is an underlying architecture and some of the solutions in this
architecture require additional discussions about threats and
consequently requirements to deal with them.

For example, it would be possible to use a Geopriv L7 LCP that only
provides location-by-value to the end host. There are certain threats to
location-by-value (at least some folks think so when it comes to attacks
against the PSAP infrastructure). Some of the working group members
suggested to also require the functionality of location-by-reference.
Location-by-reference, however, as you can see from the text raises
again other security aspect that require even more protocols to
interwork. Consequently, we added more requirements.

Just listing requirements without dealing with a description of the
context and the security threats makes it pretty hard to motivate the
requirements.

Since we did not reach an agreement of every aspect in the design team I
can only capture the results and hope that the remaining working group
members shout if they disagree with something.

At the moment I cannot see how it would help to split the document into
several documents without hurting the readability even more.

Does it make more sense for you know?

Ciao
Hannes

> 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-Novemb
er/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
>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Fri, 9 Feb 2007 16:28:38 +0100

This archive was generated by hypermail 2.1.8 : Fri Feb 09 2007 - 10:28:30 EST