Hi Valery, hi Toerless, I like the proposal from Toerless regarding explaining text for the existing (GDOI) payloads and how they may be adopted in G-IKEv2 and if there need to be new registrations at IANA. This is certainly something which would be good for an appendix and not for the main document, but it would definitely help to have a migration towards G-IKEv2. As the payloads are further handled by the application keeping the payloads alike would avoid to have to much changes in the application logic.
As GDOI is utilized and profiled for key management in the power industry in IEC 62351-9 to be used for security parameter distribution for power system specific protocols and also for providing for time synchronization with PTP, it would be good to see how the way forward looks like. What has been done in IEC 62351-9 is a profiling of GDOI for the target application domain (also with the help of RFC 8052) regarding the utilized payloads and also regarding restrictions of the utilized algorithms (avoiding SHA-1, etc.). That said, the approach is already restrictive regarding the options and algorithms. The benefit of taking also G-IKEv2 into account is the handling of PQC, which likely will not be done for IKEv1, so GDOI would not participate in that development when done for IKEv2. In addition, the GDOI mechanisms of pulling and pushing security parameters is used. From what I understood from G-IKEv2, only pushing is used as stated in the introduction, but I'm not sure if this is more a terminology point to clarify the relation to the GDOI definition of PULL/PUSH exchanges. Maybe this could also be added in an appendix. G-IKEv2 states that after registration the GCKS provides the parameters to the GM, which may be seen as a PULL. Best regards Steffen > -----Original Message----- > From: Valery Smyslov <smyslov.i...@gmail.com> > Sent: Wednesday, February 7, 2024 9:03 AM > To: 'Toerless Eckert' <t...@cs.fau.de> > Cc: Fries, Steffen (T CST) <steffen.fr...@siemens.com>; ipsec@ietf.org > Subject: RE: [IPsec] GDOI and G-IKEv2 payloads > > 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.fr...@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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > > > > www.ietf.org%2Fmailman%2Flistinfo%2Fipsec&data=05%7C02%7Csteffen.f > > > > > ries%40siemens.com%7Caaff77f3882d4ea2916908dc27b329de%7C38ae3bcd95 > > > > > 794fd4addab42e1495d55a%7C1%7C0%7C638428897652646984%7CUnknown% > 7CTW > > > > > FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX > > > > > VCI6Mn0%3D%7C0%7C%7C%7C&sdata=c61FEvwH1Io7D0bHOHKds8gxOJC0sLd5 > dX%2 > > > > Bur23FO80%3D&reserved=0 _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
