[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 [127.0.0.1]) 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-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (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 [127.0.0.1]) 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, 03 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. -- kivinen@iki.fi
- [IPsec] Comments to draft-amjads-ipsecme-ikev2-da… Tero Kivinen