Subject: Re: nsid last call

From: Olaf M.Kolkman <[email-masked]>
Date: Tue, 13 Jun 2006 15:18:10 +0200

Colleagues,

This is to close the remaining issues.

On the second issue we did not see consensus to change the text and  
it will remain as is

> In section 2.3:
>
> OLD:
> The OPTION-DATA for the NSID option is an opaque byte string the  
> semantics of which are deliberately left outside the protocol.

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.

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.

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

---

From: Peter Koch <[email-masked]>
Date: Tue, 13 Jun 2006 16:20:34 +0200

>      over a series of queries. The NSID can be opaque and encoded  

sorry to disagree, but in the Paris meeting and subsequently in
<http://www.ops.ietf.org/lists/namedroppers/namedroppers.2005/msg01347.html>
I explicitly asked to have this as dynamic as possible and neither were
there any objections nor can I see much discussion, lest support for this
180 degree change. Please remove "as long as the content ... over a series
of queries".

>      This section describe some of the kinds of data that server  

[...]

The rest of the more verbose explanation is fine, though.

-Peter

--
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: Edward Lewis <[email-masked]>
Date: Wed, 14 Jun 2006 10:16:51 -0400

At 14:37 +0200 6/14/06, Olaf M. Kolkman wrote:

>Now for a fair way to get closure on this issue;

Can you provide a link to the document?  (The thread began as an 
"Re:" as far as I can tell.)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

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

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Wed, 14 Jun 2006 14:37:14 +0200

> 180 degree change. Please remove "as long as the content ... over a  

Fair point Peter, I'm always happy to see you disagree and in this  
case you made me painfully and rightfully aware that this issue was  
in fact already explicitly brought up before last call and I had just  
forgot about it.

Anyway, this causes a bit of dilemma since during this post last-call  
debate Dean made an argument in favor of being able to identify the  
any cast nodes as a client while you made the argument to hide  
instances behind an anycast based load sharing system.  These are  
clearly conflicting.

I think that 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. On the other hand I'd like  
to give others the possibility support one of the two views. So, I  
will not close the issue yet. We leave it open for another few days  
and unless there is no clear consensus building for _not_ removing  
"as long as the content ... over a series of queries" I propose to  
converge to:

3.1.  The NSID Payload

      content. The NSID can be opaque and encoded such that it

(Silence or increased entropy do not constitute "clear consensus  
building for _not_ ... &c &c".)

phewww,

--Olaf

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Wed, 14 Jun 2006 17:59:50 +0200

> "Re:" as far as I can tell.)

Apologies,

I messed up the subject header.

The first mail in this thread (http://ops.ietf.org/lists/namedroppers/ 
namedroppers.2006/msg00735.html) should have been a continuation of  
the thread starting at:
http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00684.html

Hope this clarifies.

--Olaf

---

From: Edward Lewis <[email-masked]>
Date: Wed, 14 Jun 2006 12:23:09 -0400

At 17:59 +0200 6/14/06, Olaf M. Kolkman wrote:

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

I don't see the purpose of this change:

# In section 2.3:
#
# OLD:
# The OPTION-DATA for the NSID option is an opaque byte string the semantics of
# which are deliberately left outside the protocol.
# NEW:
# The OPTION-DATA for the NSID option is an opaque byte string the semantics of
# which are deliberately left outside the protocol. Implementations MUST
# implement manual configuration of the NSID string.

(Altering NSDID to NSID in the last line.)

