Subject: Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-edns-client-subnet

From: Dave Lawrence <[email-masked]>
Date: Sun, 4 Oct 2015 11:49:22 -0400

Thank you, Jinmei, for your thoughtful feedback.

Jinmei writes:
> It would be nicer if it can be clarified before advancing
> it: are we expecting newer implementations are developed based on this
> specification, or is this document literally for describing the
> current practice for the record (and newer implementations should
> rather wait for more complete specification in the assumed revised
> publication)?  This point wasn't clear to me, and I hope it's more
> clearly stated in the final version of the document.

While I appreciate your overall point, I think in practical terms we
can't really expect the parenthetical above, that "newer
implementations should rather wait".  Even if I had that draft pushed
out right this very minute, realistically it'll be a year for it to
get through IETF review, and additionally have somewhat less incentive
for rapid adoption than the original draft did.

Anyone that wants to interoperate with the companies currently using
ECS in any "Internet-speed" timeframe is going to have to support this
method, which even with the minor flaws that has, is still basically
pretty good for addressing the original goals that motivated it.

That said, I can add this remark to the end of the introduction:

"A revised proposal to improve upon the minor flaws in this protocol
will be forthcoming to the IETF."

Is that reasonable enough to address your concern?

> Some more specific comments on the draft text follow, most of which I
> think are minor and non-blocking:

Thank you, I have incorporated most of these into our github version,
to be -05.

> - Section 4: the term "Forwarder" is used without a definition.  I
>   think it's often confusing (different people tend to use it for
>   different meanings), so it would be better to give its definition
>   for the purpose of this document.

This was one of the most interesting comments to me, because it
actually revealed a source of terminology confusion in the DNS for
which the document was at odds with other RFC usage.  The confusion is
not unlike that of "CNAME", as far as source and target are concerned.

A Forwarder in the RFC sense has been the target of forwarded queries,
while elsewhere (such as Microsoft Technet notes, and this document)
expect it to be a server that does the forwarding to another recursive.
(I suppose that would make the target a "Forwardee".)

I have added this definition, and changed occurrences of "Forwarder"
to "Forwarding Resolver":

   Forwarding Resolver  A nameserver that does not do iterative
      resolution itself, but instead passes that responsibility to
      another Recursive Resolver, called a "Forwarder" in [RFC2308]
      section 1.

>    o  SOURCE PREFIX-LENGTH, an unsigned octet representing the leftmost
>       significant bits of ADDRESS to be used for the lookup.
> 
>   I think it'll be more accurate if it says: "representing the number
>   of leftmost significant bits".  Same for SCOPE PREFIX-LENGTH.

Added "number of" to both.

> - Section 7.1.1
> 
>    An ECS-aware resolver MUST retry the query without ECS to distinguish
>    the response from a lame delegation, which is the common convention
>    for a REFUSED status.
> 
>   Is this true?  To me it's a rather unusual choice to indicate a lame
>   delegation.  For example, if I remember it correctly ISC BIND 9
>   returns SERVFAIL if all supposed-to-be-authoritative servers are
>   lame.

Right, a recursive would return servfail for its client, but it is
true for authorities, including BIND 9.9.7-P2 running at ISC:

$ dig whatever.whatever @ord.sns-pb.isc.org | grep status
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 12817

> - Section 7.2.1
> 
>    If the Authoritative Nameserver operator configures a more specific
>    (longer prefix length) Tailored Response within a configured less
>    specific (shorter prefix length) Tailored Response, then
>    implementations can either:
> 
>   Just checking: is this an attempt to address the suboptimal scenario
>   I raised in my review of a previous version of draft?

I'd have to dig up the history, honestly.

> - Section 7.4, first paragraph:
> 
>    The prohibition against tying ECS data to records from the Authority
>    and Additional section left an unfortunate ambiguity in the original
>    specification, primarily with regard to negative answers.  The
>    expectation of the original authors was that ECS would only really be
>    used for address records, the use case that was driving the
>    definition of the protocol.
> 
>   The second sentence sounds a bit awkward to me, since the issue of
>   negative answers should basically be irrelevant to whether the query
>   is for "address records".  Perhaps it's intended to explain the
>   background on the issue with delegation cases?

It was trying to describe that the main thing that was trying to be
accomplished originally was just to enable positive tailored responses
to address queries.  I've changed the second sentence to incorporate
this so it now reads, 

     "The expectation of the original authors was that ECS would only
     really be used for address requests and the positive result in
     the response's answer section, the use case that was driving the
     definition of the protocol."

