Subject: Re: nsid last call

From: Alex Bligh <[email-masked]>
Date: Thu, 15 Jun 2006 12:15:25 +0100

--On 14 June 2006 23:28 -0400 Dean Anderson <[email-masked]> wrote:

> I can't see any good reason for there to be a secret as to how many
> anycast instances there are, nor can I see any good reason that remote
> users shouldn't be able to match the NSID to the server instance over a
> series of queries.

I can see a reason. If you were trying to DDOS a set of anycast servers
you might well like to know how many you had disabled. You could look
at NSID for that.

If someone wanted to hide the number of anycast servers, they could
encrypt a server ID with a random number appended and use that as NSID.
That way only persons in possession of a key could tell two servers
apart.

I'm not sure I'd want to do it myself, but I see no reason why NSID
necessarily has to be the same between two packets. It simply means
the server will not necessarily appear as a single server.

Alex

--
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: Dean Anderson <[email-masked]>
Date: Fri, 16 Jun 2006 15:33:46 -0400 (EDT)

On Fri, 16 Jun 2006, Edward Lewis wrote:

> At 19:05 -0400 6/15/06, Dean Anderson wrote:
> 
> >many.  But different NSIDs show that Anycast is in use.
> 
> Why does it matter if anycast is in use?

Anycast causes a number of problems that are difficult to debug because one 
can't tell which response came from which server.  That's why its important. 
That's why this draft exists.

> Along the lines of why does it matter what implementation is in use?

It doesn't. We agree that the implementation identification can be removed.

> >Obviously, allow non-server operators to distinguish. As I said, server
> >operators can already distinguish.
> 
> Why do the non-operators have to be able to tell?  What business is it of
> theirs?  

This seems somewhat arrogant, to me. DNS is a collective operation.  If my TCP
or stateful queries are failing, and I should be able to figure out that Anycast
is in use, and either arrange to not do stateful queries to those servers, or to
complain to the operator that they are doing Anycast when stateful queries are
needed.

> If they have a problem with a response, and they present it to the operator,
> they don't need to know what instance gave it to them.

Yes, actually, they do need to know that.  When I do testing of root anycast
servers, I need to know if I'm hitting different instances. I can't do that now,
which is why these drafts were proposed.

		--Dean

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

---

From: Dean Anderson <[email-masked]>
Date: Fri, 16 Jun 2006 16:06:01 -0400 (EDT)

On Fri, 16 Jun 2006, Alex Bligh wrote:

> To be clear, that isn't true under my proposal (I don't know if that's why
> you are objecting to it). Different NSIDs could come from different servers
> on different IP addresses; each one could produce multiple NSIDs in order
> to make it appear that anycast was in use, when in fact it isn't (under my
> proposal). Yes, that means that a DNS infrastructure provider can analyse
> his own network without giving away to potential attackers whether or not
> there is Unicast in play, and if so how many unique servers there are. I
> appreciate that doesn't help what you characterize as "legitimate users"
> but currently they aren't helped at all. This allows the infrastructure
> provider to give away as much or as little information as they want to.

This sort of machination isn't what one would call "standard behavior".  Its in
the same category as spoofing OS tcp fingerprints (ala nmap) and that sort of
thing.  Clever, but not really something that needs to be defined in the
standard.

		--Dean

---

From: Alex Bligh <[email-masked]>
Date: Sat, 17 Jun 2006 00:11:55 +0100

--On 16 June 2006 16:06 -0400 Dean Anderson <[email-masked]> wrote:

> This sort of machination isn't what one would call "standard behavior".
> Its in the same category as spoofing OS tcp fingerprints (ala nmap) and
> that sort of thing.  Clever, but not really something that needs to be
> defined in the standard.

I agree. Does it need to be prohibited in the standard though?

Alex

---

From: Dean Anderson <[email-masked]>
Date: Sun, 18 Jun 2006 23:25:38 -0400 (EDT)

On Fri, 16 Jun 2006, Matt Larson wrote:

