Subject: Re: nsid last call

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

On Thu, 15 Jun 2006, Alex Bligh wrote:

> Dean,
> 
> >> > 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.
> 
> It tells you how many are no longer operating. In a unicast environment
> you have no way to know.

It only tells you that some are still operating.  The NSID doesn't tell you how
many.  But different NSIDs show that Anycast is in use.

In a unicast environment, you absolutely have a way to know if a unicast server
is operating: dig <something> @<unicast address>. If you get a response back,
the server is still operating.

The "DOS" attack argument seems to be a red-herring, to me.  There is no benefit
to the DOS attacker from knowing that anycast is in use.  Even if there was a
benefit to DOS attackers, I don't think it would outweigh the benefit to
legitimate users to know that anycast is in use.

> > 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.
> 
> The question is "allow whom to distinguish?". 

Obviously, allow non-server operators to distinguish. As I said, server
operators can already 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.

???? This doesn't make sense to me.  Unicast is not-anycast.  NSID is meant to
distinguish anycast servers.

But plainly one can tell which unicast server is not responding.....

NSID isn't invented to fix unicast problems. Its purpose is to fix anycast
problems: the problem being that you can't tell which anycast instance responded
to a particulary query.

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

I don't think this is terribly helpful.  With unicast servers, you don't need 
NSID, as you can say 'dig <something> @<unicast> and get exactly what you need.

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

The user ___could___.  But why?  I wouldn't want to have to debug every client
that has a problem.  Your encrypted scheme requires the server administrators to
figure out why a client has a network latency problem.  Right now, with Unicast
servers, they can figure that out for themselves.

The goal of NSID is to have this same capability to distinguish anycast servers.  
As it is, we can't tell which one handled our query.

		--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: Fri, 16 Jun 2006 09:27:36 +0100

--On 15 June 2006 19:05 -0400 Dean Anderson <[email-masked]> wrote:

> It only tells you that some are still operating.  The NSID doesn't tell
> you how many.  But different NSIDs show that Anycast is in use.
> Even if
> there was a benefit to DOS attackers, I don't think it would outweigh the
> benefit to legitimate users to know that anycast is in use.

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.

Currently the choice for the operator is to give away all information or
nothing. Given that in practice there are no RFC-police to go check up on
what they are doing, and no client means of differentiating between opaque
NSIDs and just very extensive anycast, producing opaque NSIDs is in any
case going to be a practical proposition. So why outlaw it, when the effect
may be to discourage operators from taking it up at all? It isn't as
if it complicates the protocol.

>> 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.
>
> ???? This doesn't make sense to me.  Unicast is not-anycast.  NSID is
> meant to distinguish anycast servers.

Sorry - "if you operate an array of ANYCAST servers" - my typo (and
"anycast" in the bottom line too.

>> 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.
>
> I don't think this is terribly helpful.  With unicast servers, you don't
> need  NSID, as you can say 'dig <something> @<unicast> and get exactly
> what you need.

My example probably makes more sense if you know I'm talking about anycast
not unicast :-)

Alex

---

From: Peter Koch <[email-masked]>
Date: Fri, 16 Jun 2006 10:53:43 +0200

> The goal of NSID is to have this same capability to distinguish anycast servers.  

strictly speaking nsid is there to identify servers, not necessarily to
distinguish them. More importantly, the draft makes it very clear that
the only entity the payload has to have meaning for is the server operator.
And, finally, we shouldn't mix policy with protocol here. Since an operator
is free to enable nsid or not or to apply ACLs to the NSID feature, there's
no gain in requiring that nsid blobs remain constant for a particular
instance (however you define that).

-Peter

---

From: Edward Lewis <[email-masked]>
Date: Fri, 16 Jun 2006 10:28:02 -0400

>many.  But different NSIDs show that Anycast is in use.

Why does it matter if anycast is in use?

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

>operators can already distinguish.

Why do the non-operators have to be able to tell?  What business is 
it of theirs?  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.

I suppose there's a basic assumption that clients ought to be 
debugging problems in someone else's service.  That may be the old 
way of doing things - when there was a common mode of operation on 
the Internet.

It's foolhardy and rude to debug someone else's service problems. 
Fool hardy because you don't know the entire story - who else is 
experiencing problems?  Maybe it's not the server but some odd-ball 
box at an ISP in the way.

I've seen lots of weird problems in my day - including a half-working 
T-1 (back in the day) that worked just good enough to fool the router 
at the monitoring end but not good enough to carry data.

Unless you sit at the service NOC, you're not going to be able to 
debug the most gnarly of problems.

It's also rude, because it's a fine line between debugging someone 
else's service and probing for a weakness to exploit.

A long time ago I used some proprietary code putting TCP/IP on a Vax. 
The code had bugs and so I filed a report with a diagnosis.  My 
diagnosis was so detailed and "correct" (not a big deal, in those 
days the net was simple) they came back and accused me of stealing 
their source code.  It took a mutual friend (like I said, small world 
then) to convince them that 1) I didn't have the code, 2) I did have 
deep knowledge of the problem and 3) they themselves had used the 
same variable names as appeared in Stevens' book.

This wordy walk into the past is meant to say that I think the desire 
to allow a client to determine which or how many servers are out 
there is outmoded.  It's as outmoded (for the same reasons) as 
leaving servers open for AXFR.  This is the same as the NSEC3 debate, 
except this time it's the service, not the data, being exposed.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

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