Subject: [Int-area] Discovering a Location Server in the Access Network

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 14 Sep 2007 10:49:12 +0200

Hi all,

I would need some feedback regarding work that is currently being done 
in the GEOPRIV working group.
For some time we have been working on an application layer protocol that 
allows the end host to obtain its own location information (or a 
reference to it) from a server (called LIS) in the access network. This 
LIS indeed needs to be located in the access network (and not at an 
arbitrary place on the Internet) since only the layer 2/layer 3 provider 
is able to determine the precise location of end point.

A year ago I lead a design team that captured the problem statement and 
requirements. The document is available here:
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-l7-lcp-ps-05.txt

The protocol that provides the functionality of the above-mentioned 
requirements document is HELD:
http://tools.ietf.org/html/draft-ietf-geopriv-http-location-delivery

Providing the end host with the address of the LIS is relatively easy if 
you can use DHCP. However, there are deployment environments (such as 
DSL networks) where the DSL operator cannot control the DSL home routers 
and any information that is provided by the DSL operator may not be 
relayed to the end host via this box.

So, to overcome this issue the group had an idea: Let's use a different 
discovery technique that does not require upgrades to intermediate 
devices (such as this DSL home router).

In short, the current proposal (see 
http://tools.ietf.org/html/draft-thomson-geopriv-lis-discovery-02.txt; 
ignoring Section 2 which defines the DHCP portion) essentially does the 
following:

* Discover the public IP address of the end point
* Perform a reverse DNS lookup to learn the domain
* Lookup the LIS for that domain
* Contact the LIS

We have investigated other solutions as well (see Section 4 of  
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-l7-lcp-ps-05.txt) 
but the group (or at least a few folks) believes that this is a "good" 
approach.

I had a chat with Jari and we both agree that this topoic falls into the 
expertise of the Internet Area. Hence, I would like to solicit feedback 
from you.

Ciao
Hannes

_______________________________________________
Int-area mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/int-area

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 14 Sep 2007 16:06:35 +0200

Hi Hannes, let me try to give some thoughts.  But your mail is such a
concentrate of information to newcomers to GEOPRIV.

I'm not sure I get everything right, but anyways, here goes.

Hannes Tschofenig wrote:

> 
> A year ago I lead a design team that captured the problem statement
> and requirements. The document is available here: 
draft-ietf-geopriv-l7-lcp-ps-05.txt:
> 3.2.  Moving Network
> 
>    An example of a moving network is [...]

(As a side note, I'm happy that the GEOPRIV L7 PS and reqs document 
mentions moving networks and describes them.  I'm already happy with the 
terminology, because many people I'm talking to seem to refuse to accept 
this 'moving network' term and prefer 'mobile network' ignoring the 
potential clash with 'mobile networks' that don't move but support 
mobility of hosts.

One would also maybe cite "mobile network" of RFC4885 "Network Mobility 
Support Terminology" and "Mobility Terminology" RFC3753 and last but not 
least rfc2002 Mobile IPv4 probably the first to mention "mobile 
networks" in its section 4.5.  I think MANET documents may too.

Technically, the 'moving networks' you describe are a little bit 
different than the 'mobile networks' which run Mobile IP NEMO 
extensions.  Your movnets have the LFN (your Ethernet laptop) do the 
PPPoE game and use the MR (your NTE) as a modem I believe.  A multi-host 
WiMax deployment.  The 'mobile networks' have the Mobile Router (your 
NTE) do the dialup, eventually PPPoE but any other PtP or shared media, 
for the access.

But, I think 'moving networks' per your definition and 'mobile networks' 
per Mobile IP stuff are conceptually the same thing.  I'd like to be 
able to call the Mobile IP NEMO-based 'mobile networks' - 'moving networks'.

Anyways, just a digression.)

>  ignoring Section 2 which defines the DHCP portion) essentially does 
> the following:
> 

I think it should say 'Discover ... address of the LIS', right?   And
not 'of the end point'(?)

[...]
>  but the group (or at least a few folks) believes that this is a 
> "good" approach.

