Subject: Last Call: 'DNS Name Server Identifier Option (NSID)' to Proposed Standard (draft-ietf-dnsext-nsid) (fwd)

From: Dean Anderson <[email-masked]>
Date: Fri, 7 Jul 2006 18:32:08 -0400 (EDT)

IESG and DNSEXT WG:  Summary Last Call Comment requested by Mark
Townsley.

I object strongly to the draft as it is currently worded. Several
versions of part of section 3.1 were discussed at the last minute, and
these discussions resulted in a new draft version that was immediately
submitted to the IESG Last Call without further WG review.  Due to
confusion over which version the wording, a different text was put in
the final document from that which many people supported or accepted. WG
Chair Olaf Kolkman has acknowledged confusing references and
acknowledged some responsibility for the confusion.  
http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00830.html
[It is not asserted that Mr.  Kolkman did anything nefariously wrong,
but the WG was confused and a mistake was made.]

These are the changes that need to be made:

In the first paragraph of Section 3.1, use this wording:

 3.1.  The NSID Payload

     The syntax and semantics of the content of the NSID option is
     deliberately left outside the scope of this specification. It is
     the prerogative of the server administrator to choose the NSID
     content as long as the content is unique to each anycast instance
     so that a remote user is able to match the NSID to the server 
     instance over a series of queries. The NSID can be opaque and
     encoded such that it can be decoded by the server adminstrator to
     provide more information. This section describe some of the kinds
     of data that server administrators might choose to provide as the
     content of the NSID option, and explains the reasoning behind
     choosing a simple opaque byte string.

Delete this text from Section 3.1:

   o  It could be some sort of dynamicly generated identifier so that
      only the name server operator could tell whether or not any two
      queries had been answered by the same server.

I think that presently 7 of 10 in the DNSEXT WG who previously commented
on the spoofing issue now either support or at least accept the proposed
wording change:

  Matt Larson can accept either version, but seems to prefer slightly my
version. Quoting Koch's text, he says he can accept it, but prefers the
original text (which I think means my text).

  Alex Bligh does not think there should be a prohibition on opaque NSID
(i.e. in am in favour of removing the prohibition), but does not think
the ability to use them needs to be expressly authorised in the standard
(does not objecting to it doing so per se, I just think its otiose and
understands the argument that we shouldn't be seen to encourage it).
[the new proposed change does not prohibit opaque NSID, but requires
that it be unique per anycast instance. -Dean]

  William Leibzon is also not convinced by the DOS argument, and asks
for the DOS attack to be better explained and added to the Security
Considerations section.

  John Dickinson seems to agree with Peter Koch, but notes that spoofing
is a policy decision that has nothing to do with the protocol. It seems
he could be happy without it in the standard.

  And it was my impression that Olaf Kolkman agreed spoofing should not
be in the standard, though perhaps his mind was changed...

  Andrew Sullivan is not for spoofing.  "To be clear, I am not "for
spoofing".  I think I've said enough on the topic, however, so I won't
re-hash my arguments here."

  And of course, I (Dean Anderson) strongly object to the spoofing text.

Strongly for spoofing:
  Peter Koch
  Ed Lewis
  [email-masked]

My objection with the document is that the the language in section 3.1
permits operators to obscure the existance an anycast instance while in
full compliance with the standard.  I think one should not be able to do
this. Being able to prevent identification of anycast instances subverts
the purpose of the draft.

The only reason put forward for this facility was a vague concern that
identifying the number of anycast instances could (vaguely somehow)
assist a DOS attack. This rationale was never explained, and there is no
evidence that this would happen. If it did happen, of course, NSID could
be turned off by server query authorization controls, just as AXFR,
recursion, etc are now controlled.  So the DOS attack concern seems to
be adequately addressed by conventional methods.

Plainly, those who want to do spoofing, and aren't compelled to comply
strictly with the standard, will do spoofing regardless of the standard.  
There are many examples of such spoofing: for example TCP signature
spoofing, etc. While one might anticipate this activity "in the wild",
there is no need to specify it in a standard.  As Alex Bligh noted, it
is otiose to do so.

The only reason I can see for this feature is to obstruct testing of DNS
Root Anycast; Testing which will further demonstrate the unsafe nature
of stateful anycast.  One might also foresee that (at least) RSOs might
be prohibited from operating Anycast, and that this spoofing facility
would make it difficult to catch non-compliance.  Furthermore, including
spoofing in the standard creates much more effort to require RSOs to not
use spoofing. [this fact by itself seems to militate that this is an
inappropriate effort by certain operators, who have already demonstrated
some extraordinary nefarious efforts on the subject of DNS anycast]

This spoofing ability is contrary to the requirements discussed by the
RSSAC and elsewhere regarding the need to identify anycast server
instances.  It does not belong in this document.  This ability to
obscure anycast is nefarious in light of the extraordinary efforts to
silence discussion of the scientific fraud and to subvert the process in
several instances, as described previously to the IESG.

Dean Anderson
Av8 Internet, Inc

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 7 Jul 2006 19:15:26 -0400

> on the spoofing issue now either support or at least accept the proposed

[ . . . ]

> re-hash my arguments here."

It appears to me that my statements are being (presumably
accidentally) misrepresented.

My position is that I am not "for spoofing".  That does not entail in
any way that I support the formulation Mr Anderson is arguing for. 
It seems to me to be a little emotionally charged to suggest that
those who are opposed to the importation of policy into a protocol
are "for spoofing".

Best regards,
A

-- 
----
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<[email-masked]>                              M2P 2A8
                                        +1 416 646 3304 x4110

---

From: Alex Bligh <[email-masked]>
Date: Sat, 08 Jul 2006 10:11:55 +0100

> that it be unique per anycast instance. -Dean]

