Subject: Re: IANA document

From: "Theodore Ts'o" <[email-masked]>
Date: Thu, 29 Jan 2004 09:01:16 -0500

On Wed, Jan 28, 2004 at 09:46:31PM -0500, Michael Richardson wrote:
> I don't know where things are going with this. If it will be published,
> then it needs a revision perhaps, and I'd like to do this before document
> deadline. 
> 
> If it isn't going to be published (original plan), then I think that it is
> done, and should go to some kind of WG last call, and get fed to IANA for
> their thoughts.
> 
> I'm totally cool if Charlie just takes the text and puts it into IKEv2.

Hi Michael, I was planning on sending this note a few days ago, but
work just got me completely swamped.  My apologies for it being
somewhat terse, but I figured it would be better to send something
short rather than to delay replying to you...

I've been looking at RFC 2434, and it looks like there are some
requirements for what needs to be in the IANA consideration section
that doesn't quite meet with what's in draft-ietf-ipsec-ikev2-iana-01.txt.
In particular, what RFC 2434 suggests that the text read something like:

	Following the policies outlined in [RFC 2434],
        numbers in the range 0-1234 are allocatred using the Expert
	REVIEW policy, and the numbers in the range 1024 - 65535 are
	reserved for Private Use.

RFC 2434 also states that this text needs to be in an RFC; so I don't
think just publishing this in an I-D and giving it to the IANA cuts
it.  There still is the question of whether it needs to be in the
IKEv2 specification or in a separate stand-alone document.  I'm
personally agnostic on the subject, except insofar as which one gets
us done faster.

In addition, I am wondering if we need to adjust the allocation
policies as currently defined in ikev2-iana-01 document.  It seems
strange to me that the relatively small ranges, such as the IKEv2
Payload types (only 255 possible values) have relatively loose
policies, such as "Specification Required", whereas some ranges that
are much larger, such as the IKEv2 Integrity Algorithm Transform ID's
(with 65536 possible values) have "Expert Review" as the policy.  

I understand that you probably just used the IANA policies from the
original IKEv1 and ISAKMP specs.  But it's not clear to me that they
are completely coherent.

Comments?  

						- Ted

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Thu, 29 Jan 2004 09:09:27 -0800

At 9:01 AM -0500 1/29/04, Theodore Ts'o wrote:
>it.

Maybe you are mistaking the fact that RFC 2434 is *about* IANA 
sections in RFCs. If fact, in the middle of section 2, it says "In 
some cases, however, the burden of publishing an RFC in order to get 
an assignment is excessive." That seems pretty clear.

>   There still is the question of whether it needs to be in the

Putting it in the main IKEv2 document would seem to be faster: there 
is one less place for coordination.

>original IKEv1 and ISAKMP specs.  But it's not clear to me that they

Put Michael's text in Charlie's document wholesale with no further 
discussion. After we have an RFC, if we need to tweak the allocation 
policies, we can revise IKEv2 in a new RFC. Given the way the WG has 
gone so far, the chance that the current IKEv2 will have no errors is 
close to zero, so we should expect a second version anyhow.

Having the WG chairs ask at this late date for even more delay on 
IKEv2 seems unreasonable.

--Paul Hoffman, Director
--VPN Consortium

---

From: Michael Richardson <[email-masked]>
Date: Thu, 29 Jan 2004 12:43:53 -0500

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Theodore" == Theodore Ts'o <[email-masked]> writes:
    Theodore> I've been looking at RFC 2434, and it looks like there are some
    Theodore> requirements for what needs to be in the IANA consideration
    Theodore> section that doesn't quite meet with what's in
    Theodore> draft-ietf-ipsec-ikev2-iana-01.txt.  In particular, what RFC

  okay, but again, I wasn't asked to write IANA Considerations, but rather,
to extract the text into some nice, consise tables. If I misunderstood, then
fine. please tell me what you want.

    Theodore> In addition, I am wondering if we need to adjust the allocation
    Theodore> policies as currently defined in ikev2-iana-01 document.  It
    Theodore> seems strange to me that the relatively small ranges, such as
    Theodore> the IKEv2 Payload types (only 255 possible values) have
    Theodore> relatively loose policies, such as "Specification Required",

    Theodore> whereas some ranges that are much larger, such as the IKEv2
    Theodore> Integrity Algorithm Transform ID's (with 65536 possible values)
    Theodore> have "Expert Review" as the policy.

  Uh, "Expert Review" is a looser policy than "Specification Required"

  Expert Review means you email IANA, and say:

	 "please allocate me an IKEv2 integrity algorithm transform number
          for TripleRot-13"

  IANA, then forwards to "Expert", and "Expert" says,

	"Yeah, that sounds reasonable, go ahead"

