Subject: Re: nsid last call

From: Dean Anderson <[email-masked]>
Date: Thu, 15 Jun 2006 16:08:00 -0400 (EDT)

On Thu, 15 Jun 2006, Alex Bligh wrote:

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

But it wouldn't tell you anything that a non-NSID response tells them: That 
there are still nameservers operating.  So this isn't a good reason.

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

Right: "hide the number of anycast servers".  I see no good reason to do this.  
This draft exists so that anycast servers can be distinguished.

Server administrators are not in need of NSID. They have etherreal, and server
logs, and server debugging messages to tell them what is going on. NSID is so
that non-server administrators can figure out what is going on.

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

NSID is supposed to do that: distinguish between anycast instances.  Disabling
such distinction subverts the purpose of this draft.

		--Dean

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

--
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: Alex Bligh <[email-masked]>
Date: Thu, 15 Jun 2006 21:13:42 +0100

Dean,

> But it wouldn't tell you anything that a non-NSID response tells them:
> That  there are still nameservers operating.  So this isn't a good reason.

It tells you how many are no longer operating. In a unicast environment
you have no way to know.

> Server administrators are not in need of NSID. They have etherreal, and
> server logs, and server debugging messages to tell them what is going on.
> NSID is so that non-server administrators can figure out what is going on.
>
> NSID is supposed to do that: distinguish between anycast instances.
> Disabling such distinction subverts the purpose of this draft.

The question is "allow whom to distinguish?". If you operate an array
of unicast servers, and you have reports for (say) intermittent failures
when a name is looked up from a client with IP address 1.2.3.4, you
(as administrator) have no way of seeing which unicast server is being
used without NSID. If in answer to the report, you say "OK, please
send me the result of 'dig -t NSID blah'", this is enough as an
administrator to help you, EVEN IF the result is insufficient to help
the person reporting the data to you to understand what is going on.
So, for instance, the client above could send back the result of the
dig which contained an encrypted opaque value. He'd have no idea how
many servers there were, etc, nor which one he'd be accessing. But when
sent to the administrator, it could be deduced by decryption which
the reporter was accessing.

Alex

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 15 Jun 2006 16:34:24 -0400

> such distinction subverts the purpose of this draft.

But as others have already argued, just because remote users can't
make the distinction does not mean that nobody can distinguish them. 
It's supposed to make the instances distinguish_able_, not actually
distinguished.

A

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

---

From: Edward Lewis <[email-masked]>
Date: Thu, 15 Jun 2006 16:43:28 -0400

>It's supposed to make the instances distinguish_able_, not actually

I agree with Andrew.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Nothin' more exciting than going to the printer to watch the toner drain...

---

From: Dean Anderson <[email-masked]>
Date: Thu, 15 Jun 2006 19:09:37 -0400 (EDT)

> make the distinction does not mean that nobody can distinguish them. 

NSID is not useful if only server operators can make that distinction.  As I
said before, server operators already have sufficient tools for their own use.  
They aren't asking for NSID to debug their own servers.  

> It's supposed to make the instances distinguish_able_, not actually

Its supposed to make them distinguished.

		--Dean

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 16 Jun 2006 07:16:21 -0400

On Thu, Jun 15, 2006 at 07:09:37PM -0400, Dean Anderson wrote:
> 
> NSID is not useful if only server operators can make that distinction.  

That's not true, and in any case isn't the only possibility entailed
by having the identifiers be opaque and changing.  It is possible,
for instance, that a server operator could allow some users, but not
all, access to the mechanism for troubleshooting.  This way, unknown
users (who are possibly attackers) can't use the information in an
attack, but known users can do their own troubleshooting.  This might
be a good model for a managed service provider, who can't give the
user access to the network &c.

> Its supposed to make them distinguished.

I don't see support for this stronger claim in the document. On the
contrary, the discussion in section 3.1 points out that there are
several different considerations that need to be taken into account,
and one size does not fit all.  If you think the document says
otherwise, and can point to the text that supports that, I'm happy to
be proven incorrect; but I think the idea that this document entails
policy about what people divulge about their own servers is probably
mistaken.

A

---

From: "william(at)elan.net" <[email-masked]>
Date: Fri, 16 Jun 2006 07:00:00 -0700 (PDT)

> user access to the network &c.

Before making an assumption that NSID would be used in attack, could
you perhaps explain how that is to be done and what benefit having
it brings to the attacker that he oterwise could not do with existing
other dns parameters?

Now If the attack is indeed possible and helped by NSID that should be 
clearly stated in security consideratons with appropraite explanation.

--
William Leibzon
Elan Networks
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 16 Jun 2006 10:33:55 -0400

> it brings to the attacker that he oterwise could not do with existing

Someone has already pointed out that an attacker might use the
information both to profile the servers offering the service, and to
determine how successful an in-progress DoS is.

Moreover, every experience we have with Internet services tells us
"don't advertise more information than is necessary for your
purposes".  I can't see why we should enshrine in this case a
requirement that people advertise some minimum amount of information,
when it might turn out to be useful to attackers in some
circumstances.

Note that the weaker version of the document, which says
that the identifier is purely up to the server administrator, in no
way precludes putting all the information you might want in the
identifier.  It is only the stronger formulation, which requires that
the identifier be useful to remote (and potentially unknown) users
that restricts the operator's choice.  

I'm not arguing that people who are using nsid should never expose
information.  I'm saying instead that, without thinking very long, I
can come up with several scenarios where I can see good reasons not
to have every stranger on the Net be able to figure out,
consistently, exactly which server in a service they are talking to. 
My reading of the draft is that it currently allows operators to make
the identifier sufficiently opaque that at least some people won't be
able to use it for such consistent identification.  I suspect the
disagreement is that what I regard as a feature, others regard as a
deficiency.  I believe that those who want the stronger reading need
to argue why the document should impose the more stringent
requirement, and so far I haven't seen such an argument.

A