Subject: WGLC: Name Server Identifier Option

From: "Olaf M. Kolkman" <[email-masked]>
Date: Wed, 5 Oct 2005 20:04:14 +0200

Dear colleagues,

In Paris we promised to process the NSID draft as soon as possible
after it appeared.  Its been around for a month, so we are late with
this working group last call for:

     DNS Name Server Identifier Option (NSID)
     draft-ietf-dnsext-nsid-00

Abstract

    With the increased use of DNS anycast, load balancing, and other
    mechanisms allowing more than one DNS name server to share a single
    IP address, it is sometimes difficult to tell which of a pool of
    name servers has answered a particular query.  While existing
    ad-hoc mechanism allow an operator to send follow-up queries when
    it is necessary to debug such a configuration, the only completely
    reliable way to obtain the identity of the name server which
    responded is to have the name server include this information in
    the response itself.  This note defines a protocol extension to
    support this functionality.

Please review your draft and state your support. Technical content
should be addressed on the list editorial nits can be send to the
document editor with a CC to the chairs.

If there is little or no feedback the default action will be to
forward this document to the IESG to be published on the standards
track.

The last call terminates Saturday the 22nd of October.

- - --Olaf and Olafur
DNSEXT Chairs.

- -----------------------------------------------------------
Olaf M. Kolkman
NLnet Labs
http://www.nlnetlabs.nl/
We have employment opportunities, see the website.

--
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: David Conrad <[email-masked]>
Date: Thu, 6 Oct 2005 14:22:49 -0700

> document editor with a CC to the chairs.

Just two comments:

#1:

     2.2  The NSID Option

        The OPTION-DATA for the NSID option is an opaque byte string the
        semantics of which are deliberately left outside the  
protocol.  See
        Section 3.1 for discussion.

Should there be an explicit maximum limit on the length instead of  
relying on the OPTION-LENGTH field?  I'd also note that treating the  
OPTION-DATA field as opaque implicitly violates the assumption of  
2671 that OPTION-DATA be comprised of attribute/value pairs.  Might  
make this explicit.

#2:

     2.3  Presentation Format

        User interfaces MUST read and write the content of the NSID  
option as
        a sequence of hexadecimal digits, two digits per payload octet.

While I understand the intent, I don't believe protocol definitions  
should get into user interface issues, particularly as MUSTs.  I  
might suggest:

     2.3  Presentation Format

        As the data returned in the NSID payload is explicitly not  
specified,
        care should be taken to not assume the data is displayable in  
a raw
        form.  One potential approach would be to read and write the  
content
        of the NSID option as a sequence of hexadecimal digits, two  
digits per
        payload octet.

as well as removing section 3.3 entirely.

Rgds,
-drc

---

From: Samuel Weiler <[email-masked]>
Date: Thu, 6 Oct 2005 21:20:52 -0400 (EDT)

On Wed, 5 Oct 2005, Olaf M. Kolkman wrote:

> Please review your draft and state your support.

I have read this draft (again) and support its publication on
the standards track as-is.

As to DRC's comments:

> #1 ...  Should there be an explicit maximum limit on the length
> instead of relying on the OPTION-LENGTH field?

No opinion.

> #2 ...  I don't believe protocol definitions should get into user
> interface issues, particularly as MUSTs.

Historically, the IETF has specified presentation formats for RRs, and
I think section 3.3 adequately justifies the need for a standardized
one in this case.  I suggest leaving this text as-is.

-- Sam

---

From: Mike StJohns <[email-masked]>
Date: Thu, 06 Oct 2005 22:13:38 -0400

>the standards track as-is.

I apologize for this being my first read-through on this draft.  Mostly OK, 
but I believe the length issue raised by DRC needs correction.  See below.

> > instead of relying on the OPTION-LENGTH field?

I agree with DRC.  Pick a length so that folks who want to build tight code 
can do at least minimal validation.  Also, DNS is being used as transport 
for DDOS communication traffic.  Providing an unlimited length field with 
no semantics that can be tacked on to any DNS packet seems a bit like a 
gift to those trying to evade firewalls.  Pick a length - 16 octets to 
cover v6 addresses?

>Historically, the IETF has specified presentation formats for RRs,

