[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-ietf-ipsec-ikev2-iana-01.txt
-----BEGIN PGP SIGNED MESSAGE-----
>>>>> "Tero" == Tero Kivinen <kivinen@iki.fi> writes:
Tero> Michael Richardson writes:
>> I have updated draft-ietf-ipsec-ikev2-iana-01.txt
>> (available at: http://www.sandelman.ca/SSW/ietf/ipsec/ikev2/ until ID
>> editor gets to it)
Tero> I think the section 4, might need little more text, it took at least
Tero> for me some time to realize that this change was for v1 registry, and
Tero> the reserved range matches the payload numbers allocated for the
Tero> IKEv2.
I agree, it could use a bit more text.
>> IKEv2 Exchange types may created by Standards Action.
Tero> Do we really need standard action here, wouldn't the specification
Tero> required be enough.
The only reason I can imagine needing new exchange types is to create
vastly different protocols. This would mean that they would certainly not be
compatible with existing deployment - I think that this needs to be
considered carefully. It would seem to be a major extension to this
specification.
>> IKEv2 Payload Types may be allocated by Specification Required.
Tero> This is propably the first resource we are running out... We already
Tero> have 48 reserved numbers, and when extensions are made they quite
Tero> often want to use their own payloads... I still think the
Tero> specification required is the correct fr this.
Good. I think that this is where most experimentation will occur, and the
critical bit provides us with pretty much everything with need to remain
interoperable.
>> IKEv2 Proposal Substructure Protocol-IDs may be allocated by Standards Action.
Tero> Why standards action, why not specification required? I do not think
Tero> we are going to have too many of those, but on the other hand some of
Tero> those extensions might not be on standard track. I would suggest
Tero> specification required for this too.
Well, if we were to add a new security protocol number, I think that that
it would get a new IP-protocol number, and I don't think we hand those out
very easily.
It would also mean a whole bunch of new on-the-wire items.
I think that this is a big deal - maybe I'm wrong though.
>> IKEv2 Encryption Transform IDs may be allocated by expert review.
>> The initial expert reviewer is REVIEW.
Tero> The RFC2434 says that "When a Designated Expert is used, documents
Tero> MUST NOT name the Designated Expert in the document itself; instead,
Tero> the name should be relayed to the appropriate IESG Area Director at
Tero> the time the document is sent to the IESG for approval."
Uhm, okay. But, this isn't IKEv2 - this is a document that is really aimed
*at* the area director. It will never get published once IANA says that they
understand it.
Maybe the amendment formulas will get incorporated into IKEv2.
>> IKEv2 Diffie-Hellman, ECP and EC2N Transform IDs may be allocated by Spec Required.
Tero> Why this is specification required instead of expert review like
Tero> crypto algorithms? In both cases some kind of specification is needed
Tero> to implement them, and I think expert review would be enough for this
Tero> too.
I think that the new groups need to be published somewhere.
There is no obvious way to do this except through the IETF.
New crypto algorithms, on the other hand, might in fact be published in
other journals, by the IEEE, ACM, or be in-house "proprietary". (Consider
compression algorithms). I think that we want to make new algorithms
relatively easy to assign numbers to. You can select the ones you like, and
leave the ones you don't like.
Whereas, if you get the MODP group wrong, then you have to start phase 1
again. So, having fewer, well known MODP groups is good for interop, while
the same does not apply to algorithms - so long as there is a MUST.
>> IKEv2 Extended Sequence Numbers Transform IDs may be allocated by
>> IETF Consenus.
Tero> ^ typo in the document too..
Thank you.
Tero> Why IETF consensus? Specification required would propably be enough.
Tero> If I understand correctly the difference is that IETF consensus
Tero> requires the specification to be RFC, and specification required
Tero> allows other documents too...
I just can't see who would need a new *Extended Sequence Number* attribute.
The two values of "YES" and "NO" are done. I guess someone might need 128 bit
sequence numbers next - I think that this would require a revision to 2402bis
(2402-bis-bis?), so I think that this is a fair statement.
>> IKEv2 Security Protocol Identifiers may be allocated by Standards Action.
Tero> Again same as with proposal substructure protocol-IDs, I think
okay, so they are merged now.
Tero> specification required would be enough. I can see that someone might
Tero> want to use IKE as a key exchange method for non-ipsec cases, where
Tero> the easiest way would be to use new protocol number for that, and if
Tero> it is not IP related protocol, then its documents might not be
Tero> standard track documents, or RFCs at all. Preventing duplicate numbers
Tero> in those cases might still be usefull, in case someone sometime define
Tero> way to transport that stuff on the internet too...
I understand. I'm open here.
You feel it should be Specifications Required.
>> IKEv2 Configuration Payload Attribute Types may be allocated by Specification Required.
Tero> Here the expert review might also be enough. Perhaps the specification
Tero> required is still better.
I thought that even First-Come-First-Served. The space is large, however, I
think that asking people to document in an informational RFC is enough to
avoid the PPP/DHCP attribute chaos.
>> At a previous time, kivinen@ssh.fi was proposed for "REVIEW", and was
>> generally acceptable to many. I do not know if Kivinen is still able to
>> perform this function.
Tero> I am available if requested. The RFC2434 says that reviewers are
Tero> appointed by the relevant Area Director of the IESG....
I think that the set of available people should be non-empty, otherwise,
expert-review is meaningless. Final decision is up to AD.
] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[
] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys
iQCVAwUBP/mzcoqHRg3pndX9AQEgswQAvsaleFi4wUKiAEuORknFtxrZAnsZb13e
EuvWZdpH1l8Ou7c5c+WUpYnu6QWtW3J7SiyM5yq5C9/kfsKuS/L+Eo0F2prC2xT2
0q83oHFn1+TAVRVpHGvaQf1Bhm0oGGX+nsEUQbSzx+DeZa24M24iIo4gUglw4AKZ
v7exSb5tN+A=
=gohv
-----END PGP SIGNATURE-----