[IPsec] Genart last call review of draft-ietf-ipsecme-ikev2-auth-announce-06
Reese Enghardt via Datatracker <noreply@ietf.org> Fri, 29 March 2024 19:17 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: ipsec@ietf.org
Delivered-To: ipsec@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CFFEAC14F6AD; Fri, 29 Mar 2024 12:17:42 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Reese Enghardt via Datatracker <noreply@ietf.org>
To: gen-art@ietf.org
Cc: draft-ietf-ipsecme-ikev2-auth-announce.all@ietf.org, ipsec@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 12.9.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <171173986283.29677.15166968196717624638@ietfa.amsl.com>
Reply-To: Reese Enghardt <ietf@tenghardt.net>
Date: Fri, 29 Mar 2024 12:17:42 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/jhsvVmd8oMV9XrZvLLuzo4J3TKE>
Subject: [IPsec] Genart last call review of draft-ietf-ipsecme-ikev2-auth-announce-06
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.39
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Mar 2024 19:17:42 -0000
Reviewer: Reese Enghardt Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. Document: draft-ietf-ipsecme-ikev2-auth-announce-06 Reviewer: Reese Enghardt Review Date: 2024-03-29 IETF LC End Date: 2024-03-31 IESG Telechat date: Not scheduled for a telechat Summary: The document is clear and concise, and it is ready for publication. I have a few minor suggestion to make the document more comprehensible to non-expert readers. Major issues: None. Minor issues: Abstract: As a non-expert reader, the following phrases appear to contradict each other: "indicate the list of supported authentication methods" sounds like different algorithms, "configured with multiple different credentials to authenticate each other" sounds like different certificates but potentially using the same algorithm. If this proposal is most applicable to scenarios where IKEv2 partners use different algorithms or methods, please consider saying so explicitly in the abstract. Section 1: If there are several credentials, why not just try them one by one - is it just performance reasons (key exchange takes longer), or is there another reason? Please consider adding a sentence as additional motivation for this new mechanism. Section 3.1: "it includes a new status type notify SUPPORTED_AUTH_METHODS in the IKE_SA_INIT response message" Have a hard time parsing this sentence. Is "notify" part of the name of the new status type? Please consider rephrasing this sentence. "If the following conditions are met:" Either of the conditions or both of the conditions? "[…] then the responder may choose not to send actual list of the supported authentication methods in the IKE_SA_INIT exchange and instead ask the initiator to start the IKE_INTERMEDIATE exchange for the list to be sent in" Is this a MAY? Why is it not a MUST, as above it says "the responder […] must take care that the size of the response message wouldn't grow too much so that IP fragmentation takes place"? Why does using the IKE_INTERMEDIATE exchange fix the problem of IP fragmentation? Please consider adding a brief explanation here. Section 5: "Note, that this is not a real attack, since NULL authentication should be allowed by local security policy." Why is it not a real attack then? If NULL authentication is allowed among other methods, surely downgrading to NULL authentication is still a problem? Or should the second sentence instead say "NULL authentication should NOT be allowed by local security policy"? Nits/editorial comments: Section 1: "The problem may arise when there are several credentials of different type configured on one peer" "type" -> "types"?
- [IPsec] Genart last call review of draft-ietf-ips… Reese Enghardt via Datatracker
- Re: [IPsec] Genart last call review of draft-ietf… Valery Smyslov
- Re: [IPsec] Genart last call review of draft-ietf… Paul Wouters
- Re: [IPsec] Genart last call review of draft-ietf… Valery Smyslov
- Re: [IPsec] Genart last call review of draft-ietf… Paul Wouters
- Re: [IPsec] Genart last call review of draft-ietf… Reese Enghardt
- Re: [IPsec] [***SPAM***] Re: Genart last call rev… Valery Smyslov
- Re: [IPsec] [***SPAM***] Re: Genart last call rev… Reese Enghardt