DNS Name Server Identifier (NSID) Option
draft-ietf-dnsext-nsid-02

[Ballot comment]
Section 3.1 describes eight alternatives for the payload of the nsid option.  Immediately below,
the text provides advantages and disadavantages for six of the eight options.  No advantages or
diadvantages are given for the remaining options (a digitally signed blob or an encrypted blob).
I would like to see brief descriptions of the utility of these mechanisms, particularly with respect
to the content of the associated plaintext.

[Ballot discuss]
Section 3.1 describes eight alternatives for the payload of the nsid option.  Immediately below,
the text provides advantages and disadavantages for six of the eight options.  No advantages or
diadvantages are given for the remaining options (a digitally signed blob or an encrypted blob).
I would like to see brief descriptions of the utility of these mechanisms, particularly with respect
to the content of the associated plaintext.

In addition, Blake Ramsdell identified the following issue in his secdir review:

  Because the structure of the NSID responses is left up in the air, I'm
  concerned about whether or not this would give an opponent a new ability
  to identify the type of DNS software generating the response. That is,
  if there is structure to the NSID response data that is unique to a
  particular DNS implementation, is this a problem?

Whil the impact of suchh attacks is probably limited, I believe this warrants a brief mention
in the  security considerations. (While I haven't given it much thought, this might be mitigated
by using an encrypted blob...)

[Ballot comment]
Section 3.4., paragraph 3:
>    By definition, a resolver that requests NSID responses also supports
>    EDNS, so a resolver that requests NSID responses can also use the
>    "sender's UDP payload size" field of the OPT pseudo-RR to signal a
>    receive buffer size large enough to make truncation unlikely.

  Even thought this may make truncation unlikely, long NSIDs may still
  increase the likelihood of fragmentation, with the corresponding
  decrease of reliability. May want to add a sentence on that here.

[Ballot discuss]
Section 3.1 describes eight alternatives for the payload of the nsid option.  Immediately below,
the text provides advantages and disadavantages for six of the eight options.  No advantages or
diadvantages are given for the remaining options (a digitally signed blob or an encrypted blob).  I
would like to see brief descriptions of the utility of these mechanisms, particularly with respect
to the content of the associated palintext.

The NSID in this document is defined as an opaque identifier. There has been quite a bit of discussion around what this actually means. In particular, (1) does the identifier have a format which can be parsed by another entity, and (2) is the identifier guaranteed to be unique. For the first question, while a number of examples are given in the document that describe a possible format, none of this is nailed down in stone by design. The key bit of understanding that in my mind makes this permissible at all is that the one who is required to be able to read and use the ID information is the same entity that constructed it (for example, for troubleshooting purposes). As for uniqueness, this is a touchy subject with a lot of differing opinions. One side believes that, particularly for things like anycast, that the values MUST be unique from all servers. The other side professes that this is an unecessary burden, and that it could reveal internal details of server placement that are nobody's business. Bottom line is that, after heated discussion and revisitation of these points multiple times, the WG Chairs made a rough consensus call in favor of what is in this document.

This document has been sitting around for a while. Most of the delay was due to my decision to wait for draft-ietf-dnsop-serverid to advance before bringing this document to the IESG. The dnsop document contains requirements for draft-ietf-dnsext-nsid.

Timeline of events WRT potential appeal from Dean Anderson


Mark,

Here is _my_ view of the timeline. I think it provides a reasonably
complete picture of the events. Not all messages of all participants
in the thread are quoted though.

I hope this is helpful.


I paraphrase the issue at hand as:

Dean Anderson has an issue with the fact that the NSID draft allows
for mechanisms to construct the NSID in such a way that only operators
can identify from which instance in an anycast cloud an answer
came. Mr Anderson would like to see that everybody on the internet
could use the NSID to uniquely identify the instance. This is, IMHO, a
technically valid issue.


- The issue at hand was first brought up by Peter Koch during the
  Paris meeting and subsequently in a message to namedroppers:

  http://www.ops.ietf.org/lists/namedroppers/namedroppers.2005/msg01347.html

  "
  The draft lists and discusses a variety of ways to fill NSID, all of
  which suggest a static mapping of server instance to NSID value. As I
  mentioned in Paris, I'd like to have the option of changing that value
  per query (keeping track internally). This is one way to avoid discovering
  the number of anycast nodes behind a load balancer and there might be
  other reasons. The person debugging then can't even tell whether
  subsequent responses originate from the same server, but it could hand over
  the info received to the server admin for further inspection.
  "

  When brought up it was not discussed further and the issue was
  closed and forgotten.

