We disagree on this. I think that if some solution can be re-used in
a similar protocol, then it saves a lot of unnecessary work.
G-IKEv2 is based on IKEv2 and they are very similar. Not only framing,
but also the core crypto formulas are the same.
But as you pointed out key distribution and generation are not same.
Yes, the method we define here should be easily re-used in there, but
it still do require some work, and that is something thta the G-IKEv2
people needs to do.
As far as I understand, the method from the draft can be reused in G-IKEv2
as-is.
And if we choose not to protect IKE SA, then they will need to reinvent the
wheel.
And because it is used in the SKEYSEED it means we need to know which
PPK is used BEFORE we can decrypt IKE_AUTH, which means that we cannot
use identity to pick it. And because of that we need to make
complicated method of telling which PPK is used in the IKE_SA_INIT
using fixed ciphers that are not implemented on all devices (for
example IoT).
The ciphers are not really fixed. There is a kind of negotiation
during cookie exchanhe. Abd the draft can be easily modified
to re-use existing IKEv2 registries for the crypto primitives - see
https://mailarchive.ietf.org/arch/msg/ipsec/r4I5SCIEt4BmXsROCDXZXTbVuIc
The support for the cookie exchange is mandatory in the IKEv2,
adding a couple notification to it doesn't add much complexity.
Regards,
Valery.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