While the above is true, I did also (I think) point out that despite the
fact that particular bit of draft-ietf-dnsext-nsid wasn't how I would have
phrased it myself, I was happy with the document going forward in the
current form, that being the nature of compromise, as all the document has
now in my view is "a few unnecessary words". I thought this was perhaps
evident from my original contribution, which was to say that we should NOT
prohibit opaque NSID (what Dean calls spoofing) though we need not
encourage it. In any case, I think the point is sufficiently minor that it
doesn't merit going back to the w/g, and for the record I think Olaf made
the right call.

Alex

---

From: <[email-masked]>
Date: Sat, 8 Jul 2006 11:48:02 +0100

>   [email-masked]

To be clear, I'm persuaded there are "legitimate", non-detrimental
uses for returning encrypted responses containing values that don't
persist between responses.  The term "spoofing" probably inaccurately
characterises these uses.

I'm very reluctantly responding to your most recent message, but I fear
that if I (and others) remain silent, that some observers with incomplete
information may interpret this as acquiescence, or -- worse -- agreement,
to your charactarisations.

Geoff

---

From: Dean Anderson <[email-masked]>
Date: Sat, 8 Jul 2006 17:46:53 -0400 (EDT)

I am not against opaque NSID's: As long as the NSID is unique to the
anycast instance. However, lets be clear on what spoofing means:  To
make the NSID different between successive query responses from the same
instance is to spoof the number of instances. Indeed, the reason given
for this behavior is to hide and obscure the number anycast instances to
prevent DOS attackers from knowing how many there are. [though why
having this knowledge would benefit the attacker was never made clear,
nor was it made clear how denying this knowledge from the attacker would
benefit the operator--but this was the reason given for hiding]. This is
fairly and accurately described as "spoofing".

Lets get our terms clear: "Opaque NSID" is ___NOT___ what "Dean calls
spoofing".  Lets start by getting that characterization right.  Lets be
very clear on that: "Opaque NSID"  and "Spoofed NSIDs" are different,
and have different text examples.  "Opaque NSID"s are still unique to
the anycast instance. "Opaque NSID"s still remain the same across
queries to the same anycast instance.  By contrast, "Spoofed NSID"s are
not unique to the anycast instance.  "Spoofed NSID"s change across
subsequent queries to the same anycast instance, and fail to publicly
identify the anycast instance(s) that handled a group of queries.

"NSID Spoofing" is something lately added by persons associated with
root server operators, in the context of a scientific fraud concerning
the stability of stateful anycast, perpetrated by persons associated
with root server operators, particularly RIPE NCC and ISC.  The IESG is
currently investigating this fraud.  "NSID Spoofing" prevents outside
monitoring of root servers using anycast, and prevents outside analysis
of data regarding root server anycast.  "NSID Spoofing" provides no
other features which aren't already addressed by conventional access
controls.

[It seems ironic to me the my GF is currently grading a series of
placement essays for incoming MIT freshmen. One of the tasks given to
them is to write a "literature summary". They are given several papers
with very different views on a scientific subject, and they have to
write an essay summarizing what the papers say. The essay has to be
interesting, readable, and accurate--in other words, a good literature
summary essay. If they fail the several writing tasks given, they are
placed in additional humanities and writing courses--I don't know
exactly what happens but some sort of remediation is required. It seems
to me this skill of "literature summary" should be developed more
broadly. And indeed, there are other universities working with MIT to
implement the MIT program with their incoming freshmen.]

More inline.

		--Dean

> those who are opposed to the importation of policy into a protocol

