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

From: Suzanne Woolf <[email-masked]>
Date: Wed, 16 Sep 2015 12:05:58 -0400

Colleagues,

This begins the working group last call for draft-ietf-dnsop-edns-client-subnet, "Client Subnet in DNS Queries.” The document has gotten significant feedback and the editors have worked hard to document current use of the client-subnet EDNS option.

We’re seeking consensus to advance it to the IESG with an intended status of Informational. If you support it, please say so. If you don’t, please say why.

The current version is at: http://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-client-subnet/ <http://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-client-subnet/>

Last Call will run for two weeks, closing on Wednesday Sept. 30. 

thanks,
Suzanne & Tim

---

From: George Michaelson <[email-masked]>
Date: Wed, 16 Sep 2015 15:38:58 -0300

I have read the draft. I am collecting information carried in EDNS0
client_subnet and have been running modified authoritative state
server-side in order to tickle it out, and I am happy with what I see. It
ain't perfect but its pretty good.

I like that the draft is reasonably clear about the known unknowns and
canvasses future work. I also like that the draft doesn't hide away from
the downside risks in ECS.

I support this draft going to informational.

-G

---

From: Ted Lemon <[email-masked]>
Date: Wed, 16 Sep 2015 18:06:55 -0400

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.

---

From: "Paul Hoffman" <[email-masked]>
Date: Wed, 16 Sep 2015 19:20:00 -0700

Greetings. I have reviewed the latest version of this document and think 
that it ready for publication as an Informational RFC. It covers more of 
the relevant related topics than the draft that the WG adopted, and is 
clearer in many places. I'm not an implementer so I can't say whether or 
not it reflects many or most of the implementations out there, but I 
feel that if I were to implement this, it probably answers all my 
questions and gives me good usage scenarios.

--Paul Hoffman

---

From: Dave Lawrence <[email-masked]>
Date: Wed, 23 Sep 2015 16:40:37 -0400

Ted Lemon writes:
> It would be helpful if the authors could explain why the REFUSED
> response is being used here.

Not to be glib, but because that's what Wilmer originally specified.
That's thus what got implemented by the existing implementations (and
there are more than you'd likely imagine, too).  

> Do people think this is the right thing to do

No, I don't.  Thus I'm working on addressing that and several other
protocol issues in a new draft.

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

This is what I intend to do.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 24 Sep 2015 08:42:16 -0400

> there are more than you'd likely imagine, too).  

Thanks, that’s what I expected.  My concern is that the document currently states this unapologetically, so a reader who does not know the context might be tempted to implement it that way.   The way the document is written at present is as if it is a protocol specification intended to be implemented.   There is no applicability statement that says something like "there are a lot of problems with this version of the spec, and you should wait and implement version 2 if you don’t already have an implementation or need to interoperate with version 1."   I think the document needs to have some clear language restricting its applicability, and I also think that in cases where what was done in version 1 was obviously wrong, the document should say so.

I think it’s actually harmful to publish the version 1 document as an RFC without the version 2 document, to be honest.   I get why you want to do it in two steps, but from where I’m sitting this feels like an unfortunate decision if the first step is to publish something that looks like a perfectly valid spec and then the spec that does things the right way comes possibly much later on.

---

From: "John Dickinson" <[email-masked]>
Date: Thu, 24 Sep 2015 13:52:15 +0100

> Thanks, that’s what I expected.  My concern is that the document currently states this unapologetically, so a reader who does not know the context might be tempted to implement it that way.   The w…

I agree, when I last read this I had the IESG Note in my head (and I already knew that this was just documenting existing deployments). Looking again, I suggest that the IESG Note be moved to the main text and not be removed prior to publication.

John

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

John Dickinson

http://sinodun.com

Sinodun Internet Technologies Ltd.
Magdalen Centre
Oxford Science Park
Robert Robinson Avenue
Oxford OX4 4GA
U.K.

---

From: Dave Lawrence <[email-masked]>
Date: Thu, 24 Sep 2015 09:24:37 -0400

