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

From: 神明達哉 <[email-masked]>
Date: Wed, 31 Dec 2014 11:31:21 -0800

I've read the draft and have the following comments.

- Section 5

   o  SOURCE NETMASK, unsigned octet representing the length of the
      netmask pertaining to the query.  In replies, it mirrors the same
      value as in the requests.  It can be set to 0 to disable client-
      based lookups, in which case the ADDRESS field MUST be absent.

  I suspect the term "NETMASK" could be misleading or at least
  inaccurate.  Technically, a netmask can be an arbitrary bit pattern
  to represent a "mask", so its "length" may not always be
  well-defined.  Also, IPv6 doesn't support the concept of
  non-contiguous "netmask".  This definition seems to implicitly
  assume contiguous netmasks, and define the term "NETMASK" as the
  prefix length of an address.  I'm fine with the assumption as
  non-contiguous IPv4 netmasks can be reasonably considered a thing of
  past.  But in that case I'd suggest using the term "PREFIX-LENGTH",
  noting that this specification does not support non-contiguous IPv4
  netmasks.

  Same for SCOPE NETMASK.

- Section 5

   o  SCOPE NETMASK, unsigned octet representing the length of the
      [...]
      It might or might not match SOURCE NETMASK; it could be shorter or
      longer.

  "match" sounds awkward since the "SOURCE NETMASK" is defined as a
  length of bits (again, I'd suggest renaming it "SOURCE
  PREFIX-LENGTH").  I suggest: s/match/be equal to/ (and perhaps
  s/shorter or longer/smaller or larger/)

- Section 6.1

   A Stub Resolver MAY generate DNS queries with an edns-client-subnet
   option with SOURCE NETMASK set to 0 (i.e. 0.0.0.0/0) to indicate that

  I'd suggest: s/i.e./e.g./ since this may also be an IPv6 address (in
  which case FAMILY is set to 2)

- 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)?
  The authoritative server would (or might) return an SOA in the
  authority section, expecting the Recursive Resolver to use it for
  negative cache specific to the corresponding client address.
  Or are we simply excluding the support for negative optimized
  replies?  (If so, I think it would be worth noting explicitly).

- Section 6.3

   If the address of the client is within any of the networks in the
   cache, then the cached response MUST be returned as usual.  If the
   address of the client matches multiple networks in the cache, the
   entry with the longest SCOPE NETMASK value MUST be returned, as with
   most route-matching algorithms.

  If I understand this (and Section 6.3 in general), the following
  "suboptimal" scenario could happen:
  - 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.

  Is my understanding correct?  If so, is this a problem to resolve or
  something we need to accept?

- Section 6.3: likewise, what about the following scenario?
  - The Authoritative Server is configured with two prefixes for
    optimized responses: 2001:db8::1/48 and 2001:db8:2::/48
  - The Recursive Server receives a query from 2001:db8:3::1 and
    sends its own query to the Authoritative Server with
    SOURCE=2001:db8::/32, SCOPE NETMASK=48
  - The Authoritative Server finds the two /48 prefixes match the
    source, and returns a response using one of them.
  - The Recursive Server receives the response and caches it.
  - The Recursive Server receives a query from 2001:db8:3::1 again.
    It doesn't match the cached SCOPED address, so it sends its own
    query to the authoritative server again.
  - This will be always the case for 2001:db8:3::1, and the cached
    information is effectively useless, making the Recursive Server
    busier.

- 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?

- Section 8

   The presence or absence of an [RFC6891] EDNS0 OPT resource record
   containing an edns-client-subnet option in a DNS query does not
   change the usage of the resource records and mechanisms used to
   provide data origin authentication and data integrity to the DNS, as
   described in [RFC4033], [RFC4034] and [RFC4035].  OPT records are not
   signed.

  While what's described in this section is not incorrect, I suspect
  it's not really fair not to mention that intended deployments (i.e.,
  CDN-like ones) with this option are not really friendly with DNSSEC
  at best; even if it's not impossible to provide a valid signature
  for every "optimized" response in theory, it would involve many
  non-trivial technical challenges such as on-the-fly signing.

  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'm not saying this option is evil and should be banned just because
  of this, but I'd expect this kind of consideration for this section
  to be more helpful and fair.

- Section 10.1

   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?

- 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".

- Section 12

   1.   A stub resolver SR with IP address 192.0.2.37 tries to resolve
        www.example.com, by forwarding the query to the Recursive
        Resolver R from IP address IP, asking for recursion.

  I guess the intent was: s/Resolver R/Resolver RNS/.  And some other
  "R"s in the section will also have to be changed to "RNS".

- Section 12

        *  ADDRESS, set to 0xC0 0x00 0x02 0xE0, copied from the request.

  This is not a verbatim copy from the request, so I suggest:
  "extended from the request".

Editorial nits

- Section 3: A very minor point, but this draft seems to always use
  the term "Section" to refer to a numbered portion of RFCs/drafts,
  such as "Section 5" or "Section 6.1", so to be consistent "chapter"
  would better be "Section".

   Authoritative Nameserver:  A nameserver that has authority over one
      or more DNS zones.  These are normally not contacted by clients
      directly but by Recursive Resolvers.  Described in [RFC1035]
      chapter 6.

- Section 6.3: s/.././

      to queries originating from the network covered by the ADDRESS and
      SCOPE NETMASK..

--
JINMEI, Tatuya