"Emotionally charged"????  What does that mean?  I can see what is meant
by "opposing importation of policy into a protocol"--rather like Bligh's
view, but I can't see any emotional relationship between this view and
being "for spoofing".  How can that possibly be "emotionally charged"?  
Perhaps you are imputing emotion where none exists?  Or perhaps you are
emotionally concerned about your new co-worker (Joe Abley's) involvement
in the underlying scientific fraud of stateful anycast. I can see that.  
But I rather doubt there is any emotional relationship between these
issues. nor any relevance to my summarizing your position.

I originally summarized your position as supporting the spoofing text.  
That is, you supported the current text. You reacted to that summary by
indicating that wasn't your position.  So, I listed you in the other
category, and now you react against that, too.  It now seems you have a
view in a heretofore unknown third category: Those that don't support
spoofing, don't support the current text, and don't support my proposal
for removing that text.

In any case, what exactly are you for, or against? Please don't be
vague.  How is it that you are "against spoofing", but "for" the current
text, which includes spoofing? If you are "against spoofing" (you wrote
'I am not "for spoofing"'), then that seems to indicate that you agree
that the "spoofing" text should be removed from the draft, regardless of
my "formulation". It is hard to imagine how to formulate removal
differently, but I'm willing to listen to a different formulation for
removal, if you have one.

On Sat, 8 Jul 2006, Alex Bligh wrote:

> While the above is true, 

It should be true. You said it:
=======================================================
Date: Wed, 28 Jun 2006 09:34:23 +0100
From: Alex Bligh <[email-masked]>

[...]
What I said (well what I meant to say) is that I do not think there
should be a prohibition on opaque NSID (i.e. I am in favour of removing
the prohibition), but I do not think the ability to use them needs to
be expressly authorised in the standard (I'm not objecting to it
doing so per se, I just think its otiose and I understand the argument
that we shouldn't be seen to encourage it).

Alex
=======================================================

I just changed your text from first person to second person.

> I did also (I think) point out that despite the fact that particular
> bit of draft-ietf-dnsext-nsid wasn't how I would have phrased it
> myself, I was happy with the document going forward in the current
> form, that being the nature of compromise, as all the document has now
> in my view is "a few unnecessary words". I thought this was perhaps
> evident from my original contribution, which was to say that we should
> NOT prohibit opaque NSID (what Dean calls spoofing) though we need not
> encourage it. In any case, I think the point is sufficiently minor
> that it doesn't merit going back to the w/g, and for the record I
> think Olaf made the right call.

Repeat for clarity: "Opaque NSID" is ___NOT___ what "Dean calls
spoofing". Lets be clear on that: "Opaque NSID" and "Spoofed NSIDs" are
different, and have different text examples.  "Opaque NSID"s are still
unique to the anycast instance.  "Spoofed NSID"s are not unique to the
anycast instance.

> characterises these uses.

I did summarize that. Perhaps, though, you could elaborate on what those
"legitimate" uses might be.  We've still not heard of any truly
legitimate uses.

> to your charactarisations.

I accurately characterized your position as "for spoofing".  But do
agree absolutely, that if you do not agree with my characterization,
then you should speak up.

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 9 Jul 2006 15:06:24 -0400

Hi Dean,

I'm extremely leery of going down this conversational path, since I
think I have already explained my views adequately on the WG list. 
But since you ask for clarification, here it is.

> instance is to spoof the number of instances. Indeed, the reason given

From my point of view, that is the meaning of "spoofing" only in your
ideolect.  Everywhere I ever use the term "spoofing", I use it to
mean one thing pretending to be another, not one thing delivering
answers to identity questions which do not confirm the identity to
the asker.

> "Emotionally charged"????  What does that mean?  

It's a term that people who study arguments (which is what I did in a
previous life) use to describe the use of words that have negative
connotations, when a more neutral term is available.  You can read
more about this issue at <http://www.philosophypages.com/lg/e04.htm>.

For instance, in this case, the term "spoofing" suggests that the
practice is some sort of malicious activity.  In addition, the I-D as
currently written is simply silent about the nature of the name
server identifier.  You could describe it more neutrally, therefore,
as "strong opacity", as opposed to the "weak opacity" that you seem
to want.

> in the underlying scientific fraud of stateful anycast. I can see that.  

No, and I resent the _ad hominem_ attack.  Please don't do that.

> I originally summarized your position as supporting the spoofing text.  

No, you summarized my position as being "for spoofing".  I am not for
spoofing.  I'm not sure that anyone would be in favour of spoofing.

> spoofing, don't support the current text, and don't support my proposal

I do support the current text.  It seems to me to strike the right
balance of making possible a potentially desirable behaviour (where
clients can figure out what node has replied to them) while yet not
imposing policy decisions about how people run their servers.  I
might like it that people put a meaningful and consistent identifier
string in there, because it might make my life easier.  But protocol
documents are not in the business of dictating the policies of server
operators; so I am opposed to any addition to the document of
anything that waters down the statement, "Choosing the NSID content
is a prerogative of the server administrator."

(BTW, nit: I just noticed that "choosing" there is spelled "chosing"
in the document.)

> text, which includes spoofing?

My claim is that this document is not "for spoofing".  Neither am I. 
This document allows server operators to set policy.  I think that's
a good thing.  I am opposed to any changes to that.

I hope this clarifies things for you.  If not, I reluctantly conclude
that I am unable to make my position clear to you.  In either case, I
will not discuss this on list any more.

Best regards,
A

---

From: Dean Anderson <[email-masked]>
Date: Tue, 11 Jul 2006 02:49:10 -0400 (EDT)

> answers to identity questions which do not confirm the identity to

There is very little difference in "pretending to be another" if the
answer to the ___identity___question___ "does not confirm the identity."
This is a trivial distinction, at best. One that does not sustain your
argument, either.  I notice that both "not confirming", and "pretending
to be another"  also covers TCP signature spoofing: The TCP signature is
a question about the identity of the remote server. "TCP signature
spoofing"  also "does not confirm the identity". And "TCP signature
spoofing" also "pretends to be another".  In just exactly the same way,
in fact.

You are making a very strained effort at splitting hairs.

> practice is some sort of malicious activity.

Yes; In this case, that's right. But there is no exaggeration. I'm
reporting substantial facts on this particular subject, which includes
scientific fraud---many would consider that a 'malicious' activity.

[I think your selection of 'malice' is the wrong term. I think
"untoward"  would be better.  Neither spoofing, nor scientific fraud
imply malice--an intention to harm, but both terms do suggest some kind
of deceptive, inappropriate, unseemly activity.  For simplicity, I'll
stick with 'malicious' in place of untoward or unseemly in what
follows.]

> In addition, the I-D as currently written is simply silent about the
> nature of the name server identifier.  You could describe it more
> neutrally, therefore, as "strong opacity", as opposed to the "weak
> opacity" that you seem to want.

Yes, the ID is silent on the nature. But that does not mean that the
nature isn't 'malicious' (read unseemly). It is malicious--I'm reporting
that fact to you.  This feature serves no legitimate purpose, and in
fact furthers a previously known malicious activity--scientific fraud.  
There is no exaggeration in this term. The scientific fraud has been
reported to the IESG, the IESG has investigated this matter, and shortly
an appeal will be made to the IAB.  Other organizations will also be
involved.  A more neutral description would belie and hide the nature of
the activity already associated with the scientific fraud by Daniel
Karrenberg et al.

Neither "strong opacity" nor "weak opacity" have any relevant meaning,
since there is nothing "strong" nor "weak" about the differences between
"Spoofed NSID" or "Opaque NSID".  "strong"/"weak" is a rather artificial
non-descript choice of adjectives.

> No, and I resent the _ad hominem_ attack.  Please don't do that.

Ad hominem is a logical fallacy about irrelevant personal traits.  
_You_ attributed emotion (a personal trait) to my argument. If there was
an ad hominem, you made it.

But there is no fallacy in my response that you may have imputed emotion
where none exists. That is relevant to your assertion of emotion in my
argument. There is also no fallacy in an assertion that you (rather than
me) may be the one emotionally connected to your new coworker, who
stands to lose as a result of his involvement in the fraud I have
reported. This is relevant to why it is you who are emotionally
connected, rather than me.

I don't stand to lose anything whatsoever---I'm just reporting facts
which I'm confident will stand the test of time.  I've been vindicated
over time before on a few controversial subjects.  I've been though it
several times, and have no emotional involvement, any more than a
reporter for the NY Times has emotional involvement in the news.

> spoofing.  I'm not sure that anyone would be in favour of spoofing.

This splits hairs, exceedingly.

> I do support the current text.  

Then you plainly support spoofing, as most people define the term, and
as most people on the WG understand the term.  And plainly you are in
the same group as Peter Koch and the others who I grouped in the "for
spoofing" category.  So your original objection was trivial.  Rather
than trying disassociate your position from Koch and the others, you
were aiming for something else---a word-smithing???  Did you not realize
your objection would be read as disassociation?  You seem articulate
enough to avoid that.

> My claim is that this document is not "for spoofing".  Neither am I.

That is interesting claim, but just attempts to draw a distinction where
there is none, in an effort to try to remove a well-established unseemly
character from the text under discussion.  We used to describe this sort
of word-smithing effort as an "attempt to polish a t*rd".

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Tue, 11 Jul 2006 10:01:18 -0400

Kind Colleagues,

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.

thanks,

--Olaf

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