John Dickinson writes:
> I suggest that the IESG Note be moved to the main text and not be
> removed prior to publication.

I agree, and am making some edits today for review by the co-authors.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 24 Sep 2015 10:51:31 -0400

> I agree, when I last read this I had the IESG Note in my head (and I already knew that this was just documenting existing deployments). Looking again, I suggest that the IESG Note be moved to the m…

I think an IESG note is what happens when the authors don’t agree.   In this case it sounds like Dave is on board with clarifying the applicability, and that seems like a much better outcome.  (Thanks, Dave!)

---

From: dagon <[email-masked]>
Date: Mon, 28 Sep 2015 17:40:20 -0400

On Wed, Sep 16, 2015 at 12:05:58PM -0400, Suzanne Woolf wrote:

>  The current version is at:
> http://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-client-subnet/
> <http://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-client-subnet/>

I have some concerns, which I describe below.  I've attempted to offer
constructive improvements, but fell short of detailed suggestions.  My
comments are lengthy, even by my standards, so my general observations
are summarized:

1)  "The cost/benefit ratio must not divide by zero".

   -- The draft might account for situations where the zone offers no
      localized records, yet the authorities nonetheless engage in the
      protocol.  (I.e., the authorities witness user network
      information, because of whitelisting, but offer only non-diverse
      answers to any such query.  All cost; no benefit.)

   -- I motivate this issue by describing a global survey of who is
      using the protocol, and whethery they actually have need for
      CDN-services, based on active and passive enumeration of their
      zone content.  A category of such authorities, mainly
      governments, have their authorities whitelisted, but do not
      offer localized responses.  I suggest they are unlikely to
      engage in localized content, for policy reasons,

  ==> Perhaps the whitelisting process may account for this situation,
      to avoid undesired information transfer, when the authority
      objectively cannot improve or localize the user's subsequent TCP
      sessions.  (I.e., any implicit cost/benefit ratio considered by
      the draft might guard against DIVZERO.)

2) "Protocol implementations should avoid surprise".

   -- The privacy considerations might be improved, to consider
      situations where proxies are used for TCP traffic, but not UDP.
      There are numerous VPNs, web proxies, and privacy technologies
      that behave this way, and the protocol would now transmit user
      information to authorities, all while the users direct TCP
      through a proxy.  Likely this is not desired.  Perhaps the draft
      can address this, somehow.  

   -- I'm skeptical users should signal a desire for protocol
      avoidance in such situations, since this merely makes their
      sensitive data uses easier to identify.  Perhaps the best one
      might do here is counsel network operators who recommend
      protocol-enabled recursives, who formerly were viewed a mixnets
      in which to hide the non-proxied udp/53 traffic separate from
      the (vpn, http proxy) tcp traffic.

   -- To motivate this, I conducted an experiment, to induce such
      'information loss' for various TCP-only services.  This included
      some anonymity networks such as hidden services, and others.

  ==> While the draft might remain agnostic about such events (or view
      it as the responsibility of the user or 3d party tool maker),
      some discussion is warranted, to avoid surprise.

3) "Not All Queries Prognosticate Impending Real-Time TCP"

   -- There is no need, as far as I can tell, for protocol responses
      in certain query types.  E.g., PTR?, which is not necessarily or
      reliably an indicator of an immediate user TCP session.
      Likewise, not all answers preceding a "real time" user TCP
      session require balancing (or the rrtype already includes some
      implicit weighing/distance metrics, or the protocol is
      queue-based on and not real-time, e.g., MX, suggesting perhaps
      that localized responses are not needed.)

  ==> PTR, MX, and other records might be excluded in the draft, or
      the draft amended to suggest a type-specific consideration by
      the protocol implementors.  Or, perhaps improved whitelisting
      methodologies might be described.
       
In detail:

The current draft states that it "provides recommendations on when
this protocol extension should be used."

