Subject: [IPsec] Comments to draft-amjads-ipsecme-ikev2-data-channel-00

From: Tero Kivinen <[email-masked]>
Date: Mon, 3 Mar 2014 18:19:53 +0200

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-masked]