Section4:
> DHCP-based discovery, DNS-based discovery, Redirect [HTTP or AAA] 
> rule, multicast DNS queries, anycast and Teredo discovery.

That's fine it covers all I could think of, but there's (1) the
EXPERIMENTAL IPv6 Node Information Queries RFC4620 as well.  It's
limited to link-local multicast but I think that would be an advantage
(and not an inconvenient) because one would want that LIS server to be
as close to the querier, for geographical precision, I think.

Some IKEv2 extension possibility for discovering parameters too, and
BOOTP and last but not least Service Location Protocol RFC2165.

draft-thomson-geopriv-lis-discovery-02:
> 1.2. U-NAPTR Discovery
> 
> Where DHCP is not available, the DNS might be able to provide a URI.

If DHCP is not available then the host doesn't have the DNS Server
address either, thus no way to obtain that URI, right?

If I can manually configure the DNS Server address then I can manually
configure its location info as well, right?

Alex

> 
> I had a chat with Jari and we both agree that this topoic falls into 
> the expertise of the Internet Area. Hence, I would like to solicit 
> feedback from you.
> 
> Ciao Hannes
> 
> 
> 
> _______________________________________________ Int-area mailing list
>  [email-masked] 

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 14 Sep 2007 16:58:55 +0200

Hi Alex,

Alexandru Petrescu wrote:
> mentions moving networks and describes them.  I'm already happy with 
> the terminology, because many people I'm talking to seem to refuse to 
> accept this 'moving network' term and prefer 'mobile network' ignoring 
> the potential clash with 'mobile networks' that don't move but support 
> mobility of hosts.
>
> One would also maybe cite "mobile network" of RFC4885 "Network 
> Mobility Support Terminology" and "Mobility Terminology" RFC3753 and 
> last but not least rfc2002 Mobile IPv4 probably the first to mention 
> "mobile networks" in its section 4.5.  I think MANET documents may too.
>
Yep. I could cite that RFC.

> PPPoE game and use the MR (your NTE) as a modem I believe.  A 
> multi-host WiMax deployment.  The 'mobile networks' have the Mobile 
> Router (your NTE) do the dialup, eventually PPPoE but any other PtP or 
> shared media, for the access.
>
> But, I think 'moving networks' per your definition and 'mobile 
> networks' per Mobile IP stuff are conceptually the same thing.  I'd 
> like to be able to call the Mobile IP NEMO-based 'mobile networks' - 
> 'moving networks'.
>
No; it really means that you learn your own public IP address. That's no 
problem if you already have one but you might also be behind a NAT 
(which is extremely common in a DSL network). Hence, knowing your 
private IP address is not very useful for the discovery of the LIS since 
you will not find a LIS in your own home network.

> as close to the querier, for geographical precision, I think.
I can certainly list it as an option but the fact that it is restricted 
to a link-local multicast does not make it very attractive for our usage 
environment.

> BOOTP and last but not least Service Location Protocol RFC2165.
Yep. I could also mention these.

I have to refresh my memory about SLP but IKEv2 is certainly not very 
useful in our environment.

> address either, thus no way to obtain that URI, right?
DHCP is available but you will only learn the information obtained from 
your DSL router (which plays the role of the DHCP server for your home 
network).
This DSL router will, however, not forward information from the DSL 
operator. It is somewhat independent.

Ciao
Hannes

>>  [email-masked] https://www1.ietf.org/mailman/listinfo/int-area
>>
>
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 14 Sep 2007 17:37:49 +0200

> you will not find a LIS in your own home network.

But you're sure that it's necessary to discover my IP address when I'm 
behind NAT?  Does the LIS need to contact me without me needing to 
contact it first?

> to a link-local multicast does not make it very attractive for our usage 

Ok.  I thought the reverse but anyways.

> useful in our environment.

Well, at some point you talk using DNS in a secure manner (in the 
security section)...

Anyways, thanks.

Alex

---

From: Yangwoo Ko <[email-masked]>
Date: Sat, 15 Sep 2007 09:46:45 +0900

Alexandru Petrescu wrote:
>> No; it really means that you learn your own public IP address. That's 
>> no problem if you already have one but you might also be behind a NAT 
>> private IP address is not very useful for the discovery of the LIS 
>> since you will not find a LIS in your own home network.
> 