One early recommendation suggests that the "option will primarily be
used between Recursive Resolvers and Authoritative Nameservers that
are sensitive to network location issues."  (Section 5, "Overview").
I would recommend stronger wording than 'primarily' (either here or in
other places).

Following a survey of all NS one could discover (zone AXFR, NS queries
to parent and child NS, passive DNS, etc.) and also reach (via
instrumented DNS probes), it appears that edns-client-subnet ("ECS")
is widely used in situations where it provides no benefit to users.
For example, in a survey of the NS for the 'top million' domains
(however that is defined, e.g., Alexa), I can identify many
nameservers that:

  -- Are authority for a given zone, and few other zones (i.e., they
     are not likely a commercial provider, who enabled ECS by
     default).

  -- Have, according to passive dns and geo-diverse interaction with
     the authority (i.e., open recursive probes from diverse /24s)
     only one RRset to offer.  (Informally, there's only one possible
     answer in the only NS serving the zone, and no possible
     location-based service improvement.)

  -- Are not anycasted.

  -- Speak ECS to my iterative probes.  (Informally: With this, I
     presume they are whitelisted by existing ECS recursive
     implementers, either automatically or as a candidate for likely
     manual listing).

  -- Have low TTLs.  (Admittedly, that term is not well defined, and
     there's a long-term trend towards short TTLs for agility and
     expedited 'event' recovery).

  -- In many cases, are governments, hosting their own non-CDN
     infrastructure.

A note on that last item: To be clear, there's nothing wrong with
governments implementing ECS on their nameservers, and with recursives
sending them user network data.  But a survey of the 'top ECS'
implementers shows that many use ECS, despite having 'singleton
RRsets'.  (I.e., there's no evident CDN balancing of the zone, or
'benefit' to weigh against the privacy 'cost'.)  I only noted the
prevalence of this last property by accident, when reasoning about why
some zones collected user network information, but did not appear to
use it any witnessed response (either through my probes, or as
evidences via passive DNS).  