This does not impact interoperability (it's not in the protocol).

Not all server implementations will need to do this, e.g., turnkey 
DNS code paths, code that is not distributed, etc.  It some 
situations, hardcoding one value for this field may work quite well.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

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

> 180 degree change. Please remove "as long as the content ... over a series

This change is what has been discussed recently. I don't see that as a very
great change, even though it may not be exactly what you wanted in Paris. I 
wasn't at Paris, so I don't know what was agreed there, but presumably review by 
a wider audience has its benefits....

Can you explain why this should be allowed to be changed on a per-packet basis?

It is actaully very dynamic as I worded it.

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 think I would object to the 'each query unique secret' version, with some good
reasons for that.

		--Dean

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

---

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

---

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

> you might well like to know how many you had disabled. You could look

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.

> That way only persons in possession of a key could tell two servers

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.

> 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

---

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.

---

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

> It tells you how many are no longer operating. In a unicast environment

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.

> 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

---

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

---

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

---

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

On Fri, 16 Jun 2006, Peter Koch wrote:

> distinguish them.

If you can't uniquely distinguish them, then they aren't identified.  
Identification implies uniqueness.  If I show my drivers licence to 2 people,
they should be able to agree it was me.  Showing them each some incomparable
encryption that only I can decode is not an identification.

Moreover, this just seems to split hairs and ignore the history of this draft.  
Remember, that this proposal developed from the BIND CH query to return the
server id. In 2002, dnsop-serverid-00
(http://ietfreport.isoc.org/all-ids/draft-ietf-dnsop-serverid-00.txt) was
submitted. After 5 dnsop-serverid drafts, it is finally realized that this
serverid scheme won't work for anycast, and a stateless EDNSO NSID is proposed
in February, 2005.

There is no talk of secrecy in any of these prior drafts.

> More importantly, the draft makes it very clear that the only entity the
> payload has to have meaning for is the server operator. 

I object to that notion as well.  It has no basis in any prior history, and I
certainly missed that change....  

But my read was that they can encode information that only has meaning to them.  
This is in lieu of the implementation information. That did not mean that they
can or should make it impossible for me to identify anycast instances.

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

Absolutely there is a gain to have per-instance-constant blobs: One can tell if
Anycast is in use, and if different anycast instances are returning different
data.  Or if it is Anycast is in use when stateful queries are being made.  
Anycast operators can't hide problems resulting from Anycast.

Incidentally, adding non-constant NSIDs adds a new DDOS attack in that the
calculation of a decryptable per-packet NSID is a cryptographic function that
would take CPU resources to calculate.

But since an operator is free to enable nsid or not, or apply ACLs, that seems
to address any questions about its value to DDOS attackers.  So there seems to
be no valid reason that NSID should be variable and indistinguishable.  That
feature seems only to subvert the purpose of the draft.

My view: If they enable NSID, it had better be a per-instance-constant
identifier that everyone can see and agree is instance-unique.  Subverting that
notion is pretty significant.

		--Dean

---

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

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

> 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

---

From: [email-masked]
Date: Fri, 16 Jun 2006 17:39:16 +0100

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

> And, finally, we shouldn't mix policy with protocol here. Since an 
operator

I agree. Whatever reasons there are for or against having unique, constant 
or obscure content in the NSID it is a policy decision that should be made 
by the operator and has nothing to do with protocol.

John

====
John Dickinson
Nominet UK
====

---

From: Matt Larson <[email-masked]>
Date: Fri, 16 Jun 2006 17:12:38 -0400

> building for _not_ ... &c &c".)

I can live with this text, although I prefer the original text.

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

How about directing all this energy to reading the various trust
anchor management proposals?

Matt

---

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

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

> I can live with this text, although I prefer the original text.

Do you mean the text I proposed? 

> 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: <[email-masked]>
Date: Mon, 19 Jun 2006 07:39:47 +0100

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

That may be, but that's an issue which is completely outside
the scope of the protocol.  Specifying this in (or omitting it
from) the protocol will not govern or control how it is used in
the wild, by the root server operators or anyone else.

>       queries had been answered by the same server.

I think it's preferable to keep this in as an illustration of the
degree to which the protocol is agnostic to payload content.

[Nit: this should be "dynamically", not "dynamicly".]

Geoff

---

From: Alex Bligh <[email-masked]>
Date: Mon, 19 Jun 2006 10:17:34 +0100

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

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

The disadvantage of it being omitted completely is there is nothing to warn
the potential NSID client user that they might be dynamically generated.
This might confuse people - the latter is really just an illustration of
what might happen in a payload reply such as "none of your business". I
could also live with it being omitted though I would prefer some
caveat for the receiver of packets. I agree we should not be seeking to
imply that there is some sort of endorsement or recommendation for
opaque NSID in the absence of current operational REQUIREMENT to
mandate it.

Alex

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Mon, 19 Jun 2006 11:55:36 +0200

On Jun 14, 2006, at 2:37 PM, Olaf M. Kolkman wrote:
>
> I think that 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. On the other  
> hand I'd like to give others the possibility support one of the two  
> views. So, I will not close the issue yet. We leave it open for  
> another few days and unless there is no clear consensus building  
> for _not_ removing "as long as the content ... over a series of  
> queries" I propose to converge to:
>
>
>
> 3.1.  The NSID Payload
>

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

---

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

---

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: Tue, 27 Jun 2006 18:50:49 -0400 (EDT)

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

It seems difficult to assert that while several people including the
Chair, can be confused and confusing, that consensus is still correctly
achieved amid such confusion.

> last call technical argument for not keeping NSID constant over a

Well, since I didn't prompt the change you posted on June 13, nor the
subsequent discussion of changing this text, (I almost missed it
entirely), there are, at the very least, 2 people who agree with
identifying anycast instances over a series of queries.  So it cannot be
a "one person call"  At the very minimum, it is a 2 person call.  I
think perhaps it is even larger.

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 agrees that the spoofing provision does not need to be in the
standard.  But also doesn't see it necessary to remove.

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 you (Olaf Kolkman) agreed it should not be
in the standard, though perhaps your mind was changed...

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

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

No one else posted on the subject.

> editor were in line with this guiding principle.

There seems to be confusion on all sides, so I don't assert that you did
anything _intentionally_ wrong on the consensus. But I think it was
still wrong, though innocently so. [As I've recently asserted some
not-innocently wrong claims of consensus in complaint to the IESG, I
think it is important to state a distinction between in an innocent
mistake and a not-innocent mistake.] I believe this is an innocent
mistake on your part, but a mistake.

> future I will try to prevent use multiple negations in last calls and  

Thank you very much.

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

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Wed, 28 Jun 2006 08:11:54 +0200

Dear Dean,

Thanks for you reply. I acknowledge receiving your concerns. I think  
that my last message explained the leading principle in determining  
the rough consensus and I stand by that consensus determination.

--Olaf

---

From: Alex Bligh <[email-masked]>
Date: Wed, 28 Jun 2006 09:34:23 +0100

> 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

---

From: Edward Lewis <[email-masked]>
Date: Wed, 28 Jun 2006 12:00:43 -0400

At 18:50 -0400 6/27/06, Dean Anderson wrote:

>Strongly for spoofing:

s/for/for allowing/

>Ed Lewis

My assessment is that spoofing (as you are using the term) is neither 
an obstacle nor a requirement to achieve interoperability.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Soccer/Futbol. IPv6.  Both have lots of 1's and 0's and have a hard time
catching on in North America.

That tournament in Germany.  What's all the fuss?  (Get it? "fuss?")

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 28 Jun 2006 14:38:50 -0400

> Strongly for spoofing:
[. . .]
> Andrew Sullivan

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.

A

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

---

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