1) This isn't an RR, its part of an existing RR
2) Pseudo-RRs generally don't get presentation formats.  This is part of 
the OPT Pseudo RR.

>  and
>one in this case.

"It is much more important for the NSID payload data to be passed
    unambiguously from server administrator to user"

This text should be "from user to server administrator" instead (section 
3.3 that is) as its clear this is what's meant in the rest of the 
paragraph.  And the requirement is no better than a "SHOULD" since its not 
critical for proper operation of the protocol.  Also, the "SHOULD" should 
only be with respect to at least form of presentation - e.g. its OK to 
print out the ASCII or local character set equiv in addition to hex.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 07 Oct 2005 16:25:08 +1000

> --=====================_112862467==.ALT
> Content-Type: text/plain; charset="us-ascii"; format=flowed
> 

	This does not need a arbitary length constraint.

	DDoS is complete FUD.  You already can get maximal responses
	today without this option.

	Firewall evading is also complete FUD.  It is already easy
	enough to use the DNS as a covert channel.

	For what it is worth 16 is way too short.  I'd atleast
	make it big enough to hold a domain name.

> 2) Pseudo-RRs generally don't get presentation formats.  This is part of 

	Which just makes it harder for those writing packet dumpers.

	Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Rob Austein <[email-masked]>
Date: Fri, 07 Oct 2005 02:46:20 -0400

At Thu, 06 Oct 2005 22:13:38 -0400, Michael StJohns wrote:
> paragraph.

Yes and no.  The point is that the NSID payload needs to survive a
round trip from server admin through DNS protocol to client user then
all the way back again via protocols unknown (email, web form, two tin
cans and a piece of wet string...) to the server admin.  I was
focusing on the outbound trip, Mike is focusing on the return.

This could probably be clearer.  Good catch.

---

From: Rob Austein <[email-masked]>
Date: Fri, 07 Oct 2005 02:49:56 -0400

> 	make it big enough to hold a domain name.

Mark is correct that the design is intended to allow DNS names to be
used as the NSID payload.

---

From: David Conrad <[email-masked]>
Date: Fri, 7 Oct 2005 00:01:12 -0700

I personally dislike dealing with undefined maximums when writing  
variable length field parsers (that should probably be in the past  
tense, sigh).  I'll start the bidding at 256 bytes...

---

From: David Conrad <[email-masked]>
Date: Fri, 7 Oct 2005 00:07:55 -0700

>     This does not need a arbitary length constraint.

No, it doesn't _need_ it.  It just makes doing the parser a teensy  
bit less likely to screw up and lead to buffer overflow exploits.   
This isn't a big issue, I just thought it'd be nice to provide an  
explicit limit.

>>> Historically, the IETF has specified presentation formats for RRs,

Which many people argue was a bad idea and has led to many people  
writing broken RR parsers that don't deal with escaping properly,  
makes invalid assumptions about what can and cannot be in a label or  
rtype or rdata, etc.

>     Which just makes it harder for those writing packet dumpers.

If you're writing a packet dumper, I suspect you already have code to  
deal with arbitrary binary data.

Rgds,
-drc

---

From: Francis Dupont <[email-masked]>
Date: Fri, 07 Oct 2005 10:58:41 +0200

In your previous mail you wrote:

=> for the idea itself I believe it is very useful. I use it for instance
to understand a problem with the F root server in Paris (TCP connections
from some ISPs were reseted).

Regards

[email-masked]

---

From: Peter Koch <[email-masked]>
Date: Fri, 07 Oct 2005 14:44:59 +0200

> 2671 that OPTION-DATA be comprised of attribute/value pairs.  Might  

my reading of 2671 is that the (CODE/LEBGTH/DATA) container described in
section 4.4 already *is* the "attribute,value" pair. Otherwise there's
nothing said about the separator between attribute and value and the
charset issues. Maybe a clarification to 2671 is needed when it goes to Draft.

But as you mention the length: what is the responding server supposed to do
if putting in the requested information would exceed either 512 octets
or the maximum available payload size as "negotiated" between the
requestor and itself?

Will the EDNS version to be announced remain "0"?

-Peter

---

From: Paul Vixie <[email-masked]>
Date: Fri, 07 Oct 2005 13:37:50 +0000

i still want this to be symmetric.  that is, the client should be able to
send an opaque identifier to the server, too.

