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