or:	"Wait, TripleRot-13 is a cipher, I think that this request is
	unfounded"     

  That's all.

  Specification Required means that there has to be a document somewhere.
I thought this meant RFC series of some kind, but I've been told that for
ciphers, a publication in a peer-reviewed journal would do. That's a lot 
harder than just sending an email.

  There are some things that do not affect interoperability and the spaces are
large, so the allocations should be easy.
  One pulls back only because one wants to avoid the PPP, DHCP and radius
situation with a lot of options being used widely that started as
vendor-specific options.

  There are some things that would have profound affects on interoperability,
and so one insists that they write things down, even if the allocation space
might be big.

    Theodore> I understand that you probably just used the IANA policies from
    Theodore> the original IKEv1 and ISAKMP specs.  But it's not clear to me
    Theodore> that they are completely coherent.

  No, I thought pretty hard about it. I reviewed what was in IKEv1, and
moderated my thought by 6 years of watching people try to write extensions.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] [email-masked]      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: "Theodore Ts'o" <[email-masked]>
Date: Thu, 29 Jan 2004 13:42:24 -0500

> an assignment is excessive." That seems pretty clear.

To get an assignment, yes.  But the allocation policies for the
various registries I read as being required for to be specified in the
RFC.  These do not change, but IMHO should be documented in a
permanent location.  An Area Director may correct me, but that was my
reading of RFC 2434.

> is one less place for coordination.

True.  

> close to zero, so we should expect a second version anyhow.

Actually, we're through working group last call already, and the
changes which Charlie made in the -12 version of the I-D January 6th
reflect the second time that that we've pushed the ikev2 document to
Russ's reading queue for IETF-wide last call.

Currently the January 6th I-D states that the IANA considerations will
be in a separate document.  As part of any edits or changes that arise
either as a result of the IETF-wide last call, or from the IESG (and I
agree with you that given the nature of the review and the legnth of
the document, this is virtually a certainty), we will have an
opportunity to add Michael's document into the IKEv2's IANA
Consideration section, and replace it with its current pointer to
Michael's I-D, if that be the consensus of the working group.

However, while this is going on, we do still have an opportunity to
make changes to the allocation policies, which up until now have had
pretty much zero discussion on the mailing list.  So I raised this
question about the allocation policies not because I wanted to add
delay; indeed what we've done has been to move the ikev2 document
along the track as quickly as possible.  Instead, I'm raising this
question because I want the result to be as high-quality as possible,
while minimizing or eliminating any delay that might be introduced
into the process.  We *can* have this discussion without delaying ikev2.

