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

Tero Kivinen <kivinen@iki.fi> Mon, 03 March 2014 16:20 UTC

Return-Path: <kivinen@iki.fi>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 89AAA1A01E4 for <ipsec@ietfa.amsl.com>; Mon, 3 Mar 2014 08:20:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Cu5wZXZYRvnC for <ipsec@ietfa.amsl.com>; Mon, 3 Mar 2014 08:19:58 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 05F6D1A00B6 for <ipsec@ietf.org>; Mon, 3 Mar 2014 08:19:57 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost []) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id s23GJrvB022117 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for <ipsec@ietf.org>; Mon, 3 Mar 2014 18:19:53 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id s23GJraO021144; Mon, 3 Mar 2014 18:19:53 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <21268.43945.628205.309410@fireball.kivinen.iki.fi>
Date: Mon, 3 Mar 2014 18:19:53 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: ipsec@ietf.org
X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd)
X-Edit-Time: 10 min
X-Total-Time: 9 min
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/opjBvDF9NJbfNMluXtAiRVNHfFI
Subject: [IPsec] Comments to draft-amjads-ipsecme-ikev2-data-channel-00
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Mar 2014 16:20:13 -0000

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.