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

From: Otmar Lendl <[email-masked]>
Date: Tue, 6 Feb 2007 18:31:12 +0100

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?

The term "Location Information Server (LIS)" is used. Is this identical
to RFC3693's "Location Server (LS)"?

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?

Section 4 talks about LIS discovery. Is this document also
supposed to define the requirements for that?

>
>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?

[...]

>
>   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?

>
>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.

>   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.

>   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?

>   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:

>   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 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 ..

>   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.

>
>   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).

>
>   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.

>   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. 

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.

>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.

>
>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?

>
>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.

>      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.

>
>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"?

-----------------

Summary: 

Good document for a -00 version. 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. 

This is not yet ready for publication.

But if the WGLC just was intended to stimulate responses, then it succeeded.

/ol
-- 
< Otmar Lendl ([email-masked]) | nic.at Systems Engineer >

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 08 Feb 2007 23:12:48 +0100

Hi Otmar,

thanks a lot for your review. Please find my response below:

> 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.

> 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.

> 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.

> 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.

> as well. VPNs are mentioned explicitly later in the draft. Are they

Solutions need to consider VPNs.

Actually, we want to have the solution to work everywhere. Hence, we 
couldn't exclude networks.

> 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.

> 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.

> "discover it"? It needs to learn a way how to contact it.
Fine for me.

> Are these to points part of the official requirements of the LCP?
I should remove this sentence.

> Ok, so this identifier is the primary key with the LIS will use
Yes.

> 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.

> should not need to be aware ..
OK

> 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.

> the criteria 2 and 3 from above).
Generally speaking you are certainly right.

> document should define that term.
I could do that. I thought it is already a well-established term.

> 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.

> shouldn't labor under the misapprehension that there is no difference at
There is no doubt a problem that a Wimax behind a home DSL router that 
runs a NAT.

> requirements document, not the solution specification.
I thought that a discussion about the properties of the IP address is 
quite useful

> 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.

> 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.

> Leaving this issue open ("they need to cooperate somehow") is not doing

Could you provide some text about what you want?

> 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
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

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 8 Feb 2007 20:29:22 -0500

> For example, one could discuss what the "non-public information"  
> means in this context:
>
> "
> 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.
>

I think the 3693 terminology is not always helpful, as it assumes a  
particular deployment model, rather than focusing on the properties  
we care about, namely privacy and security (and others).

As far as I can tell, there are only two properties that matter:

(1) Are the sender and receiver of data part of the same circle of  
trust or not? (There are probably three rough cases: same person/ 
organization, client-customer relationship with contractual  
obligations and target-stranger relationships.)

(2) Does the information contain just location information or does it  
allow tying location information to a personal identity? (For  
example, this makes a LoST query from a resolver to an authoritative  
server relatively non-sensitive.)

The latter can be a bit of a gray area. For example, maybe the  
protocol only contains a client IP address, but somebody might be  
able to observe my web browsing and determine the corresponding  
Columbia login ID and thus my identity. Thus, I'd distinguish direct  
personally identifiable information (contains an AOR, say), indirect  
and non-identifiable.

Instead of worrying about labels, describing protocols along these  
dimensions would, in my opinion, be more helpful. Here, we're mainly  
talking about (case 2 of #1) and "indirect".

Henning

---

From: Richard Barnes <[email-masked]>
Date: Thu, 08 Feb 2007 21:09:02 -0500

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:
>> abstract it's the "end host". Is this the "Target" according to 
>> RFC3693? Will there be LIS-LIS communication also using that LCP?
>>   
>> I can guess what the authors meant by "return routability check", but 
>> this document should define that term.
>>
>>

---

From: Otmar Lendl <[email-masked]>
Date: Fri, 9 Feb 2007 15:30:08 +0100

Hannes,

> 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.

> 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.

> 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?

> later section in the draft.

See above. I recommend to declare the discovery out-of-scope for this
documents. It just distracts.

> 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.

> the Geopriv L7 LCP solution had in mind.

I agree, but that limitation needs to be documented.

> I thought that a discussion about the properties of the IP address is 

... if you qualify it with "end-host - LIS" use-case. 

> 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.

/ol

---

From: "Tschofenig, Hannes" <[email-masked]>
Date: Fri, 9 Feb 2007 16:28:38 +0100

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

> Information), 
> >> I'm missing a clear definition who will talk this "LCP" 
> protocol. Per 
> >> that
> >> It is not clear how the end system communicates that 
> identifier to the 
> >> LIS.
> >>
> >>   
> >> This is a second list of requirements. Shouldn't that be 
> integrated 
> >> into section 9

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 10 Feb 2007 21:14:42 +0100

Hi Otmar,
Hi all,

Please find my response below:

> section could help the readability.
Maybe I should just put some terminology there regardless whether it 
reflects RFC 3693 or not.

> 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.

>> The LIS discovery was a hot topic inFrom [email-masked] Sat Feb 10 15:15:06 2007
Date: Sat, 10 Feb 2007 21:14:42 +0100
From: Hannes Tschofenig <[email-masked]>
To: Otmar Lendl <[email-masked]>
Subject: Re: [Geopriv] Review of draft-ietf-geopriv-l7-lcp-ps-00
Cc: [email-masked]

Hi Otmar,
Hi all,

Please find my response below:

> section could help the readability.
Maybe I should just put some terminology there regardless whether it 
reflects RFC 3693 or not.

> 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.

> treat these two problems as separate work-packages and thus separate
Maybe.

> 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.

> I agree, but that limitation needs to be documented.
I did that in the " IP Address:" paragraph of Section 5.

> ... 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.

>>> It is my recommendation that this interface utilizes th the design team work since it is 
Maybe.

> 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.

> I agree, but that limitation needs to be documented.
I did that in the " IP Address:" paragraph of Section 5.

> ... 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.

> 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