Re: [IPsec] GDOI and G-IKEv2 payloads

Valery Smyslov <smyslov.ietf@gmail.com> Mon, 05 February 2024 07:52 UTC

Return-Path: <smyslov.ietf@gmail.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 B2186C14F696 for <ipsec@ietfa.amsl.com>; Sun, 4 Feb 2024 23:52:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.105
X-Spam-Level:
X-Spam-Status: No, score=-7.105 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 (2048-bit key) header.d=gmail.com
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 nhh5F5T-OntM for <ipsec@ietfa.amsl.com>; Sun, 4 Feb 2024 23:52:03 -0800 (PST)
Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EBF4C14F68F for <ipsec@ietf.org>; Sun, 4 Feb 2024 23:52:03 -0800 (PST)
Received: by mail-wm1-x32e.google.com with SMTP id 5b1f17b1804b1-40fc6578423so24179575e9.0 for <ipsec@ietf.org>; Sun, 04 Feb 2024 23:52:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1707119521; x=1707724321; darn=ietf.org; h=thread-index:content-language:mime-version:message-id:date:subject :in-reply-to:references:to:from:from:to:cc:subject:date:message-id :reply-to; bh=J50L5z7ocuOiTXLFl1/Y4+H4pP31RdSNVkwFD+riRXA=; b=D899oJQj7ywfcf6uRSVj7PjF+sm7gbrwmHtrxF0nPsV1qJ2oFz34wLJDDK70MxYm7Q ECectdqKWmeyJk87V+6o6+3pWSbEGawYUgWXHRzvnoHWIAe5cc+RTTP2SVjtqUMgn6TW 0R/ko34qex1fKT0lvEx31vSSQjZdJKyuT0XS5s0IDb59bylssC59cl1+UlOPOAaDMYA1 d6Vlobl5jxkYDK0Lh/I4zidoDVPAHqoJe9TgRNGp07hpqLgTIoGDClIKWyfvPeJqNhel yeJXJAruJsacWnWc+4RcvlRbdsVwOyCI/5eFu4cFFiXFTh6DcFLa0I+QMRo9ofCv26sn Topg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707119521; x=1707724321; h=thread-index:content-language:mime-version:message-id:date:subject :in-reply-to:references:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=J50L5z7ocuOiTXLFl1/Y4+H4pP31RdSNVkwFD+riRXA=; b=wV+m0qsWhLNEYqOBK8sSrUuGTlnMuMj4aVz8j+xVi9hJKwic4B9Up6oLVp7JJh3XlV qM6H5PtJBcJLC21m0dFw03GY8016Z1+F0dipp1C5Oqhd6VKz3/9TEIp4i5E5V4gedpR7 2mB0ZbbpdWb0kJgm6ySO6XruvfxgNtSjls/RJJ0pGtlTETxgrtgeGLvK6+uDtrsQ8PYs LOaWZcxm0cAZ/HQggfF879Ukh3LuJo7qP9+AIi76V/jlGelhdFq//6RlLsj3JjY3YRzi MzMtzNSbRK4YKWjY2BWwKXI0NBKlY7EG+Lf7o1rz8AurTnnQ+5MGwoEsMz+0teyw5sAK 0r7A==
X-Gm-Message-State: AOJu0YzoAoOO+vpmg9hrhjVLhj9pe7xbFATrHOFMbnpXfRr1FbQU4/0B MEmg+Svk2oL44eh5dVrRCRi8kPcg40FZPyDf6t1D9fF+ejERMWAFPhilv4jKfRo=
X-Google-Smtp-Source: AGHT+IGdNlp7bvdjm4jQVhGaCg6OIsuBzEJYKQZ9a0V2YhepM3iL8oH6yBFWx6IATGY3aPA/dWcimw==
X-Received: by 2002:a05:600c:5007:b0:40f:d34d:d4ea with SMTP id n7-20020a05600c500700b0040fd34dd4eamr4505160wmr.31.1707119521085; Sun, 04 Feb 2024 23:52:01 -0800 (PST)
X-Forwarded-Encrypted: i=0; AJvYcCV8uyYnDsllKYeM/GWTR6Lhd7+q7JbVzAbnw2EiOtznEFrmIm1uHOVznxouK46uiFbiip7SAowGZBiI3NHP1g==
Received: from BuildPC ([93.188.44.204]) by smtp.gmail.com with ESMTPSA id p13-20020a05600c1d8d00b0040fb30f17e8sm7861137wms.38.2024.02.04.23.52.00 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 04 Feb 2024 23:52:00 -0800 (PST)
From: Valery Smyslov <smyslov.ietf@gmail.com>
To: "'Fries, Steffen'" <steffen.fries=40siemens.com@dmarc.ietf.org>, ipsec@ietf.org
References: <DB9PR10MB6354CF46CDE84485FB1510BCF3472@DB9PR10MB6354.EURPRD10.PROD.OUTLOOK.COM>
In-Reply-To: <DB9PR10MB6354CF46CDE84485FB1510BCF3472@DB9PR10MB6354.EURPRD10.PROD.OUTLOOK.COM>
Date: Mon, 05 Feb 2024 10:51:59 +0300
Message-ID: <029001da5808$33763b20$9a62b160$@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/related; boundary="----=_NextPart_000_0291_01DA5821.58C37320"
X-Mailer: Microsoft Outlook 16.0
Content-Language: ru
Thread-Index: AQJ9gH558reIYOrUNdeISaKBvcFO06+1CWhw
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/9nF23Cm096PDqVkC62sWt1kKg6Q>
Subject: Re: [IPsec] GDOI and G-IKEv2 payloads
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 07:52:07 -0000

Hi, Steffen,

 

in general, G-IKEv2 is not backward compatible with GDOI (likewise IKEv2 is
not backward compatible with IKEv1).

For this reason extensions defined for G-DOI should be redefined for G-IKEv2
(once it becomes an RFC).

>From my reading of RFC 8052, it doesn't define new payloads for GDOI,
instead new ID type, Protocol ID etc. 

are specified. The same approach could be used for G-IKEv2 too.

 

Regards,

Valery.

 

Hi,

 

I've got a question regarding the relation of G-IKEv2 and GDOI. 

 

I realized that G-IKEv2 will be the successor of GDOI and would have a
question regarding backward compatibility of payloads defined for GDOI. As
the underlying exchanges for the base key management changed from IKE to
IKEv2 they will not be backward compatible. Nevertheless, there have been
enhancements of GDOI for protocols used in the power system domain like
GOOSE and Sampled Values, which lead to the definition of new payloads for
the ID, SA TEK and KD payloads to accommodate the power system protocol
parameters in RFC 8052. Likewise, using the same approach new payloads of
the same types have been defined to distribute parameters for PTP (Precision
Time Protocol) in IEC 62351-9. 

 

In general, I realized that there are similar payloads available in G-IKEv2
but I was not quite sure, if it was a design criterion to have backward
compatibility for extensions/enhancements defined for GDOI to be usable also
in G-IKEv2. Could you please shed some light on this?

 

Best regards

Steffen

 

--
Steffen Fries

Siemens AG
Technology
Cybersecurity & Trust
T CST
Otto-Hahn-Ring 6
81739 Munich, Germany
Phone: +49 (89) 7805-22928
 <mailto:steffen.fries@siemens.com> mailto:steffen.fries@siemens.com
www.siemens.com

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann
Snabe; Managing Board: Roland Busch, Chairman, President and Chief Executive
Officer; Cedrik Neike, Matthias Rebellius, Ralf P. Thomas, Judith Wiese;
Registered offices: Berlin and Munich, Germany; Commercial registries:
Berlin-Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE
23691322