On Mon, 28 Jun 2021, Valery Smyslov wrote:
I think document is mostly ready. Few observations:
- FWIW I think that Dan's efforts to make draft's language less speculative and
more concrete
are valid and should be reflected in the document.
I did change the wording to remove the quantifiers, eg from "a number
of vendors" to "There are vendors that".
- Is it OK that the intended status is Standards Track? Shouldn't it be BCP?
We are deprecating a few algorithms and adding an IANA column. That is
not really BCP work.
- The draft states that it updates RFC 7296, 8221, 8247. What in particular is
being updated?
I believe the recent IESG directives require a short explanation of what is
being updated
to be present in Abstract. In any case, it should be clearly indicated in the
body of the document.
Have I missed it?
It updates the IANA registries and deprecates a number of algorithms
defined. It is really updating RFC 4306 section 6 IANA Considerations,
but 4306 is obsoleted by 5996 which is obsoleted by 7296.
https://datatracker.ietf.org/doc/html/rfc4306#section-6
The 8221/8247 RFC's state non-mentioned algorithms remain in their MAY
state, and this draft updates some of those "unmentioned therefor MAY"
to DEPRECATED.
- Section3: I think that phrase "IKEv2 is a more secure protocol than IKEv1 in every
aspect." is a bit too vague.
I believe it's better to list security aspects where we believe IKEv2 is
superior:
* IKEv2 supports modern cryptographic primitives, including AEAD ciphers
* IKEv2 provides real defense against DoS (cookies, core spec) and DDoS
(puzzles, RFC 8019) attacks
* support for post-quantum crypto in IKEv2 is being developed
(draft-ietf-ipsecme-ikev2-multiple-ke)
* IKEv2 supports various authentication methods via integration with EAP (core
spec)
* an extension that allows build PAKE methods in IKEv2 exists (RFC 6467)
* did I forget something?
I'm okay either way. Originally, I didn't want to go into too much
detail, but if the WG wants to add these, we can do that.
- Section 4.3. Formally RFC 6407 is not directly concerned with IKEv1.
This is an independent protocol developed by msec WG that was based on IKEv1.
I think more accurate language should be used to make this clear. For example:
Group Domain of Interpretation (GDOI, RFC 6407) protocol based on IKEv1
defines the support for Multicast Group SAs.
I also think that reference to RFC 3740 should be remove (it doesn't even
mention IKE
in any substantial way). I'm not so sure about RFC 5374, but I'm inclining
to remove it too - it's mostly concerned with MCAS architecture and doesn't
define any concrete IKEv1 changes to support it. So, leave only RFC 6407.
I'm fine with this change. Queued up for next version.
- Section 5 lists deprecated algorithms. In my reading this list
is inconsistent with Section 7 (IANA Considerations) which lists
many more deprecated algorithms... So, I'm a bit puzzled
how to read this section.
There was one error. AUTH_HMAC_SHA1_160 should be added to 4.3.
The other "additional" entries are those that have been deprecated
already by RFC 8247, but are listed here so that IANA will add the
deprecated keyword in the new column.
- The draft currently has all its references as Normative.
I have no problems with this (except that RFC 3740 is Informational,
so should not be referenced as Normative in Standards Track and BCP documents,
but I suggested to remove it anyway). My concern is that
referencing active drafts as Normative will lead to slow down
publication of this document until those drafts are published.
I don't think it's a major problem (we will have an incentive
to work harder on these drafts :-)), just should be noted.
You are right, they should be changed to Informative.
I'll wait another day or so for further feedback, then push another
update.
Thanks,
Paul
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
