Dan Harkins writes: > > When draft-lepinski-dh-groups was discussed in the ipsec-list we were > > most concerned about the format of the KE payloads and so on, and I do > > not think anybody actually even reacted to the fact that it updates > > IKEv1 registry too. At that point it was also 2 years since the IKEv1 > > was obsoleted, now it is 7 years, so I do think there is a difference. > > There is no time limit that I'm aware of that suddenly makes an > acceptable process suddenly become unacceptable.
There is no time limit that suddenly causes that, but the longer the protocol has been obsoleted, the more questionable there is to make additions to it. I do think there is difference whether the addition is proposed 1 day after the new version is out or whether it is done 20 years later. What the exact number of years will be is of course personal opionion, and at least for me it should be less than 7 years, meaning we are already past it... It seems you disagree on me on that, so it is better just agree that we disagree on this issue. > >> And RFC 5931 (EAP-pwd) uses that registry and it > >> got approved for publication long after RFC 2409 was obsoleted, > >> again without any hullabaloo. > > > > Never knew that RFC 5931 is using that same registry. This was not > > pointed out in the IPsec list, thus I think most peoples just didn't > > realize the issue. > > I brought it up at the SAAG meeting back in Vancouver. You were > there. Saag meeting? I assume you mean secdir lunch. I did miss some of the discussion in the secdir lunch as sometimes it is hard to hear people there (no microphones, people talking over each other), and especially RFC numbers do tend to go past me, as I people do say them very quickly, and I need to parse them before I can know which number it is and even after that I usually do not have any idea what protocol that is. Meaning: I did miss that statement there even when I was there. That happens. This means it is good that you pointed it up here too. > I will admit that you are repeatedly making that assertion but it's just > some sort of argumentum ad infinitum/absurdum statement. There is > no reasoning behind your assertion. Just "we must stop!" and "we > cannot continue forever!" We did obsolete the IKEv1 protocol. So I assume that was supposed to mean something. If we continue to make additions to it, why did we obsolete it? I think there is good thing to have some kind of grace period after the protocol is obsoleted, and replaced with new, during which there is still some work that can be done (or most likely finished) for the old protocol, before we move all work to new protocol. You seem to feel that the fact that the protocol is obsoleted does not mean anything, and that we should continue work for that forever. You ar just making that sort of arguments over and over again, without providing any reasoning behind that. If you want reasons I can give you some: IKEv1 is BAD protocol. IKEv2 is much better protocol. IKEv2 include standardized ways of doing lots of things that are done in undocumented (incompatible) vendor specific extensions in the IKEv1. IKEv1 do have known security vulnerabilities especially for those vendor specific extensions, as vendor ID payloads and notifications are not authenticated at all during the initial main mode / aggressive mode exchange. IKEv1 vendor specific configuration payload and xauth exchanges do have known security vulnerailities by using group shared keys (there are some vendor specific extensions which do not have those problems (hybrid-mode)). Then there is lots of smaller things in the implementations, for example retransmission logic, dead peer detection, crash recovery etc. I do think there was good reasons why IKEv1 was obsoleted. I do know that some of those could have been fixed quite easily by making additions to IKEv1, but that was not allowed because of the IETF policy reasons, thus we had fix it by making the IKEv2 and fix all known issues there. > You essentially admit that there is no process reason to not just > update the registry and there's really no prohibition on other protocols > referring to the registry that was created by another protocol. You > may not like it, but that is not a legitimate reason. As far as I know there is no reason for random protocol Y using registry from protocol X. That does not mean that protocol Y has any saying whether anything is added to the registry X. Depending on the IANA allocation policies different parties decide whether that is allowed or not. In this case it is up to the IESG to decide as the registry is RFC required. At least this is my understanding of the issue, but I am not IETF policy person, so I might be wrong... Security area director asked us on this mailing list to comment about the issue, so thats why I am commenting. I personally do think it would be much better to create separate registry for these other generic group description to identifier mappings for these other protocols, and leave them out from IPsec registry. That would fix the problem, that we do not need to modify IKEv1 registry, and those other protocols can add their numbers to the registries at will. What do you have against that solution? > You snipped out the portion of my email where I noted that I did > not foresee any calamity that would befall us all if the IKEv1 registry > is merely updated in the same way it was by RFC 5114-- just add the > code points without any back pointers or front pointers or ridiculous > notes. So let me ask you directly: > > What calamity will befall us all if the IKEv1 registry is just updated > in exactly the same way that RFC 5114 updated the registry? I see some of our customers asking when are we going to implement them for IKEv1. We do IPsec toolkit. Some of our customers go through RFCs and IANA registries and make tick marks for every single option there is, and want to have support for it, regardless whether it makes sense or not. In first I would most likely be able to say that those numbers are not meant to be used for IKEv1, but if there is no note or so in the registry, they would ask why not? Later if some of the other vendors after similar perssurce happens to implement them, then our customers would be more and more asking why we do not implement them. As it just going to be tick mark in their sheets they do not care that we already implement them in IKEv2 and that would mean we would have again added new feature to already obsoleted protocol, which should have died several years ago. > > I could not find any other protocol than SAE, can you give me > > references to which other IEEE protocols use that registry directly > > (i.e. not through some RFC). > > There is a novel use of an unauthenticated Diffie-Hellman by > the audio/visual streaming protocol (added by TGaa). Good to know, need to check that one too. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
