Subject: [dnsext] experimental/testing DNSSEC algorithm identifiers

From: Jelte Jansen <[email-masked]>
Date: Wed, 12 Aug 2009 09:54:29 +0200

Hi,

when working towards adding a new signing algorithm for DNSSEC, we want to test
interoperability. To do that in any reasonable kind of way, we need to have an
algorithm number before it is allocated. Recent experience has taught us that
guessing the number has its dangers; when these temporary algorithm ids 'leak'
into deployed implementations, it could cause unexpected problems if the ids end
up being used for another algorithm.

We have 'private', but that's only one number, and currently there are multiple
algorithm proposals. Besides, it might clash with actual privates that are used.

So I would like to propose reserving a few identifiers for testing purposes. Say
the numbers 245-250, or even 240-250. While working towards an rfc, drafts could
use one of these so implementers can have an agreed-upon number for interop
testing, and if they end up being seen in the wild, at least we know right away
what the problem is. And perhaps do the same for DS and NSEC3 algorithms.

Given the current policy, this needs a wg draft, which i'm willing to write, and
no i can't believe i'm actually proposing more work for the wg :p

Any thoughts?

Jelte

--
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: Ondřej Surý <[email-masked]>
Date: Wed, 12 Aug 2009 10:15:42 +0200

> what the problem is. And perhaps do the same for DS and NSEC3 algorithms.

Seems reasonable and I am willing to review the draft.

Ondrej.
--
Ondrej Sury
technicky reditel/Chief Technical Officer
-----------------------------------------
CZ.NIC, z.s.p.o.  --  .cz domain registry
Americka 23,120 00 Praha 2,Czech Republic
mailto:[email-masked]  http://nic.cz/
sip:[email-masked] tel:+420.222745110
mob:+420.739013699     fax:+420.222745112
-----------------------------------------

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 12 Aug 2009 06:11:08 -0700

>no i can't believe i'm actually proposing more work for the wg :p

At the Stockholm meeting, I volunteered to write the draft revising the algorithm allocation rules. The topic of "experimental" allocations was not brought up, but could be considered in the draft. I'm hoping to have the first draft out later this week.

Having said that, the IETF has a long and painful history of protocols with identifiers reserved for testing. If the WG wants to have such identifiers, the wording in the document about what they mean will be very important.

--Paul Hoffman, Director
--VPN Consortium

---

From: Edward Lewis <[email-masked]>
Date: Wed, 12 Aug 2009 10:26:34 -0400

>Any thoughts?

In summary - I have doubts about the future of this proposal, no 
matter how worthy it is.

Why I am being a grump:

We (DNSIND/DNSEXT WGs)'ve had a bad experience with proposals to 
allocate "general pool" numbers.  There is the Kitchen SINK RR 
(RRType = 40, 
http://tools.ietf.org/html/draft-ietf-dnsind-kitchen-sink-02) and a 
generic key application for the old KEY RR 
(http://tools.ietf.org/html/draft-lewis-dnsext-key-genprot-00).

(Okay, those both wanted a number for general purpose use.  But the 
pool could have been greater than "one" in size.)

The dynamic in the development process is this.  (Assuming the goal 
is to get something on the standards track.)  First you want initial 
development you need to plug in a number.  You then need to produce a 
document to get the idea out.  Following this you want there to be 
some wide spread experimentation, which often borders on initial 
deployment.  With this you are prepared for standards vetting and 
then initial deployment.

The snag in this process is that your experimental deployment will 
use value 243 but IANA will give you the value 93.  You then need to 
uproot all the early adopters.  This problem is what has driven many 
applications to use the TXT record - in the case when the number in 
question is the RR type.

The difference here is that you are talking about a different 
protocol parameter, one that is more obscure.  But you will have the 
same issue when you do from -draft-" to RFC/PS and then DS.

Another problem is the documentation issue.  Look at SINK.  Yes, 
there's no RFC because the WG lost it's will to finish off the 
experiment.  On the one hand, we have the number burned into the 
registry and a way to find information about SINK.  Yes, it says 
"Eastlake" and if you know him, you can reach him.  You can also 
search for the draft in many repositories, now even the IETF has one.

If SINK had used an experimental value, you couldn't even do that. 
You might tcpdump and see something using value 243 - but until you 
fingerprinted the source IP address you might not be able tell if 
that was Jelte's bad idea of 2009 or Blacka's bad idea of 2003 (or 
even Jelte's bad idead of 2010, 2011, ...).  Reused numbers make it 
hard to do a text search for "what's happening?"

(Recall the question of "where are all the A6 queries coming from?" 
asked in 2007.  Many of knew right away - BIND - because A6 was a 
specific allocation, fully documented, moved to experimental and 
recognized as a truly had idea by all sane people.  I said "sane.")

The only place that allocating numbers for "private use" that has 
worked is in IPv4 because we have NAT.  (Which everyone "hates" to 
some extent.)  I know there's a call for them in IPv6 because we are 
used to them in IP address management.  Reusable numbers work in IP 
because we control them with the routing system, we don't have a 
similar scoping mechanism available for an application protocol.

I wish that I could be more optimistic about this effort.  I wanted 
to do it once too (for the KEY RR).  But it never seems to work.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 12 Aug 2009 08:38:46 -0700

At 10:26 AM -0400 8/12/09, Edward Lewis wrote:
>In summary - I have doubts about the future of this proposal, no matter how worthy it is.
>
>Why I am being a grump:

+1 to what Ed said. But I'll include a straw man in the -00 of the draft and see what others think.

--Paul Hoffman, Director
--VPN Consortium

---

From: Samuel Weiler <[email-masked]>
Date: Tue, 18 Aug 2009 15:04:55 -0400 (EDT)

On Wed, 12 Aug 2009, Jelte Jansen wrote:

> We have 'private', but that's only one number, and currently there 
> are multiple algorithm proposals. Besides, it might clash with 
> actual privates that are used.

While there are only two private numbers, we did define mechanisms for 
distinguishing between private algorithms (RFC4034, A.1.1).  It may 
well be that such code, if it exists, is buggy, but I think it's worth 
figuring that out.

Given the mechanism in 4034 A.1.1., do you really need more codepoints 
just for testing?

-- Sam