Re: [DNSOP] Cache utilization review and suggestion for EDNS client-subnet

[Mukund Sivaraman <[e-mail]>]

Hi Jinmei

On Tue, Feb 02, 2016 at 11:31:34AM -0800, 神明達哉 wrote:
> At Mon, 28 Dec 2015 07:59:14 +0530,
> Mukund Sivaraman <[e-mail]> wrote:
> 
> > https://tools.ietf.org/html/draft-ietf-dnsop-edns-client-subnet-06
> >
> > One of the main concerns while implementing EDNS client-subnet is about
> > keeping the size of cache small and in check. It seems cache handling
> > for EDNS client-subnet can be improved by changes to the option
> > syntax. While the draft may be describing an existing scheme used in
> > some existing implementations, it needs changes before this draft goes
> > any further, otherwise it would lead to more duplication in the cache
> > than necessary.
> 
> I have to admit I've not closely looked at all of the text, but I have
> a couple of high level comments:
> 
> - Whether you like it or not, any protocol change will be out of scope
>   of this particular draft (although the result of IETF last call and
>   IESG decision might change that) - (in my understanding) that's the
>   decision the wg made quite a long time ago.  If you want to
>   introduce any final change, that will have to be something that
>   doesn't involve a protocol change.

Nod. (I also understand this has progressed on; my feeling is that it
should not have been adopted by dnsop at all, if we couldn't influence
it. It could've taken a different path, but I suppose I'm complaining
too late.)

> - From a quick read, the concern you raised seems to be related to the
>   case where more and less-specific prefixes are to be configured at
>   the ECS-supporting authoritative server.  In my understanding that
>   was actually one of the unclear points, but the wg decided to defer
>   any detailed discussions to a currently-imaginary successor of this
>   document.  You should be able to find some related discussions in
>   the dnsop list archive.

The -06 draft is poor quality.

For a reasonable ECS implementation (especially cache behavior) with the
current protocol, I feel there are still some restrictions that should
be included in the draft, like blinkers on a horse so it doesn't get
distracted. The protocol leaves a lot of stuff unspecified, and it needs
to be more specific and restrictive to be functional. There is a list of
issues that can be addressed by specifying behavior. With the current
spec, implementations have to make assumptions about these and they
would lead to interoperability issues among different flavours of
implementations.

Examples of issues:

- REFUSED vs. FORMERR (FORMERR is underlying DNS protocol, so I don't
  know how the draft is allowed to modify it, or how implementations
  would not work with FORMERR).

- Underspecfication of when REFUSED must be returned in case of FORMERR
  issues.

- Closely related behavior having different return codes (bad FAMILY
  returning FORMERR, whereas bad ADDRESS field returning REFUSED
  always) - section 6 vs. section 7.2.1

- Clear upfront description of FAMILY=0 behavior, including what goes in
  PREFIX-LENGTH fields, ADDRESS field, etc. in section 6.

- No specification of what "deaggregation" is. This is required for
  proper cache operation and is an interoperability concern. It should
  be clearly specified how answers are deaggregated based on both the
  zone data for different prefixes and also the SOURCE
  PREFIX-LENGTH. This algorithm is non-obvious and an implementation
  will not get it right by first-guessing. A mistake here would lead to
  incorrect caching on the resolver side, so it is an interoperability
  concern and is well within the scope of this document.

- The draft disagrees with itself on what happens if SCOPE > SOURCE
  PREFIX-LENGTH. SCOPE > SOURCE only makes more sense if there are more
  ADDRESS bits set in the reply message than in the query message.  In
  one place the draft says it should be processed (section 7.3 where
  only up to SOURCE PREFIX-LENGTH bits of ADDRESS need to be checked in
  the reply) whereas in another place it says that a reply with a
  mismatching ADDRESS field should be dropped (section 6).

  Also, the draft does not say what it *means* in the answer when it has
  SCOPE > SOURCE. This is not a reply to the question sent in the query
  message. A longer SCOPE may not be useful (even if the resolver finds
  the client in that subnet) as it reduces privacy if the client
  attempts to use that answer.

  It would seem that in proper ECS operation, SCOPE need never be
  greater than SOURCE. Why have this specified at all? The description
  in the draft is short.

* Option forwarding behavior, as specified in the draft, can lead to
  either ECS not be used for future queries when forwarding is REFUSED,
  or redundant fetches. Option forwarding would interfere with caching
  when the SOURCE PREFIX-LENGTH in the client query's option (to be
  forwarded) is *shorter* than the locally configured policy SOURCE
  PREFIX-LENGTH on an intermediate resolver. The draft makes no explict
  mention of this or how to workaround this.

* DNSSEC behavior and negative answer handling are underspecified. The
  draft contains 2 small paragraphs on DNSSEC (section 9). It is quite
  possible that operators will use different data sources for each
  subnet (e.g., different master files). In this case, how are negative
  proofs handled? A name may be missing in a data source, or an answer
  may be missing in the data source for a subnet whereas it exists in a
  different subnet. Section 7.4 leaves the possibility of negative
  answers being handled differently by implementations. It needs to be
  more restrictive, and DNSSEC behavior should be specified
  clearly. This is an interoperability concern for both implementations
  and operators.

* A personal peeve - I dislike how the address prefix lengths are named
  "SOURCE" and "SCOPE" instead of "QUERY" and "RESPONSE". Over all this
  time playing with this draft, I've made the error of typing/saying one
  instead of the other several times because they are so similar.

It's possibly still not too late for many of these issues to be
addressed by behavioral descriptions in the draft (without any protocol
changes).

		Mukund