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

From: 神明達哉 <[email-masked]>
Date: Tue, 2 Feb 2016 11:31:34 -0800

At Mon, 28 Dec 2015 07:59:14 +0530,
Mukund Sivaraman <[email-masked]> 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.
- 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.

--
JINMEI, Tatuya

---

From: Mukund Sivaraman <[email-masked]>
Date: Wed, 3 Feb 2016 09:31:31 +0530

Hi Jinmei

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

>   document.  You should be able to find some related discussions in

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

---

From: Mukund Sivaraman <[email-masked]>
Date: Wed, 3 Feb 2016 09:34:00 +0530

Hi Jinmei

Examples of issues:

		Mukund

---

From: 神明達哉 <[email-masked]>
Date: Wed, 3 Feb 2016 10:43:53 -0800

At Wed, 3 Feb 2016 09:31:31 +0530,

> addressed by behavioral descriptions in the draft (without any protocol

I agree at least *some* of the issues have to be addressed before
publication.  I already agreed on some specific issues you raised
before: http://www.ietf.org/mail-archive/web/dnsop/current/msg16361.html

You might also want to respond to the IETF last call on the draft
http://www.ietf.org/mail-archive/web/dnsop/current/msg16223.html
before the IESG makes their decision.  (The last call period was
officially over, but I believe belated feedback can be considered if
it's substantial).

--
JINMEI, Tatuya

---

From: Yuri Schaeffer <[email-masked]>
Date: Thu, 4 Feb 2016 11:51:31 +0100

I have a hard time understanding your need for DIRECTION and DEPTH,
and would argue you'd have enough information as is.

> 
> IPv4 root [A2(/0)**] /  \ 0b0.. /    \ 0b1.. /      \ A2(/1)    X /
> \ /   \ 0b10.. /     \  0b11.. /       \ A2(/2)      X / \ /   \ 
> 0b110..   /     \ 0b111.. /       \ A2(/3)    A1(/3)
> 
> 
> ** This is the global answer, but the auth server shouldn't send
> it.
> 
> (...)
> 
> I add that there is still confusion on what happens with the scheme
> in the current draft, if the resolver queries with 
> client-subnet=128.0.0.0/1. The authoritative server has two answers
> in this network. Does it send A1 or A2? If it sends A2, with scope 
> prefix-length=1, that'll be used from cache for future resolver
> queries where client-subnet=223.0.0.0/3.

That would be used yes. Therefore as a caching resolver I would not
expect the authority to reply with SCOPE=1. I would expect in this
case either
	(A2) 128.0.0.0/1/2  ("give me a bit more and I have it more specific")
or
	(A2) 128.0.0.0/1/3 ("Give me et least 3 bits and I'll have THE answer."
)

In any case it would answer with A2 because given the information
provided this is the most specific answer (it gets it from the root of
the tree).

Now as a caching resolver the next time I do a cache lookup for say
client 128.1.2.3 I would find the cache entry "128.0.0.0/1/3" thus
giving me two choices:

A) I'm willing to share more bits. So I query the authority with
SOURCE 3. (Or maybe lower if my policy says so)

B) My policy mandates SOURCE cannot exceed 1 and I'll use the cache
entry. The authority wants more but is not getting it from me.

> A1 may not be correct as the client behind the resolver (that is
> hidden by policy) may be in 224.0.0.0/3. The draft says:
> 
>> If an Intermediate Nameserver receives a response which has a
>> longer SCOPE PREFIX-LENGTH than the SOURCE PREFIX-LENGTH that it
>> provided in its query, it SHOULD still provide the result as the
>> answer to the triggering client request even if the client is in
>> a different address range.
> 
> Operators who use this feature ought to be careful in designing
> their network. For example, there is a possibility that an address
> record may be sent to a client which has no route to it if the
> address is local to some other network.

You seem to imply that a SCOPE > SOURCE means an answer from further
down the tree. But I think it doesn't, or at least it shouldn't. The
SCOPE is not tied to an answer but rather used as an indicator how
many bits the authority needs/wants for the most/more specific answer.

//Yuri

---

From: Mukund Sivaraman <[email-masked]>
Date: Thu, 4 Feb 2016 16:47:10 +0530

Hi Yuri