---

From: Paul Vixie <[email-masked]>
Date: Fri, 07 Oct 2005 13:49:54 +0000

# > OPTION-DATA field as opaque implicitly violates the assumption of  
# > 2671 that OPTION-DATA be comprised of attribute/value pairs.  Might  
# > make this explicit.
# 
# my reading of 2671 is that the (CODE/LEBGTH/DATA) container described in
# section 4.4 already *is* the "attribute,value" pair.

yes.

# Otherwise there's nothing said about the separator between attribute and
# value and the charset issues. Maybe a clarification to 2671 is needed when
# it goes to Draft.

suggestions welcome.  but i think drc wanted the NSID option to have its own
interior attr:value segmentation structure, in which case the clarification
should be in drc's proposal rather than in 2671.

# Will the EDNS version to be announced remain "0"?

yes.  implementations of EDNS are expected to ignore options they don't
recognize.  THAT is something we can clarify when 2671 goes to draft.
the version number is about the message format and message field meanings;
it doesn't have to do with content like OPT options.

---

From: Rob Austein <[email-masked]>
Date: Fri, 07 Oct 2005 12:26:11 -0400

> send an opaque identifier to the server, too.

Paul, we've discussed this.  You're welcome to propose another option
that does what you want, but (in my opinion -- WG chairs can speak for
themselves) you have not justified tying your proposal to this one.
It's a different problem space, probably with different constraints,
and certainly with different protocol behavior.

The discussion in Paris was pretty clear on wanting to get the NSID
mechanism out the door as it stands, without further bells or
whistles.  The WG is of course free to revise that plan, but so far I
have not heard anybody but Paul asking for this feature.

---

From: David Conrad <[email-masked]>
Date: Fri, 7 Oct 2005 10:20:38 -0700

On Oct 7, 2005, at 5:44 AM, Peter Koch wrote:
> section 4.4 already *is* the "attribute,value" pair.

D'oh.  Needed more caffeine.  Apologies.

> or the maximum available payload size as "negotiated" between the

Set the truncate bit?

> Will the EDNS version to be announced remain "0"?

I'd wouldn't think there would be a need...

Rgds,
-drc

---

From: Paul Vixie <[email-masked]>
Date: Fri, 07 Oct 2005 17:42:07 +0000

# The WG is of course free to revise that plan, but so far I
# have not heard anybody but Paul asking for this feature.

it's last call, i'm just putting my position on the record.

---

From: David Conrad <[email-masked]>
Date: Fri, 7 Oct 2005 11:36:11 -0700

I have no opinion as to what Paul wants, not having been in Paris,  
but to make everybody happy (?), perhaps the document/option could be  
renamed "Name Service Identifier Option" and the document clarified  
to say something like "behavior of the server receiving a NSID OPT RR  
will be defined in a subsequent document"?

Rgds,
-drc

---

From: Peter Koch <[email-masked]>
Date: Mon, 10 Oct 2005 16:11:09 +0200

> > or the maximum available payload size as "negotiated" between the

so, if options take precedence over responses/referrals that should be
said somewhere, especially if we're discussing "long" NSID identifications.

-Peter

---

From: Peter Koch <[email-masked]>
Date: Mon, 10 Oct 2005 22:11:57 +0200

> should be addressed on the list editorial nits can be send to the

I've read the document and generally support it going onto standards track.
Some remarks and some responses to remarks made by fellow namedroppers:

o length indication

  I do not see a need to further structure the OPTION-DATA to allow for
  an additional length indicator nor do I see the need to explicitly limit the
  maximum length to less than the natural limit of 64k (well, actually less
  due to RLEN restrictions). When speaking about DoS there are two
  opportunities:

  1) Responding server DoSing querying client (as a revenge for invading its
     privacy ...)

     There are probably easier DoS measures already, including games with
     OPTION-LENGTH and so on. Limits won't help since the client would
     still have to deal with malicious violations of those limits.
     A caveat in the security considerations section might be useful.

  2) DoS amplification by sending large responses upon small queries (using
     forged src addresses)
     One would need many servers with large NSID payload and the same might
     already be achieved today with just "root referrals".

  However, when it comes to length problems, the conflict between truncation
  and honoring the SI flag should be discussed.

