Re: [DNSOP] comments on draft-ietf-dnsop-edns-client-subnet-00

[Wilmer van der Gaast <[e-mail]>]

Hello everyone,

Only just spotted this thread after a coworker pointed me at it. I
won't be able to follow up to everything, but will try to address some
of the questions.

Re NETMASK: Yeah, sorry, poor choice of terminology early on in the
doc. Prefix length is the right term to use, it just felt like the
point was clear and it was too late to change it. But feel free, of
course, it's definitely more correct.

On 31 December 2014 at 19:31, 神明達哉 <[e-mail]> wrote:
>
> - Section 6.3
>
>    fields, as detailed below.  Note that the additional and authority
>    sections from a DNS response message are specifically excluded here.
>    Any information cached from these sections MUST NOT be tied to a
>    network.
>
>   What if the "optimized" reply is a negative one for some specific
>   client addresses (while it's positive for some other addresses)?

So, this opens an interesting separate debate: I always thought the
debate specifically disallows using ECS to generate negative
responses: A name must exist or not exist, ECS info is only for
helping out with picking a location closer to the user. However I've
never actually included such a claim into the draft.

>   Or are we simply excluding the support for negative optimized
>   replies?  (If so, I think it would be worth noting explicitly).
>
Definitely should have been noted, and now I've heard some voices of
support for negative responses based on ECS. I myself am still not in
favour.

>   If I understand this (and Section 6.3 in general), the following
>   "suboptimal" scenario could happen: [...]

I think this has been responded to already, but if not.. Let me first
start with some sort of intro:

ECS is mostly meant to be very simple. Some early versions did not
mention transitive use of the option. The user can pass a 0/0 option
for privacy, but otherwise none at all, and resolvers/INSes were not
expected to use any ECS info other than info they generated themselves
from the end user's IP address, including exactly as many bits as they
want to include themselves (and really for IPv4 this should be a /24
because more info is rarely useful and less info very quickly makes
ECS useless).

Many of the confusing parts of the ECS draft now are caused by support
for a transitive ECS option. :-/

To get to your scenario:

>   - The Authoritative Server is configured with two prefixes for
>     optimized responses: 2001:db8::/32 and 2001:db8:2::/48
>   - The Recursive Server sends a query with SOURCE of 2001:db8:1::/48
>   - The Authoritative Server finds the best matching prefix for the
>     SOURCE is 2001:db8::/32 and returns a response corresponding to
>     it, setting SCOPE NETMASK to 32
>   - The Recursive Server receives the response and caches it
>   - The Recursive Server receives a query from 2001:db8:2::1, and
>     finds it has a matching cache (with prefix being 2001:db8::/32)
>     and uses the cached response to answer the query, even if it could
>     get the specifically optimized response for 2001:db8:2::/48 from
>     the Authoritative Server.
>
This is not what the draft is meant to say and I do think this is
explained elsewhere. The response the authority sent here should mean:
"I have nothing for that very specific /48 you sent me, but something
for the /32 it is part of. You can use it for that /48 but if you get
a query for another /48 within it you should re-query me." I think
this is explained in the caching section.

I don't expect this problem to happen much with IPv4 unless someone
sends less specific info than a /24, which could happen if it's poorly
configured, or if it has a client that sends it short ECS options.

(IPv6 is a different story, and with IPv6 it's pretty hard to choose a
good recommended default prefix length...)

> - Section 6.3
>
>    Any reply containing an edns-client-subnet option considered invalid
>    should be treated as if no edns-client-subnet option was specified at
>    all.
>
>   What specifically does "considered invalid" mean?  And, depending on
>   that, shouldn't the reply rather be discarded in such a case?
>
Interesting question. We ourselves were mostly just trying to be
conservative, and not lose traffic/queries from buggy resolvers.
(Being liberal in what you accept, etc.) If the rest of the query is
perfectly valid, we can still send a response that will get the user
to a working endpoint, it *might* just not be as close to the user as
it could have been.

>   If these challenges make CDN-like operators unwilling to deploy
>   DNSSEC and this option makes the optimization even more attractive,
>   then this option could help hinder wider deployment of DNSSEC.

I don't think ECS contributes to this significantly though. A CDN
nameserver is really just an authority with a "few" more A/AAAA
records than your average nameserver, that would therefore need to
keep a "few" more signatures as well. The number is still finite, a
CDN nameserver doesn't dynamically generate random IPv6 addresses for
its responses, right?

Hrm, actually, NSEC might actually be a good reason why ECS can't be
used for negative responses?

>    Users who wish their full IP address to be hidden can include an
>    edns-client-subnet option specifying the wildcard address 0.0.0.0/0
>    (i.e.  FAMILY set to 1 (IPv4), SOURCE NETMASK to 0 and no ADDRESS).
>
>   What if the user (stub resolver)'s address is IPv6?  Should it still
>   set FAMILY to 1?
>
Doesn't really matter, the point the client is trying to get across is
that it doesn't want its query origin IP address to be in an ECS
option. Whther the client is querying over IPv4 or IPv6 might in fact
be a piece of information then so hardcoding to always using 0.0.0.0/0
might be preferable.

Whether it's an IPv4 or IPv6 address the end user is after should
already be clear from the qtype.

> - Section 10.2
>
>    With multiple queries for the same name in flight, the attacker has a
>    higher chance of success in sending a matching response (with the
>    address 0.0.0.0/0 to get it cached for many hosts).
>
>   Another IPv4-centric description.  This should probably be, e.g.
>   "with the SCOPE NETMASK being 0, meaning an empty prefix".
>
It's just an example, I went for an IP address to save on words. COuld
consider mixing ::/0 (less typing in fact!) and 0.0.0.0/0 in various
examples.

-- 
Wilmer van der Gaast, London Traffic/Edge SRE.