> provided this is the most specific answer (it gets it from the root of

The draft doesn't state that the answer is for the SOURCE PREFIX-LENGTH
when SCOPE > SOURCE. At all other times, the answer is meant to be
cached at the SCOPE PREFIX-LENGTH.

I quote the draft (all that's there on the topic):

>  The SCOPE PREFIX-LENGTH in the response indicates the network for
>  which the answer is intended.
>
>  A SCOPE PREFIX-LENGTH value longer than the SOURCE PREFIX-LENGTH
>  indicates that the provided prefix length was not specific enough to
>  select the most appropriate Tailored Response.  Future queries for
>  the name within the specified network SHOULD use the longer SCOPE
>  PREFIX-LENGTH.
	       
Where does it say that the answer is for the SOURCE PREFIX-LENGTH?

> many bits the authority needs/wants for the most/more specific answer.

So you are saying that your assumption is more correct than my
assumption. :) That may be so, but both are assumptions and because we
can both assume whatever we want, it would be best to describe what the
correct meaning and behavior is in the draft, wouldn't you agree?

Having the auth and resolver sides doing different things in different
flavours of implementation would lead to incorrect caching.

		Mukund

---

From: Yuri Schaeffer <[email-masked]>
Date: Thu, 4 Feb 2016 12:57:52 +0100

Hi Mukund,

> The draft doesn't state that the answer is for the SOURCE
> PREFIX-LENGTH when SCOPE > SOURCE. At all other times, the answer
> is meant to be cached at the SCOPE PREFIX-LENGTH.

I indeed use SCOPE to determine where the answer would fit in the tree
in my cache. But that doesn't mean I discard SOURCE. I still need
SOURCE to determine if this cache entry is applicable to the next
query. There's no contradiction here.

>> The SCOPE PREFIX-LENGTH in the response indicates the network
>> for which the answer is intended.
>> 
>> indicates that the provided prefix length was not specific enough
>> to select the most appropriate Tailored Response.  Future queries
>> for the name within the specified network SHOULD use the longer
>> SCOPE PREFIX-LENGTH.

Even without it being mentioned explicitly it is clear to me that this
text means I get a suboptimal response given the SOURCE PREFIX-LENGTH
provided. Not that I would get a /wrong/ response.

>> You seem to imply that a SCOPE > SOURCE means an answer from
>> further down the tree. But I think it doesn't, or at least it
>> shouldn't. The SCOPE is not tied to an answer but rather used as
>> an indicator how many bits the authority needs/wants for the
>> most/more specific answer.
> 
> assumption. :) That may be so, but both are assumptions and because
> we can both assume whatever we want, it would be best to describe
> what the correct meaning and behavior is in the draft, wouldn't you
> agree?

I agree.
But before describing it I would like to convince you my assumption is
more correct. ;)

> Having the auth and resolver sides doing different things in
> different flavours of implementation would lead to incorrect
> caching.

Meh. Suboptimal responses maybe. If you tell me something
authoritatively don't blame me for caching it.

//Yuri

---

From: Mukund Sivaraman <[email-masked]>
Date: Thu, 4 Feb 2016 18:16:21 +0530

Hi Yuri

> query. There's no contradiction here.

I don't follow. Are you saying you are saving the SOURCE PREFIX-LENGTH
from the original query (responsible for the cache entry) alongside the
cache entry? If so, I don't follow why this is required. Can you
explain?

Or do you mean the use of SOURCE PREFIX-LENGTH from a subsequent query
when looking into the cache?

		Mukund

---

From: Yuri Schaeffer <[email-masked]>
Date: Thu, 4 Feb 2016 14:50:48 +0100

> I don't follow. Are you saying you are saving the SOURCE
> PREFIX-LENGTH from the original query (responsible for the cache
> entry) alongside the cache entry?

Yes.

> If so, I don't follow why this is required. Can you explain?

Certainly!

Suppose I query for 128.0.0.0/4 and get the response is 128.0.0.0/4/8.
And suppose I would cache it like:

A)	128.0.0.0/?/8

That is, discard the SOURCE PREFIX-LENGTH.

Maybe I also ask for 129.0.0.0/8 for which the authority replies with
the same SCOPE. My cache now contains:

A)	128.0.0.0/?/8
B)	129.0.0.0/?/8

Suppose again I want to have an answer for 128.0.0.0/4. Which cache
entry would be correct - if any? Do I need to requery the authority?
Do I need to consider the bits from the client address that where
masked? Or would I pretend the mask bits are 0? I can't decide, but I
sure like to use my cache rather than asking the authority!

If I had saved this in my cache:

A)	128.0.0.0/4/8
B)	129.0.0.0/8/8

The answer should be obvious: "A". The server wants to receive 8 bits
information but this is the answer I would have got when I would
provide just 4.

As said before, at this point I could also decide to requery and
disclose more bits. But it'll be my choice. I'm not giving up my
privacy just because someone asks nicely.

> Or do you mean the use of SOURCE PREFIX-LENGTH from a subsequent
> query when looking into the cache?

I did not mean that. Though the SOURCE PREFIX-LENGTH I'm working with
might limit me how far down the tree I will look for an answer.

