Re: [IPsec] Role of the IANA expert reviewer

[Sean Turner <[e-mail]>]

On 8/1/11 12:11 PM, Paul Hoffman wrote:
> 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.

WRT who is responsible ...

Technically, IANA is responsible for maintaining the registries in 
accordance with the registration rules documented in the RFC that 
creates/defines the registry.

The IANA experts (who are appointed by the IESG) are responsible for 
reviewing requests for additions and modifications in the registries 
that they are designated for.

The IETF/IESG is ultimately responsible for the registry as (most of 
them) are a product of the IETF process.

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

My understanding is that Tero is stating early that he would deny the 
requests based scarcity of code points, which is allowed per RFC 5226:

   Possible reasons to deny a request include:

       - scarcity of code points, where the finite remaining code points
         should be prudently managed, or when a request for a large
         number of code points is made, when a single code point is the
         norm.

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

But, they're for the same "thing": extension(s) to IKEv2 to allow
mutual authentication based on "weak" (low-entropy) shared
secrets.

spt

>> 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
>
> _______________________________________________
> IPsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipsec
>