I decided to note that some are governments, merely to underscore
their status as political authorites, who for policy reasons are
unlikely to export their DNS authorities.  (I.e., if they've not
engaged commercial secondaries to date, and keep all authority
operations "in country" on on their own networks, they'd seem less
likely to do so in the future.  Thus, they do not need (and as
governments, are unlikely to want) commercial ECS-enabled secondary
services.  I do not know why some, who offer no localized answers
anyway, took the trouble to enable to the protocol (and presumably
become ECS whitelisted.)

But focusing on just the top four items noted above, I suggest that
the draft include language that recommends against/prohibits
ECS-whitelisting such 'RRset singletons'.  Apart from the 'sexy'
question of why some organizations use ECS in their otherwise simple
zones, either by accident of service contract or explicit intent, we
objectively can measure that there's no demonstrated engineering
benefit from sending user address information to authorities for
non-diverse zone records.  I.e., this is the 'DIVZERO' problem for a
cost/benefit reasoning about the protocol.

To fully understand the potential loss of privacy, I decided to try
and 'abuse' ECS myself: what can be learned about user network
origins, while at the same time providing no answer diversity?  I set
up some domains associated with the follow categories of interests:
document leaking, torrent use, bitcoin, and tor hidden service use.  I
had the authorities for the associated domains ECS whitelisted, and
witnessed the following from the authority logs:

   -- Because of DNS prefetching, I now see (at a /24 level) the IPs
      of hosts visiting specific pages on sites such as Wikileaks
      forums, various torrent sites, and some tor hidden services.
      This observation even holds after controling for zone scraping,
      hosts that appear to just resolve everything, academic and
      industry researchers, and the normal "DNS radiation" that comes
      from NS delegation.  

      And because the hosts also had associated http content, I could
      eliminate ECS data that came as a result of attempted http
      scraping (e.g., web crawlers/indexers) or actual user visits.

      That is, I can craft an ECS-lit zone to observe when users visit
      a 3d party forum or exhibit an interest in a given topic, even
      if they don't visit my site (due to DNS prefetching).

   -- I can in some instances identify (again, only at a /24 level)
      networks hosting Tor hidden services.  There is much detail to
      explain here, but in short, many privacy networks, VPN operators
      and "how to" pages generally instruct users to use Google or
      OpenDNS, as a type of informal 'Chaum-mixnet'---essentially, a
      large 'haystack' proxy, where the attributable origins of
      queries can be hidden among a much larger pool of other user
      traffic.
  
      While not a perfect mitigation of "DNS leaks" that challenge
      privacy networks, the "just use Google/OpenDNS" practice remains
      very common, particularly among commodity and low-end VPN
      providers (but also among implementations such as ttdns, tails,
      etc.).  A web search for the IPs for the public recursives and
      the term 'proxy' or such, will literally turn up hundreds of
      sites, howtos, and tools used by multitudes.  The average use
      case of such tools is not always evident, but the
      torrent-related ECS zones saw considerable quantities of udp/53
      traffic (with ECS payloads) from users who otherwise proxies
      their TCP traffic.

      The original advice to "just use Goolge or OpenDNS" was
      presumably sound, or at least a passable version of a mixnet,
      for such privacy networks.  However, the recursives identified
      as "DNS Chaum mixnets" by these proxy services are now ECS
      implementers, and therefore permit fine-grained tracking of
      queries.  I believe this would surprise most Tor and VPN users,
      since the ability to attribute traffic becomes easy, and the
      impact of DNS leak goes from "potentially harmful" to
      "attributable".  This is very true in situations where the
      origin network has a low query volume, the subject zone has a
      low TTL, and the privacy tool treats TCP and UDP paths
      separately.  It seems with only rare exception, the implementers
      of these privacy tools have historically recommended recursives
      that are now ECS implementer.

      The current draft contemplates some loss of user privacy, and I
      thank the authors for giving this space for consideration.  But
      the analysis now seems limited, in light of this exercise, and
      excludes the scenarios I tested (low-end VPN privacy leaks via
      ECS, revelation of Tor hidden services, enriched collection of
      user network data in non-UDP proxy privacy tools).

      The current draft makes the observation (quite reasonably IMHO),
      that the /24 network information is hardly a significant loss
      for a user about to make a TCP connection (and thereby revealing
      a /32) to a service.  I.e., an operator will see user host data
      in the httpd logs, so revealing the stub's /24 via DNS is hardly
      a significant cost, and it permits judicious improvements in
      services for the user and subsequent queries handled in cache.
      All this seems logical, and originally I found this very
      persuasive.

      But the draft does not contemplate DNS resolutions in support of
      privacy-sensitive applications, such as (what I call) the
      "low-end" VPN services (namely those that don't proxy both TCP
      and UDP traffic, and therefore have a half-decades' worth of
      users still relying on current ECS implementers to continue to
      act as Chaum mixnets for DNS.)

      I suggest the draft should address such privacy sensitive
      scenarios though I'm at a loss to know how a user might signal
      to a recursive that it need recursion for privacy-sensitive
      applications.  I also don't think such signaling would be
      wise---it merely illuminates such queries for any opportunistic
      measurement.  Perhaps at the least, the draft might suggest that
      local operators, tool makers, and privacy-based software systems
      consider this issue.  In some cases, such tools leak private
      user data; in other cases, the udp traffic is also proxied,
      resulting in the revelation of the proxy nodes' network
      information.

      I fully expect that such proxy users don't expect "speedy"
      mirror selection, or other benefits offered by the draft.  Such
      users have opted already for privacy over convenience.  I do not
      know how the current draft can preserve that bargain, or even
      communicate that preference.  This seems troubling, now that
      recursives which formerly operated as mix nets are now offering
      the user /24 data, in exchange for no benefit (due to the
      proxied TCP flow).

      This dilemma (not merely speculated, but actually happening to
      such tool users), and my inability to find a creative solution,
      are ultimately why I've embraced Stephane Bortzmeyer's
      suggestion that the protocol be made opt-in rather than opt-out.

      This might not be black and white.  Perhaps this means that some
      curated user device platforms (e.g., Android) opt-in to a new
      ECS-enabled service, or something.  While the draft can avoid
      such details, I urge that it either find the creative solution
      that eludes me (how to signal privacy preference, for existing
      users expecting a mixnet?), or that it counsel careful study by
      recursive adopters.  I suggest: Do not surprise the people who
      have, for 5+ years, assumed (wisely or otherwise) that the
      recursive is a mixnet.  It might not have been, but it clearly
      is not, if it speaks the protocol.

   -- There is no protocol-level indication to a stub user which
      recursives are ECS enabled.  I believe one has to repeat my
      steps, and read blogs to find that Google and OpenDNS have
      adopted this protocol.  Perhaps other recursives are ECS enabled
      as well.

      But without fail, everyone I've shown ECS has been
      surprised---some even urgently ending meetings to check their
      infrastructure for 'data leaks' (their words, not mine).  This
      has acutely impressed those DNS users who try to identify
      abusive domains, and find it useful to resolve domains through a
      large service like Google or OpenDNS (again, using them as an
      informal Chaum-mixnet for recursion), simply because malicious
      authorities often attempt to identify such researchers and
      corrupt or ban their recursive traffic.

      I suggest that the draft seek to minimize this surprise, through
      some sort of discovery.  (How can users meaningfully opt-out, if
      they cannot easily test for ECS-enabled recursion.)  I suggest
      that recursives speaking ECS exhibit this behavior to the stubs.
      Others have suggested such a record:

        _edns-client-subnet.${HOST}.in-addr.arpa IN TXT "v=ecs1 optin"

      which could be DNSSEC signed as well.  As a non-repentive abuser
      of TXT records, I'm usually cautious of serious applications
      using TXT policy encodings.  But others I've spoken to have
      given this aspect more serious thought.  Perhaps they'll suggest
      something detailed enough to both convince and assist the
      authors.

      In short: if opt-out is to become more meaningful, users need
      paths beyond web logs to discover ECS behavior.

   -- If opt-out is the majority view of either this group or those
      implementing ECS, then I suggest that opt-out tools be made
      widely available.  If I'm correct, there's currently only a
      development branch of unbound that supports a zero-scoped
      forward from the stub.  Suggesting that users can 'opt-out',
      when there are few tools, seems prematurely hopeful.
      (Informally, we call this the "go pound sand" clause of the
      proposal, since users must potentially write their own stub
      handler, or switch production resolution to development branches
      of code.  I've never found a user educated about ECS to be
      satisified with this suggestion of the draft.)

      I should note that opt-out is in fact honored by all ECS-enabled
      recursives I can find, and I can find no violations of requested
      stub-to-recursive scope restrictions.

      At a minimum, I suggest we learn how users opt-out, and whether
      the opt-out process needs refinement in this draft.  (I.e., is
      this merely an engineering/tools exercise, or could the IETF
      draft help uphold user privacy through more direct means in this
      draft?)  I simply do not know the answer here, beyond the
      (unanimous) request from users I've chatted with to somehow
      opt-out, while still retaining the other benefits of the global
      recursives.  Please note that in some cases, the stub's path to
      an ECS-enabled recursive is part of a firmware image (e.g., most
      of the wifit hotspot devices), which even the hobbyist users
      find difficult to amend or filter for opt-out.

   -- The ECS draft might be amended to exclude certain query types.
      As another experiment, I obtained a reverse delegation for a
      netblock, and had the authority ECS whitelisted.  I then could
      observe reverse scanning by hosts---clearly a needless
      solicitation of user network data, for an answer that will never
      be tempered by localized mirror selection.

      I hope others will agree, there is no use for these ECS
      augmented PTR answers beyond logging on the remote host
      side---there's no TCP session to be balanced, no CDN to
      consider, no mirror to select.  There's no point in ECS in PTR?,
      that I can see.  The same may apply to MX and many other record
      types I've not deeply considered.  Informally, they provide no
      'CDN benefit' in exchange for the 'cost' of user privacy, or
      they portend only queue-based TCP slows (for which mirror
      selection and localization is less urgent), or the rdata
      definition includes 'weights' or distance metrics (e.g., MX),
      making ECS redundant.

      I suggest the draft limit the use of ECS to those query types
      likely to benefit from global balacing, where possible.  Absent
      an exhuastive listing of types, the draft might discourage the
      protocol use (i.e., eitherq enabled by authorities or honored by
      recursives) where the answer cannot reasonably benefit from
      localized rdata.

On a final note, I'd like to thank the authors of the draft for their
patient and thoughtful consideration.  In the course of this inquiry,
I've come to understand the operational benefits they seek to provide
users, and how it will make the Internet a better experience.  My
research focus is on networks and operators that seek to do literally
the opposite.  I hope that the caution I've suggested above does not
in anyway diminish anyone's estimation of the proponent's efforts.

I apologize in advance for all the errors in this post.  Time is
short, and I believe I needed to say something on this topic.  We have
prepared a detailed study of this problem, describing the above tests
and experiments.  I can put others touch with the student author, if
they need more details.  The paper is under consideration in academic
contexts, which requires anonymous submission.  (And ironically, many
of the DNS authorities for these privacy conferences collect user ECS
data, evidently without beneficial purpose.)

-- 
David Dagon
[email-masked]
D970 6D9E E500 E877 B1E3  D3F8 5937 48DC 0FDC E717

---

From: Wilmer van der Gaast <[email-masked]>
Date: Tue, 29 Sep 2015 14:18:44 +0100

> there are more than you'd likely imagine, too).
Correct, that's in pretty old versions of the draft so it was likely
me or one of the other authors at the time.

Background to that: The transitivity part of this option has always
been a sensitive topic, and IMHO it received more attention than it
deserved, adding lots of unneeded complexity. The only transitivity I
really found useful is anonymisation, which is just a (0|::)/0, not
hard to deal with.

I think the main motivation to support it was multi-tier DNS setups,
but the multi-tierness of such setups should be an invisible
implementation detail so should people want to make their internal
setup that complicated, that's up to them. But I could easily be wrong
here. Over time I've seen other possibly useful use cases for
transitivity, but I'm still not sure whether they're worth the
additional compexity.

Anyway, motivation for returning REFUSED was, we deemed this more
appropriate than silently discarding the user's edns-client-subnet
option and replacing it for example with an ECS option containing the
address they were querying from: An attempt at suppressing ECS
silently getting ignored. That seemed worse. I do welcome better
alternatives. IMHO transitivity was enough of a corner case that
behaviour on rejecting it was not a terribly interesting detail.

All in all, I'm very glad to see this draft hit WGLC.

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

---

From: Dave Lawrence <[email-masked]>
Date: Tue, 29 Sep 2015 16:26:38 -0400

David Dagon writes:
> I have some concerns, which I describe below. [...]

David,

Thank you very much for your thoughtful comments.  Broadly speaking, I
very much agree with the bulk of them.  Yet my current reaction is not
to make any more alterations to the existing document.  It describes
the deployed protocol as-is, and your comments are appropriate for
consideration for the revised protocol, where I can assure you they
will definitely be integrated.

Is there something specific about documenting (yet not endorsing) the
in-use protocol that you think is important to get into the document
before publication?

---

From: dagon <[email-masked]>
Date: Wed, 30 Sep 2015 11:48:47 -0400

> in-use protocol that you think is important to get into the document

I'm preparing more notes, but wanted to offer more observation:

1)  Testing Sundown?

      -- Many authorities still answer edns-client-subnet iteration, using
	 the draft/testing option code (0x50FA, instead of the assigned
	 0x0008).

      -- Some return some appropriate rfc 1035 RCODE error for 0x50FA
	 encoded queries.

      -- Some answer 0x50FA-typed queries with 0x0008 answers.  (This was
	 a surprise).

    I wonder if the document you're working on would need to comment
    on this practice.  Some response patterns seem logical (e.g.,
    RCODE=1 Format Error under 1035 s4.1.1), in response to 0x50FA
    option coded queries.  Some are merely helpful (e.g., still
    answering test option coded queries, even after there's an IANA
    assigned field).

    Other behaviors seem helpful for very early testing, but are
    perhaps not a useful status quo and might be discouraged, e.g.,
    returning 0x0008 in response to queries with option 0x50FA, since
    this raises anti-poisoning questions at the recursive.  (Is query
    tuple matching at the recursive to additionally include the option
    code?  If not, that doubles the probability of success for
    attack.)

    Perhaps if there are authority implementors on list, they can
    clarify the thinking here?  (I'd be particularly interested in
    those zones who formerly answered 0x50FA, and now issue FormError
    or similar responses.  That change denotes some re-evaluation, or
    maybe a new tool.)

    I'll have some stats on this shortly, if there's interest.

