On Wed, 5 May 2021, Dan Harkins wrote:
- the first two bullet points in section 3 are basically speculation,
"a number of..." is meaningless. These bullet points are ultimately
not even necessary to make the case being made. Delete these, please.
I have heard from vendors, so I don't think this is speculation.
I think it is important to get these points across. Especially the
second bullet point, as people might think IKEv1 is still being
supported because their devices are still seeing regular updates,
without realizing that the IKEv1 code on those devices in fact will
not receive any further updates.
- fourth bullet in section 3 should be rewritten. The "Often, IKEv1..."
sentence should be removed but the remainder is a decent point. IKEv1
was standardized before modern ciphers were designed, to get support
for modern, accepted ciphers use IKEv2.
How about:
OLD:
* IKEv1 systems most likely do not support modern cryptographic
algorithms. AES-GCM is only defined for ESP and not IKE, and
often not implemented for ESP. And CHACHA20_POLY1305 is not
defined for IKEv1. Often, IKEv1 is configured with the very weak
Diffie-Hellman Groups 2 and 5 and some implementatipons do not
support any stronger alternatives.
NEW:
* The IKEv1 protocol pre-dates modern cryptographic algorithms. While
a limited number of more modern cryptographic algorithms were added
to the IKEv1 specification, interoperability concerns means that the
defacto
algorithms deployed for IKEv1, AES-CBC, SHA1, DH2 and DH5, are no longer
recommended and a migration to IKEv2 is the best method to deploy
modern cryptographic algorithms with the IKE and IPsec protocols.
Or if you have an altnerative proposal, I'm happy to hear it.
- there is another IKEv1 feature not available in IKEv2: a deniable
authentication method. IKEv1 had a very cool deniable exchange
involving encrypted nonces. IKEv2 decided to not support that for
whatever reason. Lack of support for a cool and usefu authentication
method doesn't really make the case to send IKEv1 to historic
Can you clarify this a bit further for me? Is this deniable
authentication method part of all IKEv1 auth methods? Or is this a
specific feature that needed to be specifically enabled?
That said, if the WG deemed this feature no longer required when
specifying IKEv2, then I do not think we need to mention this here when
we are talking about motivations for people to move from IKEv1 to IKEv2.
If there is a good reason and people are prevented from upgrading to
IKEv2 because of this, I would be expecting an IKEv2 draft to be
developed to address this shortcoming. But it seems to me (I wasn't here
when these decisions were made) that the WG did not think this issue was
a concern ?
then, oh well. As an aside, I suggested a way to add an exchange
such an exchange using HPKE [1]. Not that I'm saying this needs to
be added to IKEv2, but if you're gonna talk about IKEv1 features
missing in IKEv2 you should be complete.
I was mostly listing the features in IKEv1 that were missing in IKEv2
that actually were motivations for certain people to not upgrade to
IKEv2. It is surely not meant as a list of IKEv1 vs IKEv2 features.
Other than that, good work.
Thanks.
Paul
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