That being said, at this point, let me take my working group chair hat
off, and make a formal proposal that we change the allocation policies
in Michael's document in the following way: That all registries that
require reflect 8 bit values shall require "Expert Review" and that
all registries of numbers that are 16 bits or larger shall use the
"Specification Required" as defined in RFC-2434.  The rationale for
making this change is that currently, some 8-bit registries are
"Specification Required".  This is unwise, as little as 122 or so
specifications presented to the IANA (they don't even have to be
Informational RFC's, according to RFC 2434), would be all that would
be required to exhaust the number of available IKEv2 traffic selector
types or configuration payload types.

Comments?

						- Ted

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Thu, 29 Jan 2004 11:07:14 -0800

>Michael's I-D, if that be the consensus of the working group.

...or if it is what the IESG asks for. The IESG talks with IANA on 
all these issues, so IANA might ask for it one way or another.

>types or configuration payload types.

Having all of the values have the same requirements would make 
allocation more predictable to people in the future. Doing so also 
gives more uniform results in cases where an IKEv2 extension requires 
a couple of values from different registries. Your proposal is OK, 
but a more consistent proposal is simply that all values require 
"Expert Review".

--Paul Hoffman, Director
--VPN Consortium

---

From: Michael Richardson <[email-masked]>
Date: Thu, 29 Jan 2004 16:36:52 -0500

This is a summary of allocation policies. Please disagree, and change
the subject. Maybe we need to make an issue for each one.

   IKEv2 Exchange types			    Standards Action.
   IKEv2 Payload Types			    Specification Required.
   IKEv2 Transform Types		    Specification Required.
   IKEv2 Transform Attribute Types	    Specification Required.
   IKEv2 Encryption Transform IDs	    expert review.
   IKEv2 Pseudo-random Transform IDs	    expert review.
   IKEv2 Integrity Algorithm Transform IDs  expert review. 
   IKEv2 Diffie-Hellman, ECP/EC2N           Specification Required.
   IKEv2 Extended Sequence Numbers Transform IDs    IETF Consenus.
   IKEv2 Identification Payload ID Types    Specification Required.
   IKEv2 Certificate Encodings		    Specification Required.
   IKEv2 Authentication Method		    Specification Required.
   IKEv2 Notification Payload Types	    First Come-First Served.
   IKEv2 Notification IPCOMP Transform IDs  expert review. 
   IKEv2 Security Protocol Identifiers	    Standards Action.
   IKEv2 Traffic Selector Types		    Specification Required.
   IKEv2 Configuration Payload CFG Types    Specification Required.
   IKEv2 Configuration Payload Attribute Types    Specification Required.

$Id: summary.txt,v 1.1 2004/01/29 21:36:10 mcr Exp $

---

From: Michael Richardson <[email-masked]>
Date: Thu, 29 Jan 2004 20:35:16 -0500

-----BEGIN PGP SIGNED MESSAGE-----

Motivation for these rules:

I believe that new exchange types will be entirely new protocols, or
significant extensions. If they are sufficiently different to be totally
incompatible, then they could run on their own port. If they aren't 
that incompatible, then I presume that we need to think hard about this.

Algorithms are relatively simple to standardize, and if an implementation
does not understand them, then it can just ignore them.

If one guess wrong, then an extra round trip is required. It seems that
there should be very little reason to have private definitions that are
not published somewhere.

New payloads will be significant features, so need to be described.
IKEv1's lack of a critical bit meant it was effectively Standards Action,
so this is a relaxation.

If we invent something other than authenticate, encrypt and compress,
then I think it needs to be described well.

A new value here would require an "RFC2401bis"-bis. (128bit sequence
numbers?)  

I think that new types should be explained, or it will be very hard to
interop. 

Big wide space, with minimal impact on interop.

These remind me of the problems in PPP,radius,DHCP with having vendors too
easily able to innovate (and become incompatible). Specification Required at
least requires that there be a document that exaplain things. It shouldn't be
too onerous, in my opinion. This could be watered down to "expert review".

---

From: Michael Richardson <[email-masked]>
Date: Fri, 30 Jan 2004 10:59:17 -0500

-----BEGIN PGP SIGNED MESSAGE-----

    mcr> IKEv2 Payload Types			    Specification Required.
    mcr> 
    mcr> New payloads will be significant features, so need to be described.
    mcr> IKEv1's lack of a critical bit meant it was effectively Standards
    mcr> Action, so this is a relaxation.

>>>>> "Jari" == Jari Arkko <[email-masked]> writes:
    Jari> Hmm.... I think Specification Required is quite weak. Does this mean
    Jari> that with the critical bit set to 1, a vendor (with documentation)
    Jari> can prevent interoperability with a base RFC compliant IKEv2
    Jari> implementation? 

  yes, however... one can use private use types like this ALREADY.

  Frankly, I do not find "Specification Required" to be that weak at all. 
Getting an informational RFC published is not as easy as all that.

---

From: Jari Arkko <[email-masked]>
Date: Fri, 30 Jan 2004 08:49:01 +0200

Michael,

> that incompatible, then I presume that we need to think hard about this.

Yes.

> does not understand them, then it can just ignore them.

Fine.

> there should be very little reason to have private definitions that are

Ok.

> IKEv1's lack of a critical bit meant it was effectively Standards Action,

Hmm.... I think Specification Required is quite weak. Does this mean
that with the critical bit set to 1, a vendor (with documentation) can
prevent interoperability with a base RFC compliant IKEv2 implementation?
How about IESG Approval or IETF Consensus? Or Specification Required
if critical = 0, IETF consensus otherwise?

> then I think it needs to be described well.

I think Specification Required is too weak for a 8 bit IKEv2 Transform
Type.

> A new value here would require an "RFC2401bis"-bis. (128bit sequence

Ok.

>    IKEv2 Traffic Selector Types		    Specification Required.

Ok otherwise, but it looks like a new Traffic Selector Type would have
a major impact on RFC 2401 processing, or have I misunderstood something?
If so, IETF Consensus might be more appropriate?

>    IKEv2 Notification Payload Types	    First Come-First Served.

How about Specification Required? Is there a reason why we should not
document the notifications?

> too onerous, in my opinion. This could be watered down to "expert review".

Specification Required is fine for this, I think.

--Jari

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Fri, 30 Jan 2004 11:29:33 -0800

As I said in my earlier message:

>gives more uniform results in cases where an IKEv2 extension 
>requires a couple of values from different registries. Your proposal 
>is OK, but a more consistent proposal is simply that all values 
>require "Expert Review".

Are we trying to micro-manage the future with having different 
categories for policies?

--Paul Hoffman, Director
--VPN Consortium

---

From: "Theodore Ts'o" <[email-masked]>
Date: Fri, 30 Jan 2004 17:47:29 -0500

> fine. please tell me what you want.

Sorry, I guess there had been some miscommunucations; I thought that
what we had asked you to do (and certainly what needed doing) was the
IANA considerations section.  Certainly at the moment, the ikev2
document's IANA considerations section points at your document.  

That being said, your document is actually very close to what is
needed for the IANA considerations section.  So I thought we were all
on the same page; my apologies for making that assumption.

As far as a path forward, if you're willing to edit the IANA
considerations section for IKEv2, via making changes in your I-D, and
once it is done, we can either combine it into the ikev2 document, or
we can either publish it as a separate document, whichever pleases the
working group.  Does that sound like a reasonable plan?

						- Ted

---

From: Michael Richardson <[email-masked]>
Date: Fri, 30 Jan 2004 21:44:34 -0500

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Theodore" == Theodore Ts'o <[email-masked]> writes:
    Theodore> My understanding was that an Expert represented a much higher
    Theodore> bar, because human is in the loop.  My assumption was that an
    Theodore> Expert would 

  Specification Required involves the RFC-editor, or possibly another
peer-reviewed journal. I think that this is a much higher bar.

  The only category that is mechanical would be First-Come/First-Served.

  I don't think that that IETF has a lot of experience with expert review yet.
  And, while the expert may ask to see a specification, (not necessary
though), the specification may be proprietary, require NDA, specific-national
security clearance, etc.

  So, expert review does not, in my opinion, mean that we get any
specifications to look at. It just avoids silly stuff.

    Theodore> Actually, anything permanent will qualify.  So any crackpot
    Theodore> idea in a raduate student's thesis, or a Technical Report
    Theodore> published by a lab might be enough to get a number assigned.

  I don't read 2434 as saying that it is that wide open.
  You may be correct though.
  
    Theodore> publishes a single paper that consumes half a dozen or more
    Theodore> payload id's.  Presumably that would be a case where an human
    Theodore> expert would hopefully say, hey now, wait a moment!

  True.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 30 Jan 2004 21:38:39 -0500

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "VPNC" == VPNC  <Paul> writes:

    VPNC> Are we trying to micro-manage the future with having different 
    VPNC> categories for policies?
 
  Let's divide what you saying into two statements:

  1) that we should not have different policies for different tables
     ("micro-management")

  2) that the single policy should be expert review.

  I don't have an opinion on this. If the expert is capable, then there is