- WG last call d.d. 5-Oct-2005 terminated 22-Oct-2005
  http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg01318.html

  There was discussion but not on this particular issue.

- Document moved up to AD 18 April 2006

  proto statement at:
  http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00059.html

- The AD came back with specific questions that were put to the
  mailinglist by the chair om 23 May 2006.

  http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00684.html

  During the discussion of the changes proposed in that message Dean
  Anderson requested a specific text change see his message on
  http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00711.html

- The Chair posted a message, to conclude the thread started on May
  23, on 13 june 2006
  (http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00735.html)

  In that message the chair concluded:

  "As for the discussion of the first issue. The group consents with
  the general idea that the NSID option remains "unique" but also
  asked for a definition of unique. I think Dean Anderson's proposed
  text is catching the spirit of the discussion. And if there are is
  no push- back before the end of the week I would like to ask the
  editors to update 3.1 with the following."


- On the same day (June 13, 2006) Koch replied and strongly disagreed
  with the proposed change.
  http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00737.html


- Chair followed up the day after (June 14,2006) and acknowledged that
  this was indeed an old and allready closed issue. Chair also
  acknowledged a way forward and proposed a way forward. Working from
  the premissis that "one person should not be able to overhaul a
  pre-last call issue" a text was proposed for which consensus was asked.


  The call for consensus was worded in a confusing way with to many
  negations in one sentence.
  http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00738.html


- The discussion continued and the chair concluded that there was consensus
  to include the proposed text on June 19.
  http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00784.html


  I have seen the discussion develop over the last couple of days and
  I think it has converged to a point where arguments are being
  reiterated. I have not seen a clear consensus building for '_not_
  removing "as long as the content ... over a series of
  queries"'. Hence I would like to request the editors to include the
  above version of 3.1 in the draft (modulo the possible "Strunk and
  White" and "Merriam-Webster" kind of corrections that are needed to
  turn the text into plain english).



- The editors posted a new version of the document (version -02)
  and IESG last call was initiated.
  http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00921.html

- on the 26th of June, Anderson noted that the document had not changed
  according to his expectations.

  http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00822.html


- The chair realized that his June 14 call might have been the cause
  of confusion. And posted a message to the list explaining that he
  understood the confusion (and apologized) but that his thought was
  that there was no mistake in determination of rough consensus.

  http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00830.html


- Anderson challenges the consensus call by listing a number of folk
  that are for and against spoofing on 27 June 2006.

  http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00840.html

  Some of the people listed by Anderson reply to his message,
  disagreeing with his characterization.


- Anderson request a post WGLC for specific text to include is requirement
  on June 28.

  http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00861.html
  The chair denies this the day after on the grounds that the work is out
  of the group ant in the hands of the IESG.
  http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00868.html


  The AD suggests Andersons' comments can be addressed as IETF LC comments.
  http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00872.html

- Anderson replies specifically to the WGLC detailing his objections on July 7.
  http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00921.html

  This causes some WG members to reply and state that they do not
  support Anderson's view or that they feel mispresented.

  When the discussion seems to derail the chair sends in a short
  message closing the thread while specifically asking for folk that
  think that consensus was called in the wrong way to speak up.

  Chair acknowledges that Anderson is of the opinion that the
  consensus is called the wrong way.
  http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00941.html

  "We are now at a point that the discussion is drifting from the
  original topic.

  The NSID document is out of the working group and I have not seen
  support for the view that I called rough consensus the wrong
  way. If you happen to support that view please speak up and
  motivate it, Dean has already done so.

  If and/or when we have push-back from the IESG this WG is done and
  I close this thread."


  That message closed the thread and nobody responded.





--Olaf


PS: If you think that openness is served:
Feel free to forward this message to public lists,  to individuals,
or to cut and paste it in the tracker.




-----------------------------------------------------------
Olaf M. Kolkman
NLnet Labs
http://www.nlnetlabs.nl/

IANA problem description from document author

