[IPsec] AD review of draft-ietf-ipsecme-ikev1-algo-to-historic-06

[Roman Danyliw <[e-mail]>]

Hi!

I performed an AD review of draft-ietf-ipsecme-ikev1-algo-to-historic-06.  Thanks for this work to formally move the community to IKEv2.

Based on the content of this document, I am assuming the WG intent is to follow option #3 of https://www.ietf.org/about/groups/iesg/statements/designating-rfcs-historic-2014-07-20/.  Please correct me if I have it wrong.  To repeat the salient parts of the process here, when this document goes to IETF LC, there will be a companion "status change document" which also will be sent to IETF LC.  That status change document will move RFC207/2408/2409 to historic status.  The IESG will need to ballot on both.

Below is my feedback.  Some of the editorial changes are to support the process described above.

** Abstract.  As this document is formally updating other documents, please state that in this section.  From idnits:

  -- The draft header indicates that this document updates RFC8247, but the
     abstract doesn't seem to mention this, which it should.

  -- The draft header indicates that this document updates RFC8221, but the
     abstract doesn't seem to mention this, which it should.

** Abstract.  To sync the language up with the status change document, please:

OLD
Internet Key Exchange version 1 (IKEv1) is deprecated.  

NEW
This document formally deprecates Internet Key Exchange version 1 (IKEv1).  Accordingly, RFC2407, RFC2408 and RFC2409 which specify IKEv1 are moved to Historic status.

** The document 

** Section 1.  As above.
OLD
IKEv1 has been moved to Historic status

NEW
This document formally deprecates Internet Key Exchange version 1 (IKEv1).  Accordingly, RFC2407, RFC2408 and RFC2409 which specify IKEv1 is moved to Historic status.

** Section 1.
   Algorithm implementation requirements and usage guidelines for IKEv2
   [RFC8247] and ESP/AH [RFC8221] gives guidance to implementors but
   limits that guidance to avoid broken or weak algorithms.  It does not
   deprecate algorithms that have aged and are not in use, but leave
   these algorithms in a state of "MAY be used".

I'm not following the text saying that "algorithms [are left] in a state of 'MAY be used'".  For example, the following Type 3 transforms are deprecated in Section 7 of this document: AUTH_HMAC_MD5_96, AUTH_DES_MAC and AUTH_KPDK_MD5.  However, Section 2.3 of RFC8247 seems very clear that AUTH_HMAC_MD5_96, AUTH_DES_MAC and AUTH_KPDK_MD5 are already "MUST NOT".  Where is the "MAY be used" flexibility coming from?

              +------------------------+----------+---------+
              | Name                   | Status   | Comment |
              +------------------------+----------+---------+
              | AUTH_HMAC_SHA2_256_128 | MUST     |         |
              | AUTH_HMAC_SHA2_512_256 | SHOULD   |         |
              | AUTH_HMAC_SHA1_96      | MUST-    |         |
              | AUTH_AES_XCBC_96       | SHOULD   | (IoT)   |
              | AUTH_HMAC_MD5_96       | MUST NOT |         |
              | AUTH_DES_MAC           | MUST NOT |         |
              | AUTH_KPDK_MD5          | MUST NOT |         |

** Section 1.  Explicitly state the update being made to RFC8247 and RFC8221.

OLD 
This document deprecates those algorithms that are no longer advised ...

NEW

This document deprecates those algorithms from RFC8247 and RFC8221 that are no longer advised ...

** Section 3.

   A number of IKEv1 systems have reached their End of Life

Is there a way to quantify that or support that claim?

** Section 3.  Please provide a reference for CVE-2016-5361.

** Section 3.

   IKEv1 configurations SHOULD NOT be directly
   translated to IKEv2 configurations without updating the cryptographic
   algorithms used

It seems odd to provide normative behavior for the technology that just got deprecated.  Consider rephrasing it to direct IKEv2 behavior.  Perhaps, "IKEv2 implementations SHOULD NOT directly import IKEv1 configurations without updating the cryptographic algorithms used."

** Section 5.  

   *  Encryption Algorithms: RC5, IDEA, CAST, Blowfish, and the
      unspecified 3IDEA, ENCR_DES_IV64 and ENCR_DES_IV32

   *  PRF Algorithms: the unspecified PRF_HMAC_TIGER

Is it "unspecified" or "unstandardized" or "registered"?

** Section 7.
   All entries not mentioned here should receive no value in the new
   Status field.

Did the WG discuss a non-empty value?

Thanks,
Roman