What I understood from the first mail sent by Hannes is that discovery 
of the public address is necessary for the next step (i.e. DNS reverse 
lookup) to work. If there is other way to get the address of LIS without 
going through presented steps, then that is just yet another alternative.

Regards

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 15 Sep 2007 10:24:26 +0200

Hi Alex,

Alexandru Petrescu wrote:
>>>>  ignoring Section 2 which defines the DHCP portion) essentially 
>>>> does the following:
>>>>
Yes, you have to find the LIS first. In order to find the LIS in that 
scenario you need to learn the domain name of the access network (in 
this case the DSL operator's access network).When you know your own 
public IP address then you are able to find the domain name of the DSL 
operator's LIS in that network.

>> I can certainly list it as an option but the fact that it is 
>> restricted to a link-local multicast does not make it very attractive 
>> for our usage environment.
>
Providing channel security between the end host and the LIS is an 
orthogonal issue.
Current requirements indicate that only server-side authentication is 
realistic to mandate. IKEv2 does not provide a way to execute 
server-side only authentication; TLS would just be doing a fine job and 
it is a more natural choice for an application layer protocol  (with 
HELD XML is carried on top of HTTP)

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 21 Sep 2007 13:11:29 +0200

Hi all,

I haven't received concerns regarding the suggested discovery approach. 
May I assume from the lack of feedback that the suggested approach is 
reasonable?

Ciao
Hannes

Hannes Tschofenig wrote:
> For some time we have been working on an application layer protocol 
> that allows the end host to obtain its own location information (or a 
> reference to it) from a server (called LIS) in the access network. 
> This LIS indeed needs to be located in the access network (and not at 
> an arbitrary place on the Internet) since only the layer 2/layer 3 
> provider is able to determine the precise location of end point.
>
> Providing the end host with the address of the LIS is relatively easy 
> if you can use DHCP. However, there are deployment environments (such 
> as DSL networks) where the DSL operator cannot control the DSL home 
> routers and any information that is provided by the DSL operator may 
> not be relayed to the end host via this box.
>
> So, to overcome this issue the group had an idea: Let's use a 
> different discovery technique that does not require upgrades to 
> intermediate devices (such as this DSL home router).
>

---

From: Joe Touch <[email-masked]>
Date: Fri, 21 Sep 2007 09:23:25 -0700

> May I assume from the lack of feedback that the suggested approach is

I have seen this sort of conclusion claimed before, and it is incorrect.

Silence is not a hum in favor.

I don't have a position on this per se, but if nobody can step forward
and claim this is a reasonable solution, all we have is 'lack of
feedback', not 'consensus'.

Joe

...

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 21 Sep 2007 19:54:14 +0200

Joe Touch wrote:
> 
> Hannes Tschofenig wrote:
>> Hi all,
>> 
>> I haven't received concerns regarding the suggested discovery 
>> approach. May I assume from the lack of feedback that the suggested
>>  approach is reasonable?
> 
> I don't have a position on this per se, but if nobody can step 
> forward and claim this is a reasonable solution, all we have is 'lack
>  of feedback', not 'consensus'.

I think I can agree.

I'm interested in all discovery mechanisms existing out there, and then
making some new...  But at some point one can easily wonder whether
there aren't too many of them those discovery mechanisms, and maybe some
more reuse can be possible.

So can I turn your (Hannes) question: how much does your new discovery
protocol reuse?  Of what?  Please don't argument that that and that
group believes the requirements eliminate all existing discovery
mechanisms, because I'm speechless in front of these requirements
because I haven't followed them, sorry :-)

Then of course another question to you (Hannes) is whether we have any
IPR issues around this new method of discovery, any entanglement.  If
there's IPR, on which side would one prefer to err, and so.

But without at least these little things one can say little, and even
less call it 'consensus', In My Humble Oppinion.

Alex

>>> * Discover the public IP address of the end point * Perform a 
>>> reverse DNS lookup to learn the domain * Lookup the LIS for that 
>>> domain * Contact the LIS
> 
> 
> ------------------------------------------------------------------------
> 
> 
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 21 Sep 2007 20:10:10 +0200

My mail was a new (and different) attempt to receive some feedback.
So far, didn't work. Just bad luck.

Ciao
Hannes

---

From: Joe Touch <[email-masked]>
Date: Fri, 21 Sep 2007 11:18:12 -0700

Hi, Hannes,

I appreciate the idea of a 'ping' to the group. I also appreciate that
everyone has their area of focus, and not all things brought to a WG
receive the attention that's needed to move them forward.

IETFers have discussed incentive systems to encourage people to read
things that 'need to be reviewed', but let's not discuss that here.

Until we have that or an alternative - in the absence of positive
feedback - items should not move forward in a WG based on silence as
implicit approval.

If there is an absence of positive community support - either explicit,
or implicit by the community's lack of interest and silence - IMO, the
best path forward is to *revert* an item to individual submission, even
if it's on the WG charter.

Joe

-- 
----------------------------------------------------------------------
Joe Touch                Sr. Network Engineer, USAF TSAT Space Segment
               Postel Center Director & Research Assoc. Prof., USC/ISI

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 21 Sep 2007 20:22:01 +0200

Hi Alex,

> more reuse can be possible.
If we can re-use something existing then that's great for me as well.
The usage of DNS based discovery is not extremely new either. The 
special case here is just to consideration of the fact that there are 
NATs out there.

> protocol reuse?

Actually, it is not MY discovery mechanism. I am just a long-time 
participant of the GEOPRIV working group and would like to see some 
progress. In this particular case cross-area review seemed to be an 
appropriate way to receive feedback "early" in the process.

>   Of what?  Please don't argument that that and that
That's a basic problem if one working group is working on a subject and 
another group or community is providing input to selected parts. I have 
some (bad) experience with these type of interactions and so far I 
learned that soliciting feedback later than earlier is causing more 
problems in the end. For some recurring problems (such as XML issues) 
there are separate review groups that provide feedback in a timely 
fashion. This case is a bit too special and there is no such group 
available.

> there's IPR, on which side would one prefer to err, and so.
There were no IPRs disclosures posted to the respective GEOPRIV documents.
Since I am not the author of the specs I don't really know.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 21 Sep 2007 20:28:37 +0200

Hi Joe,

> receive the attention that's needed to move them forward.
Agree.

> things that 'need to be reviewed', but let's not discuss that here.
Certainly a complicated subject.

> feedback - items should not move forward in a WG based on silence as
So far this issue is non-blocking. I just fear that this issue will 
surface again during IETF Last Call.

> if it's on the WG charter.
There is another discovery mechanism, namely based on DHCP, that is 
pretty uncontroversial. I believe that it will progress quite smoothly 
in the group. Hence, the HELD specification itself would not be blocked 
since there is this other discovery mechanism. I do, however, believe 
that it is important to consider real world constraints that might slow 
down the deployment of certain mechanisms. If there is a way todo 
something about them then (in my believe) we should be looking at them.

Ciao
Hannes

---

From: Pekka Savola <[email-masked]>
Date: Sat, 22 Sep 2007 07:53:51 +0300 (EEST)

> * Lookup the LIS for that domain

2-3 years ago we had the similar problem with IPv6-in-IPv4 tunnel 
endpoint discovery, only that the endpoint could reside outside the 
L2/L3 network as well.  The approaches identified then were described 
at:

http://tools.ietf.org/html/draft-palet-v6ops-tun-auto-disc-03

Personally, I thought anycast made most sense.

Some other folks preferred reverse DNS population (e.g. [1]), but that 
also has problems with private address use of a more recent approach 
to try to push the NAT boxes to act as authoritative for private 
address spaces [2] in which case the ISP could not populate its DNS 
resolvers for private addresses either.

In your case where the L2/L3 provider is required to provide this 
information in order for the methodology could work, though personally 
I'm somewhat concerned about 1) how reliable the public IP address 
discovery could be, 2) what happens if the ISP doesn't provide reverse 
DNS entry for the public IP, and 3) whether the operator who's 
providing L3 service and public IP does in fact even know where the 
user is located (if the user's ADSL session is provided by a L2 
provider and just tunneled - in bulk - using L2TP to L3 provider).