no problem.

---

From: "Theodore Ts'o" <[email-masked]>
Date: Fri, 30 Jan 2004 17:35:52 -0500

> or:	"Wait, TripleRot-13 is a cipher, I think that this request is

My understanding was that an Expert represented a much higher bar,
because human is in the loop.  My assumption was that an Expert would
require a specification, and then apply human judgement about whether
or not a particular assignment was warranted.  Depending on the
expert, the standards set can be quite high.

> harder than just sending an email.

Actually, anything permanent will qualify.  So any crackpot idea in a
graduate student's thesis, or a Technical Report published by a lab
might be enough to get a number assigned.  For a space with over
32,000 available values, that hopefully won't be an issue.  But for a
registry space where there are only 122 free slots, suppose someone
publishes a single paper that consumes half a dozen or more payload
id's.  Presumably that would be a case where an human expert would
hopefully say, hey now, wait a moment!

						- Ted

---

From: Jari Arkko <[email-masked]>
Date: Sat, 31 Jan 2004 10:00:32 +0200

>   yes, however... one can use private use types like this ALREADY.

Is it necessary to keep this behaviour in IKEv2?

> Getting an informational RFC published is not as easy as all that.

I agree that Informational RFC publication is not easy. But RFC 2434
does not require an RFC, other documentation is also allowed:

       Specification Required - Values and their meaning must be
            documented in an RFC or other permanent and readily available
            reference, in sufficient detail so that interoperability
            between independent implementations is possible.

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Sat, 31 Jan 2004 10:41:38 +0200