> - Section 10
> 
>    Special awareness of ECS in devices that perform Network Address
>    Translation (NAT) as described in [RFC2663] is not required; queries
>    can be passed through as-is.  The client's network address SHOULD NOT
>    be added, and existing ECS options, if present, SHOULD NOT be
>    modified by NAT devices.
> 
>   I'm not sure if I fully understand the second sentence.  Does it
>   assume this NAT device acts as something like DNS-ALG?  If so, I
>   think it's better to say so more explicitly (RFC2663 is quite
>   broad).

I'm really not sure how to meaningfully change this.  The second
sentence seems fairly clear to me in saying "look, just don't even
muck with ECS".  Please let me know if you have specific text to make
it better.

> - Section 10
> 
>    In other cases, Recursive Resolvers sited behind a NAT device SHOULD
>    NOT originate ECS options with their external IP address, and instead
> 
>   Does this assume that the operator of the recursive resolver knows
>   it's behind a NAT and configures that way?  If so, I'd suggest
>   stating that explicitly.  In its current form it could read as if
>   the recursive server implementation somehow automatically detects
>   that it's behind a NAT (it might be possible but not very trivial),
>   and therefore sounds a bit awkward to me.

No, I agree with you that it is unreasonable to expect a resolver to
know it is behind a NAT, and the section was attempting to exonerate
them from that.  I changed "Recursive Resolvers sited behind a NAT"
here to "if a Recursive Resolvers knows it is sited behind a NAT".

> - Section 12.1
> 
>    Additionally, Recursive Resolvers SHOULD be configured to never send
>    the option when querying root, top-level, and effective top-level
>    domain servers.
> 
>   I suspect the meaning of term "effective top-level domain" is not
>   very clear (I actually have almost no idea about what it is -
>   something like "co.jp"?).  If there's a reference I'd add it.
>   Otherwise, I'd explain what it intends to mean more specifically.

New text for that sentence:

   Additionally, Recursive Resolvers SHOULD be configured to never send
   the option when querying root, top-level, and effective top-level
   (ie, "public suffix") [6: https://publicsuffix.org/] domain servers.

I know there is ongoing discussion in the IETF dbound group about
these delegation-centric domains and terminology around them, and if
someone thinks that better text or an alternative link is needed here
I'd be happy to substitute it.

> - Section 15: s/Internet Software Consortium/Infoblox/ (please keep my
>   current employer happier:-)
> 
>    ... Tatuya Jinmei from Internet Software Consortium;

Done.

---

From: Suzanne Woolf <[email-masked]>
Date: Sun, 4 Oct 2015 13:19:23 -0400

Admin note: the WGLC has concluded. Thanks everyone for your comments, and the authors for addressing them. We'll be reviewing all of the correspondence with the authors and have an official followup soon on moving this draft forward.

Suzanne & Tim

---

From: Wilmer van der Gaast <[email-masked]>
Date: Mon, 5 Oct 2015 11:40:54 +0100

On 30 September 2015 at 20:50, dagon <[email-masked]> wrote:
> [...]
>   I wonder if the logic of this section would not apply to any NS that
>   answers in delegation?  Surely ECS only helps subsequent
>   tcp/{80,443} flows, and the odd tcp/53 flow from the recursive does
>   not need similar acceleration through network localization.
>
Correct. Not only that, keep in mind ECS is about the end user
location, not about the resolver location, so it doesn't make sense
anyway to use ECS info to change the delegation and supporting it
anyway would only add more complexity to the already complicated
resolver.

Note how section 7.3.1 already mentions by the way that ECS only
applies to the ANSWER section so this is already in the draft.

>   Of course, this would require white lists to index not only by the
>   IP, but also then blacklist the NS by zone, in a last-match rule
>   system.  And as an aside, if my requests for yet another pony have
>   worn out anyone's patience, please accept my apologies.
>
> Summary: The document might simply describe the EDNS0 payload with
> reference to qname minimization principles.  Such data is ripe for
> cutting when iterating upwards, and even if ECS recursives don't
> expand to exclude all zone cuts, perhaps q-min implementations might
> address my suggestion for expanding beyond {g,e,n}TLD/root exclusion.
>
So: I do like this idea, though indeed it means whitelisting based on
zone instead of IPs. From what I can remember that is not necessarily
a problem, only with authorities supporting ECS is IP-based-only a
requirement to make auto-detection work. The other way around, there
are no such issues from what I can tell.

I'd however avoid over-complicating things as the current draft is
already extremely hairy and complicated for what it really is - I'd
take the idea above if it would provide useful simplification, i.e. by
being able to just refer to existing common practice for other
purposes than ECS.

My 2 cents as an emeritus author.

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

---

From: 神明達哉 <[email-masked]>
Date: Mon, 5 Oct 2015 13:02:06 -0700

At Sun, 4 Oct 2015 11:49:22 -0400,

> pretty good for addressing the original goals that motivated it.

I interpret this as the answer to my question is "we expect newer
implementations are developed based on this specification".  And we're
going to publish it even if we know there are several technical flaws.
Our mileage may vary about how "minor" they are, and I myself wouldn't
say they are super critical, but if they are really super minor we
should have been able to clean them up in this draft quickly, so they
should be at least somewhat non-trivial.

To be clear, I'm not necessarily opposed to that decision; the IETF is
notorious about its very long timeframe, and it may just not make
sense to go through all the overhead if we see some immediate needs
for a relatively solid reference if not complete.  But I believe it's
irresponsible to obscure the intent as a means of avoiding possible
pushbacks and getting it through faster (you probably didn't intended
that, but for an external observer it could look that way).  I believe
because the new developers should be able to act based on "informed
consent".

I'm not sure if this view is shared by others - this is more or less a
matter of opinion so if I'm a clear minority I won't be able to
persuade many others just by keeping the discussion.  So in that case
I'll simply shut up.

But...

> Is that reasonable enough to address your concern?

as you're at least suggesting some additional text (thanks for that,
but that does not fully address my points), I'd offer mine: revise the
following part of the last paragraph of Section 1:

   While they interoperate for the primary goal, they have varying
   behaviour around poorly specified edge cases.  Known
   incompatibilities will be described.  The authors believe that it is
   better to document this system, even if not everyone agrees with the
   concept or the details of the original specification, rather than
   leave it undocumented and proprietary.