2)  Probe Delay for Authority Behavior?

    I either don't understand or am not convinced by the draft's
    discussion of a possible probe delay for testing ECS behavior in
    authorities.  Here's my current thinking: A naive in-line
    implementation of probes would of course incur delay when
    iterating to an authority for which a recursive has no cache
    evidence of ECS.  But surely all recursive implementations have
    done other out-of-query-band testing of authorities for ECS
    behavior, at least from what I can determine from my logs.
    (Indeed, some are still manual.)

    Section 12.1 does note the need for periodic probing.  I'm not
    clear why section 12.2 notes a "possible query loss/delay" for
    such probes.  I speculate: in the worst case, wouldn't a busy
    recursive just provide a stock zone answer, without subnet
    localization?  I speculate that, in the worst case, the first
    query for a novel zone results in this non-localized answer
    (sorry; no ECS for novel NS/novel zones; just plain vanilla 1034),
    but after the recursive validates ECS awareness (either
    out-of-band, or through manual whitelisting), subsequent queries
    become subnet aware.  

    Worst case, if the whitelisting and/or periodic probing
    contemplated by S.12.2 were a linear scale of the TTL for the NS
    record (or the default for the zone), then even naive, in-line
    querying for ECS would be able to limit "loss/delay" to
    once-per-TTL expiration.  And again, the recursive could avoid
    this, by simply not returning an ECS-endowed message, falling back
    to stock 1034 instead of failure.

    So I'm afraid I do not understand "loss/delay" discussion in the
    document.  Granted, it's probably there to motivate the need for
    whitelisting.  But I focus on this, because I'd like to understand
    (and hopefully avoid) any language that diminishes the operational
    value or potential for adding probe records such as this to any
    ECS-aware zone:

    This is operationally not done, AFAIK.  But if it were (and also
    only honored in response to 0x0008 typed queries from the
    recursive), or in some similar form, it would become evident to
    the stubs---the first evidence they'd have a both recursive and
    authority treatment of ECS.  If there are more complexities in NS
    ECS status maintenance, I'd like to better understand them.  There
    are only two implementors of the protocol, AFAIK, so perhaps
    someone can help?

