Subject: Re: nsid last call

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

On Fri, 16 Jun 2006, Peter Koch wrote:

> On Thu, Jun 15, 2006 at 07:05:55PM -0400, Dean Anderson wrote:
> 
> > 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.

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

-- 
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: [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. ]

Peter Koch wrote on 16/06/2006 09:53:43:

> 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

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