as something like this:

   This document describes the protocol that is currently used by
   those early adopters in the hope that new implementations can be as
   interoperable as those currently deployed.  However, the existing
   implementations vary behaviour around poorly specified edge cases,
   and several technical issues that can cause interoperability
   problems have been identified through the review process of the
   document.  Some of those issues are described in this document but
   are not necessarily resolved.  The authors believe that it is
   better to document this system, even if not everyone agrees with the
   concept or the details of the original specification, rather than
   leave it undocumented and proprietary, so that more implementations
   will work with moderate interoperability sooner than later.  A
   revised proposal to improve upon the identified flaws in this
   protocol will be forthcoming to the IETF.

(note: it includes a revised "The authors believe..." sentence, but
obviously I can't speak for the authors.  This is just based on my
guess of what the authors intended).

> true for authorities, including BIND 9.9.7-P2 running at ISC:

Hmm, I guess I'm now (more) confused...the sentence before this one
is:

   [...]  If
   the Recursive Resolver will not forward the FAMILY and ADDRESS data
   from the incoming ECS option, it SHOULD return a REFUSED response.

so I thought the "ECS-aware resolver" is a resolver that receives a
response from the Recursive Resolver.  And my question was whether
it's really "the common convention" that a Recursive Resolver returns
a REFUSED when it encounters a lame delegation.  I don't know if this
suggests the need for revising the text, but if only to educate me
some more explanations on exactly what kind of situation is intended
might help.

> I'd have to dig up the history, honestly.

This (and other links referenced in the message) will probably help:
http://www.ietf.org/mail-archive/web/dnsop/current/msg13428.html

and this one is related to my "high level question".  Especially if we
envision that more implementations based on this document will be
developed and deployed but we are not willing to resolve technical
issues identified so far, I think the current text is a bit
irresponsible.  I'd at least explain the following:

- a mixture of more/less specific prefixes can lead to
  interoperability problems
- what the current practice does for these today (e.g., simply avoid
  having such a configuration, or it has been just lucky not to have
  this setup, etc)
- (assuming that's the intent) this point will be clarified more
  explicitly in the expected revised specification

> muck with ECS".  Please let me know if you have specific text to make

I don't think I can offer any specific text unless my question is
answered...perhaps I can suggest something if at least it clarifies
specifically what "perform Network Address Translation (NAT) as
described in [RFC2663]" means.  Anyway, if it's only me who are
confused, I wouldn't be opposed to it if my question is just ignored.

--
JINMEI, Tatuya

---

From: Dave Lawrence <[email-masked]>
Date: Mon, 5 Oct 2015 20:28:34 -0400

Jinmei writes:
> going to publish it even if we know there are several technical flaws."

Yes, your interpretation of the answer is correct.  But it's an
Informational draft, describing existing practice.  We don't really
have a lot of latitude to fix even the minor issues here, in my
opinion, without making the draft even bigger and more complex and
describing something that existing implementations are not doing.

> but that does not fully address my points), I'd offer mine:
> 