o Presentation format

  This needs to be defined and should be kept as is (modulo the change to
  emphasize the human part in the loop). Any deeper involvement of strings
  opens this to the i18n game, which to avoid seems a good idea.
   
o NSID content

  The draft lists and discusses a variety of ways to fill NSID, all of
  which suggest a static mapping of server instance to NSID value. As I
  mentioned in Paris, I'd like to have the option of changing that value
  per query (keeping track internally). This is one way to avoid discovering
  the number of anycast nodes behind a load balancer and there might be
  other reasons. The person debugging then can't even tell whether
  subsequent responses originate from the same server, but it could hand over
  the info received to the server admin for further inspection.

o SI/NSID non transitivity

  The message is clear, but can we expect implementations agnostic of SI/NSID
  to behave? (I know section 4.1 of 2671 forbids forwarding of OPT RRs).

o "Symmetry" of NSID

  In Paris we agreed that for the sake of getting this out the door any
  extensions like end2end identification or client identification should
  be defined in separate drafts - if the need be. I'm just wondering why
  we "waste" both an option code and a flag bit (which is more precious)
  instead of requesting server identification by an NSID option (even an empty
  one) in the query.

-Peter

---

From: Paul Vixie <[email-masked]>
Date: Mon, 10 Oct 2005 21:44:26 +0000

# o "Symmetry" of NSID
# 
#   In Paris we agreed that for the sake of getting this out the door any
#   extensions like end2end identification or client identification should be
#   defined in separate drafts - if the need be. I'm just wondering why we
#   "waste" both an option code and a flag bit (which is more precious)
#   instead of requesting server identification by an NSID option (even an
#   empty one) in the query.

i wonder the same.

---

From: Rob Austein <[email-masked]>
Date: Tue, 11 Oct 2005 15:03:14 -0400

At Mon, 10 Oct 2005 22:11:57 +0200, Peter Koch wrote:
> 
>   However, when it comes to length problems, the conflict between
>   truncation and honoring the SI flag should be discussed.

Good catch, thanks.

> o NSID content
> 
>   The draft lists and discusses a variety of ways to fill NSID, all
>   of which suggest a static mapping of server instance to NSID
>   value.
>   As I mentioned in Paris, I'd like to have the option of changing
>   that value per query (keeping track internally). This is one way
>   to avoid discovering the number of anycast nodes behind a load
>   balancer and there might be other reasons. The person debugging
>   then can't even tell whether subsequent responses originate from
>   the same server, but it could hand over the info received to the
>   server admin for further inspection.

Thought I'd covered this:

   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.

If that's not enough, send text. :)

> o "Symmetry" of NSID
> 
>   In Paris we agreed that for the sake of getting this out the door
>   any extensions like end2end identification or client
>   identification should be defined in separate drafts - if the need
>   be. I'm just wondering why we "waste" both an option code and a
>   flag bit (which is more precious) instead of requesting server
>   identification by an NSID option (even an empty one) in the query.

If the WG would prefer that we just use an empty NSID option rather
than the SI flag bit, that's a simple change.

Absent a specification for what non-empty NSID payload from client to
server would mean, I think it should be empty (name server MUST ignore
NSID payload, client MUST NOT/SHOULD NOT send NSID payload).  If and
when the WG specifies what client->server payload looks like, how it's
supposed to work, etc, that specification can just update this one if
the WG concludes that reusing the NSID option is appropriate.  I still
suspect that the client->server case is different enough that it
should be a separate option, but hey, I could be wrong.

My main concerns at this point are: (a) that this specification be
complete rather than making forward references to specifications that
might never be written, and (b) that we finish this promptly, per the
discussion in Paris.

---

From: Peter Koch <[email-masked]>
Date: Fri, 28 Oct 2005 18:17:19 +0200

>       queries had been answered by the same server.

yes, indeed. Please accept my apology.

> than the SI flag bit, that's a simple change.

Good.

> NSID payload, client MUST NOT/SHOULD NOT send NSID payload).  If and

Agreed. "MUST ignore" is future safe (forward compatible) on the server side.

> might never be written, and (b) that we finish this promptly, per the

Same here. My suggestion was not meant as a preparation of client side ID.
Whether or not this option can be reused I don't care for now.

-Peter