The last issue is probably the biggest and you may need to consider in 
more detail how such "L2 different from L3" network would work. 
Realistically any solution I could think of that doesn't involve DHCP 
or PPP is likely to require coordination in this case.  Would it 
required that the local regular requires L3 provider to also keep 
track of the physical location?

[1] http://tools.ietf.org/html/draft-yamamoto-naptr-service-discovery-01 
[2] http://tools.ietf.org/html/draft-ietf-dnsop-default-local-zones-02

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 22 Sep 2007 16:12:14 +0200

Hi Pekka,

thanks for your response.

Pekka Savola wrote:
> L2/L3 network as well.  The approaches identified then were described at:
>

Thanks for the pointer to this document.
I will go through it.

> Personally, I thought anycast made most sense.
I will evaluate whether it can be used for our usage scenario.

> discovery could be,
That's something I was concerned about as well.

> 2) what happens if the ISP doesn't provide reverse DNS entry for the 
> public IP,

Obviously if you don't implement important parts of the solution then 
the solution will not work.

> and 3) whether the operator who's providing L3 service and public IP 
> does in fact even know where the user is located (if the user's ADSL 
> session is provided by a L2 provider and just tunneled - in bulk - 
> using L2TP to L3 provider).
The ISP may, in some cases, not be able to know it. There is also a 
story for this, see.
http://tools.ietf.org/wg/geopriv/draft-winterbottom-geopriv-lis2lis-req-00.txt
http://tools.ietf.org/wg/geopriv/draft-winterbottom-geopriv-held-identity-extensions-02.txt
*
*
> track of the physical location?
So far, I haven't mentioned the usage scenarios. Some of us are 
particularly interested in emergency services. The regulator is already 
in the progress of placing requirements on the access network provider 
to make location information available (in case of emergency services).

