[IPsec] RFC4307 & ENCR_NULL & USGv6 profile & Roadmap document

Tero Kivinen <kivinen@iki.fi> Tue, 20 October 2009 13:41 UTC

Return-Path: <kivinen@iki.fi>
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58CE23A67E4 for <ipsec@core3.amsl.com>; Tue, 20 Oct 2009 06:41:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.024
X-Spam-Level:
X-Spam-Status: No, score=-2.024 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GDATMjSa4NFE for <ipsec@core3.amsl.com>; Tue, 20 Oct 2009 06:40:57 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id F09713A6946 for <ipsec@ietf.org>; Tue, 20 Oct 2009 06:40:56 -0700 (PDT)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n9KDexi0000790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Oct 2009 16:40:59 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n9KDex9F006369; Tue, 20 Oct 2009 16:40:59 +0300 (EEST)
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: <19165.48619.530034.469960@fireball.kivinen.iki.fi>
Date: Tue, 20 Oct 2009 16:40:59 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: ipsec@ietf.org
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 12 min
X-Total-Time: 12 min
Cc: pasi.eronen@nokia.com, sheila.frankel@nist.gov
Subject: [IPsec] RFC4307 & ENCR_NULL & USGv6 profile & Roadmap document
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Tue, 20 Oct 2009 13:41:01 -0000

I was reading the USGv6 profile, and it complained that RFC4307 and
RFC4835 do not agree on status of NULL encryption. RFC4307 says MAY,
and RFC4835 says MUST.

As far as I have understood the RFC4835 defines algorithm requirements
for Child SAs (ESP and AH), and RFC4307 defines algorithm requirements
for IKEv2 SAs, i.e. when IKEv2 protects its own traffic.

However while the roadmap document agrees on that ("[RFC4307]
specifies the encryption and integrity-protection algorithms used by
IKEv2 to protect its own traffic") it also final sentence which makes
this not so clear: "It also specifies the encryption and
integrity-protection algorithms that IKEv2 negotiates for use within
IPsec."

I.e. that last sentence would indicate that RFC4307 would also define
encryption and integrity-protection algorithms for Child SAs. On the
other hand it does not list IPsec-v2 nor IPsec-v3 on the requirements
level so that would indicate it does not apply to IPsec, only to IKE.

In the abstract RFC4307 does not clearly say whether it only covers
IKEv2 traffic or if it also covers Child SA (IPsec, ESP/AH) traffic
negotiated with IKEv2. But later in the section 3.1.1 it clearly says
that "The IKEv2 Encryption Payload requires..." which indicates it
only covers IKEv2 SA traffic not anything else.

If this is true, then the requirement level for ENCR_NULL is clearly
wrong, as RFC4306 says that ENCR_NULL MUST NOT be used when protecting
IKEv2 SA traffic (section 5. Security Considerations).

So I would suggest we remove the misleading last sentence from the
draft-ietf-ipsecme-roadmap-04.txt section 5.1.2, and make an errata
for RFC4307 saying that ENCR_NULL is "MUST NOT" instead of "MAY".

Also the USGv6 document might also distinguish the fact that RFC4835
and RFC4307 cover different protocols, thus they does not need to
agree on the requirement levels, and NULL encryption cannot really be
required for IKEv2 as it would go against MUST NOT in RFC4306.
-- 
kivinen@iki.fi