Subject: [alto] the discovery problem

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 26 Jul 2010 19:51:06 +0800

draft-ietf-geopriv-lis-discovery probably provides most of what you will need for your application.  You could possibly even use the DHCP option defined there.

The security problems arising from the delegation scenario is described briefly in draft-barnes-hard-problem.  You might have fewer problems with this with ALTO.

draft-thomson-geopriv-res-gw-discovery includes the more controversial portion - the use of the reverse tree.  We did originally follow the PTR, but that had even more problems.  For instance, two IPs in different networks - and different servers - can refer to the same domain.

Feedback on the draft that uses the reverse tree has been nothing less than harsh.  It would take me more time than I have right now to go through all the issues.  I'm happy to expand on this in person.

I would strongly recommend that you look at draft-ietf-geopriv-lis-discovery as defining the scope of what is achievable in the short term ...and what you should look at addressing now.

--Martin

---

From: Haibin Song <[email-masked]>
Date: Mon, 26 Jul 2010 13:57:49 +0800

I totally agree. Please see section 5.1 in draft-song-alto-server-discovery
for the DNS discovery method for ALTO. And check section 5.1.2.1 for reusing
the DHCP option for domain name. And check section 5.1.2.3 for the
limitations of the reverse DNS lookup.

BR,
Haibin

Martin Thomson wrote:

>draft-ietf-geopriv-lis-discovery probably provides most of what you will
need for your application.  You could possibly even use the DHCP option
defined there.

>The security problems arising from the delegation scenario is described
briefly in draft-barnes-hard-problem.  You might have fewer problems with
this with ALTO.

draft-thomson-geopriv-res-gw-discovery includes the more controversial
portion - the use of the reverse tree.  We did originally follow the PTR,
but that had even more problems.  For instance, two IPs in different
networks - and different servers - can refer to the same domain.

Feedback on the draft that uses the reverse tree has been nothing less than
harsh.  It would take me more time than I have right now to go through all
the issues.  I'm happy to expand on this in person.

I would strongly recommend that you look at draft-ietf-geopriv-lis-discovery
as defining the scope of what is achievable in the short term ...and what
you should look at addressing now.

>--Martin
_______________________________________________
alto mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/alto

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 27 Jul 2010 03:01:55 +0800

> limitations of the reverse DNS lookup.

Unfortunately, what you have in the draft is only a superficial treatment of the problems.  This gets deeper and more involved - there are operational concerns regarding use (or not) of the reverse tree for IPv6, there are concerns with administrative boundaries and tree walking, there are concerns regarding the use of PTR and how it maps to a single domain that could cross access network boundaries, and many more issues.

--Martin

---

From: Sebastian Kiesel <[email-masked]>
Date: Mon, 26 Jul 2010 23:02:34 +0200

Martin,

On Mon, Jul 26, 2010 at 07:51:06PM +0800, Thomson, Martin wrote:
> draft-ietf-geopriv-lis-discovery probably provides most of what you
> will need for your application.  You could possibly even use the DHCP
> option defined there.

This might be true for the "normal" ALTO server discovery, when the
ALTO client is located in the resource consumer (e.g., peer of a p2p
app), which will eventually access the desired resource.

The 3pdisc use case is different:

Host "B" (e.g., a tracker) connected to an arbitrary network receives an
inbound TCP/UDP flow from another host "A" (e.g., peer) in another
arbitrary access network.  We do not want to make any assumptions on the
L7 protocol, so all "B" knows is the source IP in the packets that
belongs to "A" (or to the outermost NAT box in front of "A", which
should be enough for our purposes, carrier-grade NAT might need
additional discussion).  Knowing only this IP address, host "B" then
needs to discover an ALTO server that can give guidance for optimizing 
host A's peer selection.

This seems to be basically the same scenario as described in sec. 3.2 of
http://tools.ietf.org/id/draft-thomson-geopriv-res-gw-lis-discovery-03.txt
What happened to that draft?

Thanks,
Sebastian

---

From: "Haibin Song" <[email-masked]>
Date: Tue, 27 Jul 2010 07:51:43 +0800

> Unfortunately, what you have in the draft is only a superficial treatment of the
> problems.  This gets deeper and more involved - there are operational
> concerns regarding use (or not) of the reverse tree for IPv6, there are concerns
> with administrative boundaries and tree walking, there are concerns regarding
> the use of PTR and how it maps to a single domain that could cross access
> network boundaries, and many more issues.
> 
> --Martin

The domain mapped from PTR that might cross multiple access networks have been considered, that domain name might be different than your access network domain name. But we are certainly happy to see more considerations to this problem.

Haibin

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 27 Jul 2010 14:10:59 +0800

> The 3pdisc use case is different:
...

> What happened to that draft?

This is a difficult sort of problem to deal with.  I described some of the open issues on that draft in an earlier mail.  We have a few problems that would not apply to alto (perhaps), but on the whole, the problem is a tough one.  Fundamentally, it's an architectural problem.  It's difficult for me to describe the problems succinctly and clearly - I suspect that if I could, we wouldn't have this problem :)

I recommend looking at some of the meeting minutes for previous sessions on this topic.