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

Hi Alex,

Alexandru Petrescu wrote:
> Hannes Tschofenig wrote:
>>>>
>>>>  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
>>>
>>> I think it should say 'Discover ... address of the LIS', right?   And
>>> not 'of the end point'(?)
>>>
>> 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.
>
> 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?
>
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.

>>> [...]
>>>> 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.
>>>
>>> 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.
>> 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.
>
> Ok.  I thought the reverse but anyways.
>
>>> Some IKEv2 extension possibility for discovering parameters too, and
>>> 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.
>
> Well, at some point you talk using DNS in a secure manner (in the 
> security section)...
>
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
> Anyways, thanks.
>
> Alex
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email 
> ______________________________________________________________________

_______________________________________________
Int-area mailing list
Int-area@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/int-area