> On Wed, 14 Jun 2006, Olaf M. Kolkman wrote:
> > 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. 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.
> > 
> > 
> > (Silence or increased entropy do not constitute "clear consensus  
> > building for _not_ ... &c &c".)
> 
> I can live with this text, although I prefer the original text.

Do you mean the text I proposed? 

> This whole thread is getting a bit silly, since the contents of the
> NSID payload is unenforceable, anyway.

Well, of course that's true most of the time. But its not always true, e.g. root
server operators who have legal agreements that compel them to comply with the
standards.  That's why I think this sort of business should be left out of the
standard.  Those people who want to do things with spoofing and hiding,
obviously still can.  

But I don't want to see the root operators doing this sort thing.

> I agree. Does it need to be prohibited in the standard though?

As opposed to just omitted?  Hmm. I think that it should at least be omitted,
and strictly standard behavior should be that anycast instances are identified
universally.  But I could be happy with merely omitting it.  However, in that
case, we also need to remove the following text in 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.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Mon, 26 Jun 2006 18:15:40 -0400 (EDT)

Umm it seems that the language for "as long as the content ... over a series of 
queries" is not included in the new draft -02.

"_not_ removing" seems to mean that it should be included. Right?

Was this a mistake? Or did I miss something?

I certainly missed the legitimate reason to hide anycast instances while seeming
to support NSID....  Anyone who doesn't want allow anycast identification
doesn't need to permit NSID.

Please think of how one would require (say root operators) to support NSID such
that Anycast instances have to be identified.  With the "as long as the content
... over a series of queries" language, you just require them to support and
respond to NSID.  Without this language, it becomes much more difficult to
specify.

The flip side, not giving out NSID information, is easily accomplished by
authorization similar to AXFR, etc.

And the spoofing of responses is certainly not something that needs to be in a
standard.

Why do things differently, now?

		--Dean

On Mon, 19 Jun 2006, Olaf M. Kolkman wrote:
> 
> Kind Colleagues,
> 
> 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).
> 
> 
> --Olaf
> 
> 
> -----------------------------------------------------------
> Olaf M. Kolkman
> NLnet Labs
> http://www.nlnetlabs.nl/
> 
> 
> 
>

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Tue, 27 Jun 2006 11:49:36 +0200

Dear Dean,

> Was this a mistake? Or did I miss something?

I made the mistake of using double negations in
   "I have not seen a clear consensus building for '_not_ removing"...

I should have used  "There is consensus to remove text that requires  
the NSID content to remain constant over a series of queries". I  
agree that this formulation, and earlier use of triple negations, may  
have caused confusion.

But, there was no mistake in determining the rough consensus.

I think that I clearly indicated the guiding principle with "a one  
person call in favor for identifying the any cast instances over a  
series of queries is not sufficient to overhaul an issue that was  
brought up pre-last call". (See [1] and reference therein for the pre- 
last call technical argument for not keeping NSID constant over a  
series of queries).

The determination of rough consensus and the instructions to the  
editor were in line with  this guiding principle.

My sincere apologies for the confusion this may have caused. In the  
future I will try to prevent use multiple negations in last calls and  
consensus summaries.

--Olaf

[1] http://ops.ietf.org/lists/namedroppers/namedroppers.2006/ 
msg00737.html

---

From: Dean Anderson <[email-masked]>
Date: Wed, 28 Jun 2006 15:03:35 -0400 (EDT)

Well said.

Word of the Day for Monday December 8, 2003
otiose \OH-shee-ohs; OH-tee-\, adjective:
1. Ineffective; futile.
2. Being at leisure; lazy; indolent; idle.
3. Of no use. 

		--Dean

On Wed, 28 Jun 2006, Alex Bligh wrote:

> 
> 
> --On 27 June 2006 18:50 -0400 Dean Anderson <[email-masked]> wrote:
> 
> > Alex Bligh agrees that the spoofing provision does not need to be in the
> > standard.  But also doesn't see it necessary to remove.
> 
> 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
> 
>