First of all, I am really dubious whether this is needed. When I
started reading this, I first assumed, ok, it is used to transfer some
data between two nodes from userland to userland without any need for
kernel IPsec stack, or some configuration / policy data that is needed
before the ESP SA can be brought up.
I was really suprised that this actually transmits IPv4 and IPv6
packets inside the IKE. I.e. it just replaces the ESP with IKEv2. I
see any real benefit from that. What is the use case for this?
I think it would be much easier to just create one IPsec ESP SA and
run your IP packets over that?
I think it is bad idea to create tunneling IP packets over IKEv2 over
UDP over IP solution.
Some other nits: In the section 8.1 it says:
o Protocol ID (1 octet): MUST be 1, as this message is related to an
IKEv2 SA.
This is wrong. The RFC5996 says that Protocol ID MUST be 0, as there
is no SPI:
o Protocol ID (1 octet) - If this notification concerns an existing
SA whose SPI is given in the SPI field, this field indicates the
type of that SA. For notifications concerning Child SAs, this
field MUST contain either (2) to indicate AH or (3) to indicate
ESP. Of the notifications defined in this document, the SPI is
included only with INVALID_SELECTORS and REKEY_SA. If the SPI
field is empty, this field MUST be sent as zero and MUST be
ignored on receipt.
--
[email protected]
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
