Paul Hoffman writes: > > Ok, perhaps using word of being responsible for the IANA registries is > > wrong as IANA will be responsible for the actual registries, but it is > > my understanding that designed expert is support to help IANA to keep > > the registries usable. > > Absolutely. And, you have done a fine job of that so far (certainly > better than I could have done). In my mind, keeping serious > proposals for IKEv2 functionality out of the registry does not keep > it useful.
I have not tried to keep any proposal out from the IKEv2, I wanted the proposals which do about same thing, and which already have separate mechanism to negotiate which of them is used, to use same numbers for the payloads / exchange / authentication types in the IKE_AUTH phase. The only differences in the for example for the exchange type would be to use number 35 as exchange type instead of allocating new number. Same thing with payload number, i.e all three proposals would be using same payload number for their own payloads. All three of the protocols can still be used, I just wanted them to use same numbers for same things as this is how IKEv2 does for those registries. We have IKE_AUTH, not IKE_AUTH_PSK_CERT, IKE_AUTH_EAP_FIRST, IKE_AUTH_EAP_INTERMEDIATE, IKE_AUTH_EAP_LAST. Creating two new exchanges IKE_PACE, IKE_PACE_AUTH is not how IKEv2 does things normally, especially as the IKE_PACE combined with IKE_PACE_AUTH looks very much like IKE_AUTH done with EAP, except that it uses secure password method specific payloads instead of EAP payloads. Also as I said in EAP we do have one EAP specific payload we use to transmit all EAP specific data inside the IKE_AUTH. We do not have multiple EAP specific payloads transmitting differenet EAP payloads in IKEv2. We could have EAP_REQUEST, EAP_RESPONSE, EAP_SUCCESS, EAP_FAILURE payloads in IKEv2 instead of using just one EAP payload. Especially as the IKEv2 code needs to check into the code inside to see whether it is EAP_SUCCESS or EAP_FAILURE. IKEv2 way of allocating IANA numbers have been so that it tries to save numbers especially on the 8 bit registries. It is very different when you compare what we have done for example in the Encryption Algorithm Transform IDs registry. That registry is 16-bit registry with 1022 numbers for IANA to allocate, and there we have for example 9 numbers allocated for different AES variants (CBC, CTR, CCM_8, CCM_12, CCM_16, GCM_8, GCM_12, GCM_16, GMAC). > > If I have to be able to defend all my decisions to reject things based > > on the RFC4306 only, there is no way I can reject anything as the only > > text in there is text which says: > > > > ---------------------------------------------------------------------- > > Note: When creating a new Transform Type, a new registry for it must > > be created. > > > > Changes and additions to any of those registries are by expert > > review. > > ---------------------------------------------------------------------- > > You can reject whatever you want, subject to IETF review. This > thread is that review, ahead of time. I am disagreeing with your > apparent decision to reject these ahead of time. That would be fine, if you would defend your disagreement with technical reasons, but you seem to be just rejecting about the fact that any numbers could be rejected even with technical reasons. I have given out my reasons why I want all of those methods to use same number space (i.e. want to keep the registry clean, do not want to allocate duplicate numbers for same things (not same protocols, but for example same kind of payloads), want to keep allocations in the same way other allocations in IKEv2 has been done etc). I have listed some of those in my previous emails, altough it might be that I have not formulated all of them very throughly and those reasons might have been scattered in different emails, and I have mostly concentrated in the most technical aspect, i.e. the small number space of payload numbers, and keeping the more political ones (like following the similar way of doing allocations than what is done in the IKEv2 RFC) in the background. > > Note that I did not claim that three proposals are "exactly the same > > thing", I said that the payload types they allocate are "for the > > excatly same thing", i.e. transfering secure password protocol > > specific data between the peers. > > And SHA-3 will do "exactly the same thing" as SHA-2: will you not > allocate code points for it? :-) SHA-3 will get code point, as will any other reasonable cipher/hash. Actually SHA-3 will most likely get 3 + 3 code points as this is how things are allocated in IKEv2. I.e. it will get 3 code points in the PRF registry for 256, 384 and 512 bit sizes and it will also get 3 code points in the Integrity Algorithm Transform ID registry. Those registries are 16-bit registries, and they have 1022 numbers for IANA allocation and 64511 for private use. I do not see any reason to limit allocations for SHA-3 in that registry as that is not small registry, and the way we normally do allocations there is to encode the size to that number. I would most likely be against if someone would like to create new Transform Attribute Type for HASH Length attribute (similar than what we now have for Key Length arttribute for encryption cipher), and then said that we only allocate one SHA-3 attribute and mandate it to be used with that new HASH Length attribute type with values indicating whether it is 256, 384 or 512 bits. My reason would be that it is so much different than current IKEv2 allocations for hashes. On the other hand if SHA-3 family will support any random bit lengths and someone wants to support SHA-3-1, SHA-3-2, SHA-3-3, ... SHA-3-1023, SHA-3-1024, then I would exactly propose using the method above instead of allocating 1024 numbers to the SHA-3. And in both cases I would try to convince the people doing that work way before it comes to IANA allocation phase, and I would again be telling that my reasons might still be same if it comes to IANA allocation phase (as I did in this time). > > I.e. the current RFC4306 use of payloads do use subtypes a lot and > > those subtypes change the payload format inside the main payload. > > Sure, but that is because we knew which values we wanted when we > wrote IKEv2. Today, we are talking about extensions. We are talking about extensions which know EXACTLY which subpayloads they want to support. For two of the drafts there is exactly one type of payload they send, for one there is two different payloads in both directions. And everything what goes inside the payload is going to be method specific anyway, so if someone make yet another secure password method then they format their payload as they like. > Thank you for giving the fuller explanation of your thinking. > However, I still don't think that justifies rejecting ahead of time > the idea that each gets its own IANA allocation: it just argues more > effectively for your current draft on how to negotiate them. I think > those two are completely separate discussions, which is why I > changed the subject on this thread. If we do not negotiate the methods at all (as some of them didn't) then there would be no other option than to allocate each of them some separate numbers, as that would be only way to distinguish them. So to have *a* way to know which method is used, is requirement for the shared allocations. Note, that method does not need to be same for all drafts, there just needs to be some way to know which method is used. All current methods already have a way to know which method is used, altought the way is not same. > >>> 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. > > > > How on earth can you interpret statement saying "I am not sure whether > > *we* are doing that in the future or not." to indicate that it will be > > a single persons decision? > > The "I" part. I cannot speak for the whole working group / IETF, which is why I said that I am not sure what we (meaning the WG / IETF) are doing in future. > The expert reviewers for some IANA registries seem to think that > they are the ones who do this consideration, and your use of "I" > instead of "we" concerned me. (This could be an English/Finnish > thing...) The "I" part refered to my own thinking, the "we" part refered to the community who decides. I do not think collective thoughts are that common yet (at least here in Finland), so I usually think I will be using I when I refer to my own thoughts... Saying "We are not sure whether we are doing that" would indicate majestic plural for my ears, which might have been even worse... -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
