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
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