-------- Original Message --------
Subject: Re: [IANA #9954] RE: Last Call: 'DNS Name Server Identifier Option (NSID)' to Proposed Standard (draft-ietf-dnsext-nsid)
Date: Mon, 07 Aug 2006 16:41:24 -0400
From: Rob Austein
To: iana-drafts@icann.org
CC: dnsext-chairs@tools.ietf.org, iesg@iesg.org
References:  


At Mon, 07 Aug 2006 12:21:24 -0700, ICANN RT wrote:
>
> The IANA has reviewed the following Internet-Draft which is in Last
> Call: draft-ietf-dnsext-nsid-02.txt, and has the following
> comments/questions with regards to the publication of this document:
>
> IANA understands that, upon approval of this document, a single value will be
> added to the RR and QTYPE registry located at:
>
> http://www.iana.org/assignments/dns-parameters
>
> That value will be:
>
> TYPE Value and Meaning
> ---- ------------------------------------
> NSID TBD Name Server Identifier
>
> IANA understand that this is the only IANA action required upon approval of the
> document.

Sorry, wrong.

The document allocates one "EDNS Option Code.  This is a separate
space from the RR/QTYPE code space.  See RFC 2671, sections 4.4 and 7.

draft-ietf-dnsext-nsid-02.txt is asking you to allocate an "EDNS
Option Code" from one of the several regisistries described in RFC
2671 section 7 (specifically, the "EDNS Option Code" registry).

I don't know whether IANA ever created any of the registries described
in RFC 2671.

IANA Last Call Comment:

IANA understands that, upon approval of this document, a single value will be
added to the RR and QTYPE registry located at:

http://www.iana.org/assignments/dns-parameters

That value will be:

TYPE Value and Meaning
---- ------------------------------------
NSID TBD Name Server Identifier

IANA understand that this is the only IANA action required upon approval of the
document.

PROTO

http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00059.html

Questions:

1) Have the chairs personally reviewed this version of the ID and do
    they believe this ID is sufficiently baked to forward to the IESG
    for publication?

  Yes.

2) Has the document had adequate review from both key WG members and
    key non-WG members? Do you have any concerns about the depth or
    breadth of the reviews that have been performed?

  Yes, at least 5 people in the working group state they have
  reviewed this work thoroughly. We have no concern about the depth
  of review.


3) Do you have concerns that the document needs more review from a
    particular (broader) perspective (e.g., security, operational
    complexity, someone familiar with AAA, etc.)?

  No. This is a relatively trivial protocol extension.


4) Do you have any specific concerns/issues with this document that
    you believe the ADs and/or IESG should be aware of? For example,
    perhaps you are uncomfortable with certain parts of the document,
    or whether there really is a need for it, etc., but at the same
    time these issues have been discussed in the WG and the WG has
    indicated it wishes to advance the document anyway.


  The document specifically addresses server to client
  identification. Client to server identification is out of scope. If
  such is ever needed the WG will write new specification.


5) How solid is the WG consensus behind this document?  Does it
    represent the strong concurrence of a few individuals, with others
    being silent, or does the WG as a whole understand and agree with
    it?

  Solid. Note that the need for this technique came from the DNS
  operations community. Also see draft-ietf-dnsop-serverid (The nsid
  document does not contain references to dnsop-serverid as it stands
  on itself).


6) Has anyone threatened an appeal or otherwise indicated extreme
    discontent?  If so, please summarize what are they upset about.

  No.

7) Have the chairs verified that the document adheres to _all_ of the
    ID nits?  (see http://www.ietf.org/ID-nits.html).

  Yes

8) For Standards Track and BCP documents, the IESG approval
    announcement includes a writeup section with the following
    sections.

  In order to be able to identify certain nameservers in a DNS
  anycast cloud clients querying nameservers in that cloud can add an
  EDNS OPT pseudo RR that signals the answering nameservers to
  include identifying information in an OPT RR that is attached to
  the answer.

  This technique improves the existing ad-hoc methods to identify
  nameservers.

  Working group consensus is solid. During the working group
  discussions the question came up to also allow for client to server
  identification. This was argued to be out of scope since.

  This feature will be implemented in at least two independent
  open-source products used on anycasted root-servers. And will be
  available in at least one resolver implementation and become
  available in two libraries.

-----------------------------------------------------------