I'm still digesting the rest of the document, and running tests.  It's
well written, and helpfully annotated.  I'm just a bit slow in this
process.

I will endeavor in the time that remains for this IETF review to
identify more comments about the draft, which documents current
practices.

My general sense, summarized in my earlier post, is that this protocol
is a significant change due to the re-injection of user metadata,
has/will cause user surprise (I use that word descritively, based on
experience), affected proxies/vpns and hidden services, and could be
better detailed in some parts (e.g., no encoding for PTR?, MX?,
discussing FORMERR behavior for 0x50FA type queries, etc.).  

But I'm also aware that global recursive operators can point to a
competitive need for mirror localization.  In short, "interesting
times".

---

From: 神明達哉 <[email-masked]>
Date: Wed, 30 Sep 2015 11:48:08 -0700

On Wed, Sep 16, 2015 at 9:05 AM, Suzanne Woolf <[email-masked]> wrote:

> This begins the working group last call for
> draft-ietf-dnsop-edns-client-subnet, "Client Subnet in DNS Queries.” The
> document has gotten significant feedback and the editors have worked hard to
> document current use of the client-subnet EDNS option.
>
> We’re seeking consensus to advance it to the IESG with an intended status of
> Informational. If you support it, please say so. If you don’t, please say
> why.

I'm not necessarily opposed to advancing it, but I have one high level
question.  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.  Also, if the
intent is the latter, I wonder we might rather avoid using RFC2119
keywords (but that's not a strong opinion).

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

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

- Section 6

   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.

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

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

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

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

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

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

- Section 15: s/Internet Software Consortium/Infoblox/ (please keep my
  current employer happier:-)

   ... Tatuya Jinmei from Internet Software Consortium;

--
JINMEI, Tatuya

---

From: dagon <[email-masked]>
Date: Wed, 30 Sep 2015 15:50:49 -0400

> well written, and helpfully annotated.  I'm just a bit slow in this

"As long as I have you on the phone..."

I have one more comment:

3) Towards ECS Blacklisting

  I write in praise of Section 12.1, when it notes that ECS probes
  should never be sent to a TLD, an effective TLD (ugh, that term), or
  a root.

  Brief testing has not revealed any TLD or gTLD NS that exhibits
  edns-client-subnet behavior.  (The lab has placed bets about whether
  the nTLD NS will hold any surprises, but testing is not complete,
  and is ongoing.)

  If you're looking for particulars, the draft might also note that
  query minimization would address this issue entirely.  Stub ECS
  information is a fragment of query data similar to a child label
  that requires truncation when chasing delegation.

  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.

  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.

