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

"Panwei (William)" <william.panwei@huawei.com> Mon, 05 February 2024 15:07 UTC

Return-Path: <william.panwei@huawei.com>
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 260DBC17C88A for <ipsec@ietfa.amsl.com>; Mon, 5 Feb 2024 07:07:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.903
X-Spam-Level:
X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
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 0yswuZKr7_yv for <ipsec@ietfa.amsl.com>; Mon, 5 Feb 2024 07:07:13 -0800 (PST)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16FEAC17C882 for <ipsec@ietf.org>; Mon, 5 Feb 2024 07:07:13 -0800 (PST)
Received: from mail.maildlp.com (unknown [172.18.186.231]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4TT8lw14lnz6K8tR for <ipsec@ietf.org>; Mon, 5 Feb 2024 23:03:56 +0800 (CST)
Received: from lhrpeml500004.china.huawei.com (unknown [7.191.163.9]) by mail.maildlp.com (Postfix) with ESMTPS id E48861404F9 for <ipsec@ietf.org>; Mon, 5 Feb 2024 23:07:09 +0800 (CST)
Received: from kwepemi100010.china.huawei.com (7.221.188.54) by lhrpeml500004.china.huawei.com (7.191.163.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Mon, 5 Feb 2024 15:07:08 +0000
Received: from kwepemi500010.china.huawei.com (7.221.188.191) by kwepemi100010.china.huawei.com (7.221.188.54) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Mon, 5 Feb 2024 23:07:06 +0800
Received: from kwepemi500010.china.huawei.com ([7.221.188.191]) by kwepemi500010.china.huawei.com ([7.221.188.191]) with mapi id 15.01.2507.035; Mon, 5 Feb 2024 23:07:06 +0800
From: "Panwei (William)" <william.panwei@huawei.com>
To: "ipsec@ietf.org" <ipsec@ietf.org>
Thread-Topic: What's the most reasonable way for the responder to handle the request containing unknown Key Exchange methods
Thread-Index: AdpYNcfe9ZYfZMnUS7SS4j6Mdob8ow==
Date: Mon, 05 Feb 2024 15:07:06 +0000
Message-ID: <5e48af661d63445794b649649519ea65@huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.164.106.52]
Content-Type: multipart/alternative; boundary="_000_5e48af661d63445794b649649519ea65huaweicom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/L5sEGMoisWCrs-FvY-zmP_NJu3I>
Subject: [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 15:07:17 -0000

Hi folks,

Several new Key Exchange methods were defined after RFC 7296 was published. (See https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-8)
For example, RFC 8031 introduced two new KE methods, Curve25519 (KE Method ID = 31) and Curve448 (KE Method ID = 32). There may be more new KE methods defined in the future, e.g., the PQC KEM may be introduced into IKEv2.

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.

My logic is as follows:
In section 3.3.6 Attribute Negotiation of RFC 7296, it says:
   Similarly, if the responder receives a transform that it does not
   understand, or one that contains a Transform Attribute it does not
   understand, it MUST consider this transform unacceptable; other
   transforms with the same Transform Type are processed as usual.  This
   allows new Transform Types and Transform Attributes to be defined in
   the future.
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.
Also in section 3.3.6, it says:

   Negotiating Diffie-Hellman groups presents some special challenges.

   SA offers include proposed attributes and a Diffie-Hellman public

   number (KE) in the same message.  If in the initial exchange the

   initiator offers to use one of several Diffie-Hellman groups, it

   SHOULD pick the one the responder is most likely to accept and

   include a KE corresponding to that group.  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.
This paragraph indicates that the initiator can suggest a KE method regardless of whether it is known to the responder. 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.


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.
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.

I’d like to hear more opinions from you experts.

Regards & Thanks!
Wei PAN (潘伟)