Re: [IPsec] GDOI and G-IKEv2 payloads

[Fries, Steffen]

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 
> Sent: Wednesday, February 7, 2024 9:03 AM
> To: 'Toerless Eckert' 
> Cc: Fries, Steffen (T CST) ; 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 +, 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 ba

Re: [IPsec] GDOI and G-IKEv2 payloads

['Toerless Eckert']

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 +, 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

Re: [IPsec] GDOI and G-IKEv2 payloads

[Tero Kivinen]

Valery Smyslov writes:
> > 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.

G-IKEv2 will have its own IANA registries just like IKEv2 has separate
registries compared to the IKEv1. This will mean that none of the old
extensions can be used directly for G-IKEv2 as new IANA allocations
will be needed, but making new RFC that will define how old G-DOI
extension for G-IKEv2 should be quite simple, mostly just doing IANA
allocations and using IKEv2 terms and payloads instead of old ones.

I do not see any major issues for making an RFC that adds old G-DOI
extension to G-IKEv2.
-- 
kivi...@iki.fi

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] GDOI and G-IKEv2 payloads

[Valery Smyslov]

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 +, 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

Re: [IPsec] GDOI and G-IKEv2 payloads

['Toerless Eckert']

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

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.

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 +, 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

Re: [IPsec] GDOI and G-IKEv2 payloads

[Valery Smyslov]

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 +, 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

Re: [IPsec] GDOI and G-IKEv2 payloads

[Toerless Eckert]

How would someone today do the equivalent of RFC8052 with G-IKEv2 ?

On Mon, Feb 05, 2024 at 04:06:11AM +, 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

Re: [IPsec] GDOI and G-IKEv2 payloads

[Fries, Steffen]

Hi Valery,

Thank you for the prompt answer. This is somehow what I have expected. Just 
wanted to double check. So there is at least the chance to proceed with the 
approach picked in RFC 8052. It still requires specification, but allows for 
taking the same approach. This would be important to have at least the same 
semantic of the payloads.

That already answers my question.

Best regards
Steffen

From: Valery Smyslov 
Sent: Monday, February 5, 2024 8:52 AM
To: Fries, Steffen (T CST) ; ipsec@ietf.org
Subject: RE: [IPsec] GDOI and G-IKEv2 payloads

Hi, Steffen,

in general, G-IKEv2 is not backward compatible with GDOI (likewise IKEv2 is not 
backward compatible with IKEv1).
For this reason extensions defined for G-DOI should be redefined for G-IKEv2 
(once it becomes an RFC).
>From my reading of RFC 8052, it doesn't define new payloads for GDOI, instead 
>new ID type, Protocol ID etc.
are specified. The same approach could be used for G-IKEv2 too.

Regards,
Valery.

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

Re: [IPsec] GDOI and G-IKEv2 payloads

[Valery Smyslov]

Hi, Steffen,

 

in general, G-IKEv2 is not backward compatible with GDOI (likewise IKEv2 is
not backward compatible with IKEv1).

For this reason extensions defined for G-DOI should be redefined for G-IKEv2
(once it becomes an RFC).

>From my reading of RFC 8052, it doesn't define new payloads for GDOI,
instead new ID type, Protocol ID etc. 

are specified. The same approach could be used for G-IKEv2 too.

 

Regards,

Valery.

 

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

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] GDOI and G-IKEv2 payloads

[Fries, Steffen]

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