Best,

---

From: "Joe Abley" <[email-masked]>
Date: Wed, 30 Sep 2015 16:32:07 -0400

On 30 Sep 2015, at 14:48, 神明達哉 wrote:

> specification,

I know of at least one significant implementation based on the current 
specification that is proceeding right now. So that's a vague, 
unsubstantiated data point for you :-)

There is significant customer demand in the enterprise DNS market for 
features that require edns-client-subnet, and a significant resolver 
population that supports it today. I think it's unreasonable to expect 
either that commercial operators will be willing to publish their 
internal product plans to dnsop or that silence from that community 
implies that no work is being done.

Hence, I don't think there's any meaningful such clarification that 
could be included in the draft (although I understand why you suggested 
it).

Joe

---

From: 神明達哉 <[email-masked]>
Date: Wed, 30 Sep 2015 14:14:24 -0700

At Wed, 30 Sep 2015 16:32:07 -0400,

> implies that no work is being done.

Perhaps I was not clear enough about my intent, since this point is
irrelevant to it; it's totally up to the developer/operator whether to
implement/deploy a specification even if it's explicitly discouraged.
That's their business and that's fine for me.  I didn't try to know
such attempts by my question above.

My point is:
- If, while knowing developers/operators do whatever they want anyway,
  we basically intend this document to just describe the current
  practice than a specification for newer implementation, IMO we
  should more explicitly state so and even discourage the attempt of
  implementing it for now.  Especially as we expect a revised document
  will be written (soon?), and because the current document simply
  diimsses some known issues with the excuse of "this is just
  describing what's currently implemented".  Again, some may still
  ignore the warning and go for it anyway, but, IMO, it's more
  responsible for us to at least explicitly discourage it to avoid
  having more incomplete/immature/less interoperable implementations.
- On the other hand, we actually expect more implementations will come
  based on this publication, at least some of the glitches should be
  fixed before the official publication.  The (mis)use of REFUSED
  RCODE would be one such point.  Some privacy related considerations
  might be another.  Behavior with less/more specific prefixes might
  be yet another.  Some of these issues might still be considered "out
  of scope for now", but in its current state I think this document
  dismisses those too casually.

--
JINMEI, Tatuya