At Thu, 8 Jan 2015 19:36:00 +0000,
Wilmer van der Gaast <wil...@google.com> wrote:
> 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.
I'm not necessarily pushing it especially if others don't see the need
for clarifying it, but I don't think it's too late; this doesn't
affect the wire format or the protocol behavior, it's just a
terminology clarification. Some implementations may have to be
updated over time so they are more consistent with the latest
terminology, but this can be gradual updates without affecting the
actual behavior. The draft itself is literally a draft yet, and it's
not uncommon for internet drafts to have this kind of naming changes.
If that provides more clarity and less confusion for many future
readers of the RFC that this draft will eventually become, I think
it's worth the cost of today a lot.
> On 31 December 2014 at 19:31 <jin...@wide.ad.jp> wrote:
> > 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.
I don't have a strong opinion, but in either case I think this should
be clearly documented.
> 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'm afraid I couldn't find anything in the current draft that clearly
excludes the above "suboptimal" scenario. Could you point at the
specific text?
Besides: in another message of this thread I was told that the server
would set SCOPE NETMASK to 47, and I see that will surely prevent the
suboptimal case I described. But I'm not sure if you are talking
about the same thing by "I have nothing for that very specific
/48...", and, in any case, I suspect it's very difficult to reach this
interpretation just from the current text of the draft.
> 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...)
I admit the above specific scenario is a bit artificial and it's
probably less likely to be seen in practice. But, we cannot be sure
how exactly this option will be used in general especially for IPv6
(as you said), and since this document is generic and IP-version
agnostic, I don't think we can just dismiss corner cases. Ideally we
should make the protocol work for such cases, and we should at least
clearly describe any limitations.
> > 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.
My main point is that "invalid" is too broad. All of the following
could be considered "invalid":
A. OPTION-LENGTH is too large (e.g. 65535) for the entire message
B. OPTION-LENGTH is too sort (e.g. 2)
C. FAMILY is neither 1 nor 2
D. SOURCE/SCOPE NETMASK is 255
E. SCOPE NETMASK is not 0 in a request
F. SOURCE/SCOPE are 0, but ADDRESS is not empty (according to OPTION-LENGTH)
G. FAMILY=1, SOURCE NETMASK=32, but ADDRESS contains more than 4
octets of data (according to OPTION-LENGTH)
H. ADDRESS indicates it's a multicast address (e.g. starting with 0xff
for IPv6)
Some should be considered "too invalid" to continue handling the
message at all; at least I believe any sane implementation treats the
case A that way. Others may be negligible, but I wouldn't be
surprised if an implementation drops the entire message in cases like
G (in fact, from a quick look the ISC BIND 9 seems to drop the entire
message in cases A, B, D, F, and G).
I don't know what's the best way to address this point (or whether to
do it in the first place). Perhaps it might not matter much, as cases
like G are clearly bogus and the sender implementation should be
corrected (and will be so if reasonably maintained) over time. But if
we want to do something about it in this document, some options are:
- describe message validation more specifically and precisely: e.g.,
"if the OPTION-LENGTH is smaller than 4, the receiver MUST discard
the entire DNS message...." Many IETF protocol documents take this
approach (but many others don't).
- describe the general guideline with some more leniency and details,
e.g. "if any of the option field contains an unexpected value (e.g.
SOURCE NETMASK larger than 128 when FAMILY is 2), the receiver SHOULD
ignore the entire option but continue processing the message unless
OPTION-LENGTH is too large to move to the next option (or the end of
the OPT RR) safely. An implementation MAY choose to discard the
entire message according to its own validation policy except for
cases that this document explicitly allows, if any."
> > 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?
Possibly so, but if we think about implementation and deployment
details, it may not be that trivial. For example, many
publicly-available signing tools that I know of work per zone. So
you'd need to sign the entire zone for all versions corresponding to
all combinations of different answers. Depending on the size of
deployment it's scalability limitation may not be acceptable. Big
operators can certainly develop custom tools that work well in these
cases, but some operators will still prefer using generic tools or
simply don't have resource to develop custom ones.
I also know an implementation at the authoritative side that allows a
user to specify regular expressions for owner names, e.g.,
*.example.com, where '*' is not a DNS wildcard, and www.example.com,
ftp.example.com etc would be considered individual owner names in
terms of DNSSEC signature calculation.
Also, technically, if you change an answer that means you make a
change to the zone, which, again technically, would require an update
to its SOA, which would require resigning it.
Admittedly, though, I don't know whether these technical details are a
barrier for deploying DNSSEC in CDN-like operations.
> 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.
In the case of a "real" end user (a stub resolver), the address family
is not a secret. In case it's forwarded by a recursive server
obscuring it may make some sense.
Anyway, I knew it wouldn't really matter, but my point is that the
possible ambiguity of the text could be an interoperability issue.
For example, a stub resolver sets FAMILY to 1 with the actual source
address being IPv6. A Resolver implementation notices the
inconsistency and might consider it a kind of malicious attempt and
drop it (btw this is probably also related to the "what's invalid"
discussion).
Perhaps the draft can be clearer and more explicit, e.g.:
- When setting SOURCE NETMASK to 0, the client (end client or
forwarding resolver) SHOULD set FAMILY to 1, regardless of the
corresponding address for (slightly) better privacy protection.
- The receiving node MUST ignore the ADDRESS and FAMILY if SOURCE
NETMASK is set to 0.
BTW: while responding to this part I noticed one minor editorial
issue: in the definition of FAMILY in Section 2, s/[2]/[1]/:
o FAMILY, 2 octets, indicates the family of the address contained in
the option, using address family codes as assigned by IANA in
IANA-AFI [2].
> Whether it's an IPv4 or IPv6 address the end user is after should
> already be clear from the qtype.
Yes, but I don't think it's relevant to this discussion...
> > - 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.
I know this is (most likely to be) intended to be just an example, but
IMO the text isn't clear enough about the intent. Mixing cases may be
helpful, and/or just adding "e.g." etc may be enough (in this case it
would be: "(e.g., with the address 0.0.0.0/0 to get it cached for many
hosts).".
--
JINMEI, Tatuya
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
