Re: [dnsext] Possible alternatives to draft-vandergaast-edns-client-ip-00.txt ?

[Ted Hardie <[e-mail]>]

Hi Brian,

Some comments in-line.

On Wed, Feb 3, 2010 at 9:06 AM, Brian Dickson
<[e-mail]> wrote:
> If we're uncomfortable with sending client IP addresses to authority
> servers, how can similar results be achieved?
>
> This is similar to a problem in routing system design, which has been
> looked at by the IRTF folks.
>
> It boils down to three choices - push, pull, or publish/query.
>
> All three have issues of scaling, timeliness, and
> reliability/resiliency/shared-fate.
>
> Sending client IP (however you try to anonymize it) is a "push".
>
> Having the authority server(s)/CDN(s) somehow inform all the resolvers
> in the world of their individual geo-ip (etc) boundaries (I don't even
> know how that would even be possible) would be "pull", or "reverse
> push".
>

I can imagine a different mix here that has the geo-ip boundaries published only
to the interested resolvers.  A resolver is "interested" whenever it has
a query for which localization is available; the problem is that it induces
latency.

Imagine a resolver sending a query for an RR to the relevant authoritative
server; it gets an answer and additional data that localization data is
available.  An interested resolver can then request the localization data
and serve the localized answer instead of the original answer.  This
unfortunately generates at least one additional round-trip plus the processing
time.  If resolvers chose not to get localized data when the requester was
local (presuming that the original answer had been localized to the resolvers
IP), then this also leaks the information that the resolver thought
the requester
was local.

This may fall into your publish/query model, but it seems slightly different.

> The third alternative would be "publish/query".
>
> It could conceivable be done in a manner that would achieve some
> manner of scalability, some transparency regarding privacy issues, and
> presumably good interoperability with adequate backward compatibility.
>
> The exact mechanisms for signaling/negotiating usage of the mechanism
> would likely be similar to draft-vandergaast-edns-client-ip-00.txt,
> i.e. using EDNS[01] as an in-band, in-packet channel. (The alternative
> would require additional look-ups.)
>
> The "publish" part would be that the geo-ip information used by such
> CDN networks, would be published in a DNS zone somewhere, probably in
> a format similar to in-addr.arpa and ip6.arpa, but under its own
> domain or sub-domain.
>
> There would be one "tree" of geo-ip information per geo-ip provider,
> whether that be internal to a CDN, or by a geo-ip provider, or whoever
> else wants to do it themselves.
>
> The RR's in those trees would be "nonce" values, each representing an
> equivalence class of whatever geographic location+granularity the
> geo-ip provider identifies as being "the same". A set of IP addresses
> the geo-ip provider thinks are "close" would share a nonce.
>
> The resolver would need to know which geo-ip tree to query, probably
> signaled by either an EDNS[01] value (DNS label of the root of the
> tree), or some kind of RR.
>
> The resolver would then look up (either in its cache, or directly) the
> client's IP, to determine the nonce.
>
> The resolver would then attach the nonce in an EDNS[01] option to the
> query, and the authority server would return an appropriate result.
>
> The use of the nonce effectively anonymizes the query/answer.
>

Doesn't this depend on the size of the set of IP addresses the geo-ip
provider thinks is close?  What if the set sharing a nonce is still a /24?


> The use of the same tree for many authoritative zones effectively
> further anonymizes the geo-ip lookups, since the likelihood of the
> nonce being found in-cache increases monotonically over time.
>
> Paranoid clients can do lookups to well-known "safe" zones, or even
> the geo-ip providers' nonce trees directly, to prime the cache, before
> doing "real" lookups, e.g. of their <illegal goods/services
> provider>'s web site.
>
> Comments on this idea?
>
> Anyone think it is worth pursuing?
>
> Brian
>
>

I think it is very useful to think about the problem space more generally,
rather than starting out with a solutions draft.

regards,

Ted Hardie