Re: [IPsec] GDOI and G-IKEv2 payloads

Valery Smyslov <smyslov.ietf@gmail.com> Wed, 07 February 2024 08:02 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 CA8E0C14F6A0 for <ipsec@ietfa.amsl.com>; Wed, 7 Feb 2024 00:02:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.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, 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=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 QcRuxgp4GoHd for <ipsec@ietfa.amsl.com>; Wed, 7 Feb 2024 00:02:37 -0800 (PST)
Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (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 91170C14F6E8 for <ipsec@ietf.org>; Wed, 7 Feb 2024 00:02:37 -0800 (PST)
Received: by mail-wm1-x336.google.com with SMTP id 5b1f17b1804b1-40fe79f1aaaso2633505e9.0 for <ipsec@ietf.org>; Wed, 07 Feb 2024 00:02:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1707292956; x=1707897756; darn=ietf.org; h=thread-index:content-language:content-transfer-encoding :mime-version:message-id:date:subject:in-reply-to:references:cc:to :from:from:to:cc:subject:date:message-id:reply-to; bh=d+KWrBotLw+Pa7NQWVSXMuplTh4vwIu0bPUB3ju2CFc=; b=nPyEWWo/LkhI5XDaAVjBqcxjHV05xUYOKHFHyGxXGOolr1EOZrtrphlkF5zXcr5qm5 vRlZSEjodPkaRMj+tpnaDpsE2kvAqawYCC/aMwbp5Hcyrv4rIAkTvrLdivdkWyOKs99X CgG9ou4V+uD79lVTNM6gForhaax7LcISUnxoSwkoFDfYOgEskbD+qgy/lTwV6qKfYuLv Ikz9yH1G+dcIOM+gSQBnR0A7ibUu72D3DiVmpKMGXjpGmzuxlWFAjL780y2VZ7+2L2lE QvqpNJFRzo/gHL4MFP5MAuLWWDATw++oeelKJhgysrcFEHDTFom6H4YDIkzL1uhpj6fE O8hA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707292956; x=1707897756; h=thread-index:content-language:content-transfer-encoding :mime-version:message-id:date:subject:in-reply-to:references:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=d+KWrBotLw+Pa7NQWVSXMuplTh4vwIu0bPUB3ju2CFc=; b=HEH3Xhw9tXFJBqublCcuQchFLJ0WODbkF6IFJvcKbk1uXP+FzaW4Q4LjJ02qq0RA+4 16OU4dLQUSbSle/GPlVbuVOg4sKbVW1VLVonibXB+/pHdNQgo5q65+nMdM1t7CIra+f1 JFkYpOtqETfcuWaXpMR9uc6A/ZWW3ycIwTzbDJXG2viDPLOgg3JAbr5nmrFWUIZxQwSV zPWa2D4UWjhdseu+6QNT65GSy2byubdRGve63C0RvfGJ+nNQDfE2jeUuYHrAfuLh/Sau xyGp/CuhE2tdagUveb4KFFyeC74fMRsV1WWL2q2biPwMeiErTcTSkgcdxYODfp4BA5VV U+hg==
X-Forwarded-Encrypted: i=1; AJvYcCWoArHNMhMPfjJXwNNP9BxwF0lvjYpNMQtoTydHOrYRdPQ7bw/PG6ciBMXeTbZkN55UOEe7EgTi4fPSAA0RZQ==
X-Gm-Message-State: AOJu0YyrjoZL9RpBmBiTTtFrqsC5Yi8T+Yn+OFpq7wsEQg/w2QMNlqtm 7iG1d0q3FgKW3M0J4ll+1cJUFciDocMPxaspBc/nCy8s0WnJdrEmP20A7Dwo
X-Google-Smtp-Source: AGHT+IEau46cgXl8zDsT+wJ/rH9UdanUbtt2gTMWkMPOLcFvrdqdtSvrIFggwkDxXWn7ZLXZPofOJA==
X-Received: by 2002:a05:600c:1ca3:b0:40f:ddd0:d707 with SMTP id k35-20020a05600c1ca300b0040fddd0d707mr3887449wms.32.1707292955352; Wed, 07 Feb 2024 00:02:35 -0800 (PST)
X-Forwarded-Encrypted: i=1; AJvYcCWRXopasDj2NG4/8F8En+awBZhf5JVQYqEdzul6kKB+Kzaf8ai9UVZPaSxTd/NHt1zjKdPjOT0OU/EZxykmKg==
Received: from BuildPC ([93.188.44.204]) by smtp.gmail.com with ESMTPSA id x19-20020a05600c2a5300b0040fbdd6f69bsm4283266wme.33.2024.02.07.00.02.34 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Feb 2024 00:02:34 -0800 (PST)
From: Valery Smyslov <smyslov.ietf@gmail.com>
To: 'Toerless Eckert' <tte@cs.fau.de>
Cc: "'Fries, Steffen'" <steffen.fries=40siemens.com@dmarc.ietf.org>, ipsec@ietf.org
References: <DB9PR10MB6354CF46CDE84485FB1510BCF3472@DB9PR10MB6354.EURPRD10.PROD.OUTLOOK.COM> <ZcEQWFuF7Uj_dY-d@faui48e.informatik.uni-erlangen.de> <02ff01da58ce$88f7f630$9ae7e290$@gmail.com> <ZcJayWHonFVxYRhv@faui48e.informatik.uni-erlangen.de>
In-Reply-To: <ZcJayWHonFVxYRhv@faui48e.informatik.uni-erlangen.de>
Date: Wed, 07 Feb 2024 11:02:33 +0300
Message-ID: <037401da599c$0242e680$06c8b380$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Content-Language: ru
Thread-Index: AQJ9gH558reIYOrUNdeISaKBvcFO0wJuat3FAnu9GacBA+7Jha+IxPkw
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/lh9PK2qrlWB-HeFV4ZYvlsEfFJY>
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: Wed, 07 Feb 2024 08:02:42 -0000

Hi Toerless,

> Well... There may be connection between progressing the draft and these
> extensions.
> 
> Given how extensions to GDOI where also done by other SDOs, i would like
to
> understand if
> G-IKEv2 has done the best to make extensions as painless as possible,
especially
> for adopting extensions previously existing in GDOI. Worst case, G-IKEv2
does
> make any such extensions more difficult than necessary (not what i would
think,
> just thinking paranoid).

G-IKEv2 is based on IKEv2 which has numerous extensions.

> Ideally, i would even like to see a small section in G-IKEv2 that outlines
how GDOI
> extensions can be mapped to G-IKEv2 . If this waas all registry entries in
> RFC8052, then it would IMHO even be a great exercise for progressing
G-IKEv2 to
> see if equivalent registry entries for
> G-IKEv2 would be sufficient. And the section i am thinking of would for
example
> just be a comparison of registry tables.

I don't think core specification should define how all existing extensions
of an older protocol could be mapped to the current one, but few general
words could be added.

Regards,
Valery.

> Cheers
>     Toerless
> 
> On Tue, Feb 06, 2024 at 10:31:43AM +0300, Valery Smyslov wrote:
> > Hi Toerless,
> >
> > first G-IKEv2 should be published as RFC. The draft is currently in
> > WGLC (for a long time), but received very few reviews so far (and many
> > thanks to all who reviewed it!).
> > I'm planning to publish an updated version addressing Daniel's review
soon.
> >
> > Once G-IKEv2 is standardized, there is no problem (IMHO) to do the
> > equivalent of RFC8052 with it.
> >
> > Regards,
> > Valery.
> >
> > > How would someone today do the equivalent of RFC8052 with G-IKEv2 ?
> > >
> > > On Mon, Feb 05, 2024 at 04:06:11AM +0000, Fries, Steffen wrote:
> > > > 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
> > > > www.siemens.com
> > > > [Logo]
> > > > 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
> > >
> > > _______________________________________________
> > > IPsec mailing list
> > > IPsec@ietf.org
> > > https://www.ietf.org/mailman/listinfo/ipsec