Re: [IPsec] GDOI and G-IKEv2 payloads

['Toerless Eckert' <[e-mail]>]

On Wed, Feb 07, 2024 at 11:02:33AM +0300, Valery Smyslov wrote:
> Hi Toerless,

[snip]

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

I was imagining:

a) A table where each row has two columns, one showing the term for the IKEv1/ISAKMP
   extension point, the other the term for the IKEv2 extension point.

   explanations if the functionality achieved by using the new extension point is not the
   same (or better) than the old extension point.

b) Understanding whether one could even transparently support the same extension functionality
   for ISAKMP and IKEv2 by just using an appropriate API. Aka: The registration code point was
   known only to the API provider, so depending on whether ISAKMP/IKEv1 or IKEv2 is being used.
   If this is feasible, it would give developers a good understsanding of the simplicity of
   migration. If this would not be feasible, then that would point to functionalities
   that are not fully backward compatible and/or require more thinking in IKEv2

The solutions that depend on these extensions do also may require some non-extension point
"base" functionality of GDOI, so i too wonder about b) just for the GDOI base functionality.
For example, i could imagine that for reasons of security some crypto suite recommendations
would have changed, so if any deployments of GDOI solutions have some performance aspects,
the newer crypto profiles may make that more challenging on older hardware (but no idea, from
past memory, IPsec seemed to be a lot more friendly with legacy than TLS ;-).

Cheers
    Toerless

> 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: [phone]
> > > > > mailto:[e-mail]
> > > > > 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
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/ipsec

-- 
---
[e-mail]