>   2) that the single policy should be expert review.

Regarding the micro-management question, I believe the IETF generally
sets an appropriate policy for each table separately. This makes sense,
because there can be significant differencies in the implications of
allocating a value in the different tables. Small fields are more carefully
managed than 32 bit fields. Fields that have significant interoperability
implications are better managed than fields that are sent for information
only.

For instance, we look after protocol numbers more carefully than for
port numbers. RFC 3588 (Diameter) has a different policy for allocating
header bits than for attribute numbers. RFC 3427 (SIP) defines a different
policy for general header fields and so called P- (proprietary) header
fields.

Of course, this does not mean that in the IKEv2 case we must have
different policies. But I don't think we should rule it out from
the start.

As to the specific proposal of Expert Review for everything...
I think there is a big difference between Exchange Types and
Encryption Transform IDs, for instance. The former is just 8
bits, and Standards Action seems appropriate for it. Yet I
don't think we should require Standards Action for everything.

--Jari

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Sat, 31 Jan 2004 10:26:05 -0800

>   I don't have an opinion on this. If the expert is capable, then there is

The expert is assigned by the IESG. I think we can safely assume that 
if the IESG assigns a lame expert, they'll hear about it quickly 
enough.

>peer-reviewed journal. I think that this is a much higher bar.

I agree with Ted and disagree with Michael. The RFC Editor is not 
going to be an expert in IPsec, and probably not have a very 
well-attuned garbage detector for bad proposals. The expert should.

>   I don't think that that IETF has a lot of experience with expert review yet.

Fully disagree. It's working fine in many areas. (Full disclosure: 
I'm now the "expert" on charsets (!))

>though), the specification may be proprietary, require NDA, specific-national

At which point they will not get their IANA registration.

>specifications to look at. It just avoids silly stuff.

That isn't how it has worked in other parts of the IETF. For 
instance, the IESG might require that the expert have a review team, 
so all proposals are seen by many sets of eyes. (This is the case for 
charsets, which are often more intricate and obscure than IKE 
parameters.)

--Paul Hoffman, Director
--VPN Consortium

---

From: Michael Richardson <[email-masked]>
Date: Sat, 31 Jan 2004 15:28:11 -0500

-----BEGIN PGP SIGNED MESSAGE-----

    >> I don't think that that IETF has a lot of experience with expert

    VPNC> Fully disagree. It's working fine in many areas. (Full disclosure:
    VPNC> I'm now the "expert" on charsets (!))

  Okay, that's great. I'm aware of every policy out there.

    >> though), the specification may be proprietary, require NDA,
    >> specific-national security clearance, etc.

    VPNC> At which point they will not get their IANA registration.

  I thought that this was one of the *features* of Expert review.
The expert can assign values, even if the specifications are secret.

    >> specifications to look at. It just avoids silly stuff.

    VPNC> That isn't how it has worked in other parts of the IETF. For
    VPNC> instance, the IESG might require that the expert have a review
    VPNC> team, so all proposals are seen by many sets of eyes. (This is the
    VPNC> case for charsets, which are often more intricate and obscure than
    VPNC> IKE parameters.)

  Hmm. So, it sounds like expert review is now harder to pass now than
IESG Consensus. My understanding of 2434 was that it was supposed to be much
easier than that. We had originally discussed expert review in the context of
cleaning up the registries for ikev1. 

  I defer to your experience.

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Sat, 31 Jan 2004 13:40:58 -0800

>The expert can assign values, even if the specifications are secret.

Only if that's their instructions. If the IESG says "go ahead and 
give a handful to things without specification", they will; if the 
IESG says "have a public specification for everything so that IANA 
values lead to interoperability", they won't.

>IESG Consensus.

In some cases yes, in some cases no. The difference is not harder vs. 
easier, it is "make the IESG think about every one" vs. "allow the 
IESG to delegate to a human". One has to assume the IESG will 
delegate wisely.

Again, it's reasonable to ask the IESG (via our ADs) if they have a preference.

--Paul Hoffman, Director
--VPN Consortium