This seems basically fine with me, and I'll consult with the other
authors and the chairs.

> > >    the response from a lame delegation, which is the common convention
...
> 
> Hmm, I guess I'm now (more) confused... I thought the "ECS-aware
> resolver" is a resolver that receives a response from the Recursive
> Resolver.  And my question was whether it's really "the common
> convention" that a Recursive Resolver returns a REFUSED when it
> encounters a lame delegation.  I don't know if this suggests the
> need for revising the text, but if only to educate me some more
> explanations on exactly what kind of situation is intended might
> help.

Ahhh I see your overall point now, because you're absolutely right
that in that context of a recursive to its client, REFUSED is not used
for signaling lame delegations.  I'll see what I can do to shift some
things around to make it clearer that the overloaded meaning of the
REFUSED response needs to be resolved for the
recursive<->authoritative interaction.

> http://www.ietf.org/mail-archive/web/dnsop/current/msg13428.html

I didn't write the text you're referring to, but yes I believe it was
an attempt to address it, and I think it's sufficient because we're
really not getting into the details about how authorities come up with
answers, which is why this was kind of a hand-wavy, "you should be
aware of this issue and figure out some way to deal with it in your
own situation".

>   interoperability problems

This depends on how you define interoperability problems.  The
protocol itself will work.  I think making implementers of
authoritative ECS systems aware that the order in which the CIDRs are
filled matters is sufficient warning to have them figure out how to
manage the issue.  Recursives, on the other hand, can't really do
anything other than cache what the authority tells them, no matter
what the draft says.

> > >    Translation (NAT) [...]
> > I'm really not sure how to meaningfully change this.  [...]
> 
> I don't think I can offer any specific text [...]
> Anyway, if it's only me who are confused, I wouldn't be opposed to
> it if my question is just ignored.

For the record, I'm explicitly not ignoring this, but I'm personally
still at a loss for what to do about it and am still inclined to leave
the NAT section as-is.

---

From: 神明達哉 <[email-masked]>
Date: Tue, 6 Oct 2015 09:29:03 -0700

At Mon, 5 Oct 2015 20:28:34 -0400,

[...]
> This seems basically fine with me, and I'll consult with the other

Okay, if something like this is acceptable, my high-level point will
be basically addressed.

> anything other than cache what the authority tells them, no matter

For these I do not necessarily agree, but I can live with that if the
introduction is revised to something we discussed above.

> still at a loss for what to do about it and am still inclined to leave

I was probably not clear, I didn't intend to say you're ignoring this
point.  I tried to say I'm okay with the current text if others don't
see a problem in understanding it.  I don't know about others, but
since neither you nor I can suggest something specific, and since this
is quite minor, I'm fine with just forgetting the point.

--
JINMEI, Tatuya

---

From: Suzanne Woolf <[email-masked]>
Date: Fri, 9 Oct 2015 18:47:09 -0400

Dear Colleagues,

This Working Group Last Call has concluded, and we've seen consensus support to send the document on to the IESG.

Thanks to everyone who spent their time and effort on reviews and discussion, and to the authors for their careful attention to addressing the comments.

Suzanne & Tim

---

From: abby pan <[email-masked]>
Date: Mon, 12 Oct 2015 02:08:05 +0000

FORMERR maybe a choice ?

Ted Lemon <[email-masked]>于2015年9月17日周四 上午6:07写道：

> It would be helpful if the authors could explain why the REFUSED response
> is being used here.   Realizing that the current version of the document is
> intended to document existing practice, nevertheless, strongly recommending
> the use of REFUSED here is a bad idea, as can be seen from the advice that
> immediately follows, which is to retry if REFUSED is received.
>
> Do people think this is the right thing to do, or is it just one of those
> things that snuck in because nobody wanted to do an IANA allocation?   My
> preference would be to allocate a new EDNS0 response code, point out that
> existing implementations do something different, which behavior is actually
> a bad idea, and recommend against adding such behavior to new
> implementations.
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>
-- 

Best Regards
Pan Lanlan