//Yuri

---

From: Mukund Sivaraman <[email-masked]>
Date: Thu, 4 Feb 2016 20:13:39 +0530

Hi Yuri

> information but this is the answer I would have got when I would

Is this example for considering that a 128.0.0.0/4/8 answer is different
from a 128.0.0.0/4/4 answer when both are available answers to be
returned by an auth for a 128.0.0.0/4/0 query? Other than that, I don't
see what saving SOURCE PREFIX-LENGTH seperately alongside
<address,address-prefix-length> would provide. If both answers were
treated identically, it can be cached at 128.0.0.0/4.

If any one of these two different answers is found in cache, from the
description above, you'd use it and not fetch from authority (where you
might get the other answer for a 128.0.0.0/4 query). I.e., this is no
different from caching at /SOURCE when SCOPE > SOURCE.

A 128.0.0.0/4/0 query will only have the first 4 ADDRESS bits set.  So
if we consider that a SCOPE > SOURCE answer is an answer to the question
at all, the answer is only valid for those first 4 ADDRESS bits, i.e.,
SOURCE PREFIX-LENGTH bits. There are no more defined bits in
ADDRESS. The answer's ADDRESS field has to equal the query's ADDRESS
field.

It seems the scheme you are describing to save the SOURCE PREFIX-LENGTH
is used in distinguishing between /SOURCE/SOURCE and /SOURCE/(>SOURCE)
answers. It was in reply to this comment:

> PREFIX-LENGTH when SCOPE > SOURCE. At all other times, the answer is
> meant to be cached at the SCOPE PREFIX-LENGTH.

You are describing what you're doing in implementation. I hope you
understand my concern that none of the above is specified.

		Mukund

---

From: Mukund Sivaraman <[email-masked]>
Date: Thu, 4 Feb 2016 20:55:55 +0530

> different from caching at /SOURCE when SCOPE > SOURCE.

I thought of one case where saving a longer *SCOPE* separately apart
from the caching address prefix length can be useful.  This is in case
the resolver is a ECS option forwarder (intermediate) and wants to
provide the same syntax response /SOURCE/(>SOURCE) in its reply message
to the downstream resolver.

In practice, a resolver implementation wouldn't use a longer prefix when
it has a shorter source prefix configured as policy. This is why there's
the question of why the spec even talks about sending SCOPE > SOURCE
assuming the answer section is for ADDRESS/SOURCE/SOURCE.

		Mukund

---

From: Yuri Schaeffer <[email-masked]>
Date: Thu, 4 Feb 2016 16:36:44 +0100

> Is this example for considering that a 128.0.0.0/4/8 answer is
> different from a 128.0.0.0/4/4 answer when both are available
> answers to be returned by an auth for a 128.0.0.0/4/0 query?

Both 128.0.0.0/4/8 and 128.0.0.0/4/4 could satisfy a 128.0.0.0/4/0
query. But the former *might* motivate me to requery for 1XX.0.0.0/8.

I always read the document as, when receiving a SCOPE > SOURCE answer,
use it to answer the client. But do not use it to reply from cache for
future queries. Ofcourse as an implementer I would still cache it
because I don't want to disclose as much bits as the authority asks
for, but still have caching.

> Other than that, I don't see what saving SOURCE PREFIX-LENGTH
> seperately alongside <address,address-prefix-length> would provide.
> If both answers were treated identically, it can be cached at
> 128.0.0.0/4.

This might be the source of confusion? I don't see a difference
between 'address-prefix-length' and 'SOURCE PREFIX-LENGTH'. Are we in
the end arguing the same thing?

> If any one of these two different answers is found in cache, from
> the description above, you'd use it and not fetch from authority
> (where you might get the other answer for a 128.0.0.0/4 query).
> I.e., this is no different from caching at /SOURCE when SCOPE >
> SOURCE.
> 
> A 128.0.0.0/4/0 query will only have the first 4 ADDRESS bits set.
> So if we consider that a SCOPE > SOURCE answer is an answer to the
> question at all, the answer is only valid for those first 4 ADDRESS
> bits, i.e., SOURCE PREFIX-LENGTH bits. There are no more defined
> bits in ADDRESS. The answer's ADDRESS field has to equal the
> query's ADDRESS field.

Yes!

> It seems the scheme you are describing to save the SOURCE
> PREFIX-LENGTH is used in distinguishing between /SOURCE/SOURCE and
> /SOURCE/(>SOURCE) answers. It was in reply to this comment:
> 

I understand your concern. I myself am not a fan. OTOH I don't see a
particular problem in this case. Even if implementations don't do
exactly the same.

//Yuri