[IPsec] Role of the IANA expert reviewer

[Paul Hoffman <[e-mail]>]

On Aug 1, 2011, at 7:42 AM, Tero Kivinen wrote:

> As we have seen from the ipsec list the community does not seem to
> care too much, but I myself as a member of the community and also the
> person responsible for the IANA registries do care.

You are *not* responsible for the IANA registries. RFC 5226 says:

   It should be noted that a key motivation for having designated
   experts is for the IETF to provide IANA with a subject matter expert
   to whom the evaluation process can be delegated.  IANA forwards
   requests for an assignment to the expert for evaluation, and the
   expert (after performing the evaluation) informs IANA as to whether
   or not to make the assignment or registration.

. . .

   Designated experts are expected to be able to defend their decisions
   to the IETF community, and the evaluation process is not intended to
   be secretive or bestow unquestioned power on the expert.  Experts are
   expected to apply applicable documented review or vetting procedures,
   or in the absence of documented criteria, follow generally accepted
   norms, e.g., those in Section 3.3.

I do not believe that you can defend a decision to reject registrations based on what is in RFC 4306. If you disagree, please show which text you are referring to.

> I have stated my reasons why I consider allocating multiple payload
> numbers etc for exactly same thing a bad thing.

The three proposals do not do "exactly the same thing": they each have different cryptographic and administrative properties. This has been widely discussed in the WG.

> As it seems that IKEv2 might be used with other things than IPsec too
> in the future (KARP, 802.15.4, 802.11ai etc) I do see challenges in
> the IKEv2 IANA registries.
> 
> Even if those use cases are not IPsec they most likely will reuse most
> of the registries from the IPsec. We could overlap their numbers with
> each other, but on the other hand that can cause confusion, so it
> might be better to make sure they do not have overlapping numbers,
> i.e. use of unique numbers for different things and mark those as
> reserved in the registries which do not use them.
> 
> This is bit what IKEv1 and IKEv2 did, for example we are not using
> payload numbers 1-32 as they are reserved in IKEv2 registry as IKEv1
> used them. Same way our exchange numbers 0-33 are reserved etc.
> 
> I am not sure whether we are doing that in the future or not. I want
> to think more about this and see the actual protocols before deciding.

This should be a WG/IETF decision, not that of a single person.

> But on the other hand I want to keep our options open, which means I
> do not want to fill our registries with multiple registrations for the
> exactly same thing.

See above.

> Can you explain me what problems will it cause if the
> draft-kuegler-ipsecme-pace-ikev2 is changed so it uses the
> draft-kivinen-ipsecme-secure-password-framework framework just like
> other secure password method drafts have already done?


> In my understanding there will be 2 extra bytes in the IKE_SA_INIT
> notification phase to indicate the PACE inside
> N(SECURE_PASSWORD_METHODS) and there will be one extra byte (or two
> depending how you do it) in the ENONCE and PKEi/PKEr payloads.
> 
> So in total the technical differences will be 7 extra bytes. Is there
> anything else?

Regardless of what the authors of this document do, that question is not relevant to whether or not you, as the designated expert, give them a codepoint.

--Paul Hoffman