Re: [IPsec] What's the most reasonable way for the responder to handle the request containing unknown Key Exchange methods

Paul Wouters <paul@nohats.ca> Mon, 05 February 2024 19:01 UTC

Return-Path: <paul@nohats.ca>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A71E4C14F5ED for <ipsec@ietfa.amsl.com>; Mon, 5 Feb 2024 11:01:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.405
X-Spam-Level:
X-Spam-Status: No, score=-4.405 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TtrbG1T_RwFA for <ipsec@ietfa.amsl.com>; Mon, 5 Feb 2024 11:01:15 -0800 (PST)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 725B9C14F5FD for <ipsec@ietf.org>; Mon, 5 Feb 2024 11:01:15 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4TTG1g6MP6zCyh; Mon, 5 Feb 2024 20:01:11 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1707159671; bh=A12sdupAQl90DV66AUZZOtKBzNkea9OuwW5PFuskp2c=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=R6Fk4nmpQSc4Vqyk2rc0Rh0eldkBJMXC7o9GjN2uRp9yDf6pa3A7xds2oYk/j4Qg0 bDqfMdeGrmvfk7S22mW7BWsWFoOFNaPiwJcJQl2MwS7Fi/Gk3ZM0UZjL9sOI9llRUp yrVQBYU7sOqxlkwpuHY2HWd1VCRpydD6E8MzF8e8=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id UxTykLO2YAuO; Mon, 5 Feb 2024 20:01:10 +0100 (CET)
Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 5 Feb 2024 20:01:10 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 7F49E11151BD; Mon, 5 Feb 2024 14:01:09 -0500 (EST)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 7C92E11151BC; Mon, 5 Feb 2024 14:01:09 -0500 (EST)
Date: Mon, 05 Feb 2024 14:01:09 -0500
From: Paul Wouters <paul@nohats.ca>
To: "Panwei (William)" <william.panwei=40huawei.com@dmarc.ietf.org>
cc: "ipsec@ietf.org" <ipsec@ietf.org>
In-Reply-To: <5e48af661d63445794b649649519ea65@huawei.com>
Message-ID: <9d92f51b-0d9f-e43d-3392-bf9887befa3e@nohats.ca>
References: <5e48af661d63445794b649649519ea65@huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-7"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/9eiz_zqrmtcuVH75fWV9ixvuEgI>
Subject: Re: [IPsec] What's the most reasonable way for the responder to handle the request containing unknown Key Exchange methods
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
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: Mon, 05 Feb 2024 19:01:19 -0000

On Mon, 5 Feb 2024, Panwei (William) wrote:

> Regarding how the responder handles the request containing the new Key Exchange methods (old name was DH
> Group) that it doesn’t understand, I’ve had a discussion with someone, but we failed to agree with each other
> due to different interpretations of RFC 7296. I’d like to hear more opinions from you experts.
> 
> The handling I suggest is as follows:
> 
>     1) if all KE methods proposed by the initiator are unknown to the responder, i.e., no KE method is
> acceptable, then the responder replies NO_PROPOSAL_CHOSEN, no matter what KE method is used in the KE payload.
> 
>     2) if at least one acceptable KE method is included in the initiator’s proposals, the responder can select
> one acceptable KE method, ignore the unknown KE methods, and perform the next step of KE Payload processing.
> 
>        2.1) if the KE method used in the KE payload happens to be the same as this selected KE method, then
> the responder normally replies with this selected KE method and the corresponding KE payload.
> 
>        2.2) if the KE method used in the KE payload is different from this selected KE method, then the
> responder replies INVALID_KE_PAYLOAD with this selected KE method, regardless of whether the KE method used in
> the KE payload is known or unknown to the responder.

that is correct. Note that the INVALID_KE_PAYLOAD can also contain the
KE method(s) the responder is willing to use.

> This paragraph indicates that the responder should ignore the unknown KE methods in the SA payload because the
> new KE methods can be considered as new Transform Attributes.

Yes, it should ignore unknown KEs. This allows newer software/versions
to attempt newer KEs without breaking with older implementations that
do not support the newer KEs.

>    If the responder selects a
> 
>    proposal using a different Diffie-Hellman group (other than NONE),
> 
>    the responder will indicate the correct group in the response and the
> 
>    initiator SHOULD pick an element of that group for its KE value when
> 
>    retrying the first message.

I guess that SHOULD is a little odd. It really means "it should pick one
from the responder list, that falls within its own local policy as valid
to use, otherwise it must terminate the connection".

> This paragraph indicates that the initiator can suggest a KE method regardless of whether it is known to the
> responder.

IKE assumes both peers do not know each others capabilities before the
negotiation starts.

> The latter sentence indicates that the responder can continue the negotiation when the KE method in
> the KE payload is unknown and just needs to reply INVALID_KE_PAYLOAD with the correct KE method.

No, it cannot "continue". INVALID_KE_PAYLOAD is an errror. If this is
sent in the IKE_SA_INIT reply, the responder isn't even expected to keep
any state. The initiator has to "start from scratch" using a different
KE method. The responder responds "from scratch" to that message.

> However, others suggest that the responder should terminate the IKE exchange without reply, when the KE method
> used in the KE payload is unknown to the responder, even if there are other acceptable KE methods proposed in
> the SA payload.

One must NEVER terminate without sending a reply. Doing so only causes
the initiator to retransmit its packet, thinking the packet was dropped.
It will only make things worse. Always reply. But in the case of
INVALID_KE_PAYLOAD, the responder can get away with not keeping (or even
creating) state.

> Because they feel the unknown KE method in the KE payload means that the whole packet is an invalid packet,
> and discarding this packet is the thing to do.

That is wrong :)

Paul