Ciao
Hannes

>
> [1] 
> http://tools.ietf.org/html/draft-yamamoto-naptr-service-discovery-01

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 22 Sep 2007 17:27:59 +0200

> approach. May I assume from the lack of feedback that the suggested  

Not so fast...

I've given the draft a quick read and I find myself with some questions:

- what would be the resolution of the geography information?

- how sensitive is this information from a privacy standpoint?

The answers to these questions will determine what approaches are  
workable.

As for the discovery mechanisms:

STUN -> reverse DNS -> location server seems convoluted to me. If you  
look at DNS service discovery (also known as wide area bonjour in  
some circles) you'll see something that's a lot easier: forward DNS - 
 > server. The advantage here is that DHCP supplies a domain name  
that can be used for the forward lookup, and home gateways tend to  
push the domain name they learn from an upstream server out to local  
hosts so this would work fairly well in an IPv4/NAT setup. And it can  
piggy back on the DNS service discovery that already happens if  
applicable.

But there are two issues: IPv6, which is typically deployed without  
DHCP and also often without a working reverse DNS. Apart from that,  
there is no built-in limitation on who gets to discover the server  
address. This can be fixed by letting the location server handle  
privacy limitations.

Although anycast was widely shut down for DNS resolver discovery, I  
think it fits really well here, because it works both for IPv4 and  
IPv6 and doesn't require additional infrastructure such as the DNS or  
DHCP. Also, the anycast mechanism automatically limits who gets to  
talk to the server.

Last but not least, the draft seems to assume a centralized model  
where there is one authoritative server and clients need to talk to  
that server. I'm not entirely comfortable with that. In general, it's  
always preferable to be in charge of your own destiny as a user. A  
more practical problem could be that service providers don't set up  
servers. We've seen that there are groups who will spend time and  
money to discover information like this independently. It would be  
great if that information could be used if there is no other choice  
and/or the user prefers this.

It would also be great if home gateways could (re)transmit location  
information, which is either learned from an upstream server or  
entered by a local administrator. But in these cases it's important  
to consider the possibility of having wrong or conflicting  
information. (I.e., user moves and forgets to change location setting  
in a wifi base station.)