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://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
