[IPsec] storm WG: Updating RFC 3723's IP Storage profile of IPsec

"Black, David" <david.black@emc.com> Sun, 10 March 2013 02:36 UTC

Return-Path: <david.black@emc.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 07F3D21F880B for <ipsec@ietfa.amsl.com>; Sat, 9 Mar 2013 18:36:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id K2NVbfMj+4gC for <ipsec@ietfa.amsl.com>; Sat, 9 Mar 2013 18:36:50 -0800 (PST)
Received: from mexforward.lss.emc.com (hop-nat-141.emc.com []) by ietfa.amsl.com (Postfix) with ESMTP id 2AD1921F8808 for <ipsec@ietf.org>; Sat, 9 Mar 2013 18:36:49 -0800 (PST)
Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com []) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r2A2an0Q015457 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ipsec@ietf.org>; Sat, 9 Mar 2013 21:36:49 -0500
Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com []) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor) for <ipsec@ietf.org>; Sat, 9 Mar 2013 21:36:36 -0500
Received: from mxhub03.corp.emc.com (mxhub03.corp.emc.com []) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r2A2aacb019165 for <ipsec@ietf.org>; Sat, 9 Mar 2013 21:36:36 -0500
Received: from mx15a.corp.emc.com ([]) by mxhub03.corp.emc.com ([]) with mapi; Sat, 9 Mar 2013 21:36:35 -0500
From: "Black, David" <david.black@emc.com>
To: IPsecme WG <ipsec@ietf.org>
Date: Sat, 09 Mar 2013 21:36:33 -0500
Thread-Topic: storm WG: Updating RFC 3723's IP Storage profile of IPsec
Thread-Index: Ac4dOBRvvZWctvprSGychCcwUc4Vpg==
Message-ID: <8D3D17ACE214DC429325B2B98F3AE71290DCD887@MX15A.corp.emc.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "Black, David" <david.black@emc.com>
Subject: [IPsec] storm WG: Updating RFC 3723's IP Storage profile of IPsec
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.12
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: Sun, 10 Mar 2013 02:36:51 -0000

In connection with updating iSCSI, the storm WG is going to need to update
the IP Storage profile of IPsec in RFC 3723.  I'm sending this note to
the ipsecme WG now, as I think this is related to the discussion of
cryptographic algorithm requirements on Tuesday.

**IMPORTANT**: The RFC 3723 profile of IPsec differed from the cryptographic
algorithm requirements for IPsec v2 (24xx RFCs) on which RFC 3723 was based,
and I expect this to continue to be true for the update to RFC 3723 wrt the
new cryptographic algorithm requirements.

Chairs - I'd be willing to put up a slide or 2 on this at the meeting if you
think that would be useful.

-- RFC 3723

Here's what RFC 3723 had to say about cryptographic algorithms:

   To provide confidentiality with ESP, ESP with 3DES in CBC mode
   [RFC2451][3DESANSI] MUST be supported, and AES in Counter mode, as
   described in [RFC3686], SHOULD be supported.  To provide data origin
   authentication and integrity with ESP, HMAC-SHA1 [RFC2404] MUST be
   supported, and AES in CBC MAC mode with XCBC extensions [RFC3566]
   SHOULD be supported.  DES in CBC mode SHOULD NOT be used due to its
   inherent weakness.  ESP with NULL encryption MUST be supported for

-- Data Integrity and Origin Authentication changes

The only proposed change for these algorithm requirements is to add:

     - Implementations that support IKEv2 [RFC5996] SHOULD also
       implement AES GMAC [RFC4543] 

-- Encryption Algorithm changes

This one's a bit more involved, because there are concerns with
both of the encryption algorithms for which RFC 3723 stated requirements.

(1) The MUST for 3DES-CBC has become questionable due to 3DES's
64 bit block size, i.e., the core cipher encrypts or decrypts 64 bits
at a time.

Things start to go awry cryptographically as one approaches the
birthday bound of 32GB (GigaBytes) of data encrypted under the
same key.  As a reminder, here are a couple of links:


How far away to stay from that bound is a judgment call, but 32GB
or some fraction thereof is not a lot of data for iSCSI to move.

One could deal with this via rekeying, but the result will be
rather frequent rekeying if one decides to stay at least an order
of magnitude away on a multi-gigabit/sec link.

In contrast, AES has a 128 bit blocksize, and so its birthday
bound is astronomical (2^69 bytes if I have the math right).

AES CBC is the most common mandatory-to-implement mode for

(2) AES CTR was originally selected for its hardware friendliness
(e.g., it pipelines well), even though there was no hardware
friendly integrity MAC algorithm to go with it at the time.  AES GCM
is now the strongly preferred choice, as it provides encryption
and a MAC.

... Now comes the fun ...

Proposal (w/o RFC citations, all AES requirements are for 128 bit keys):

     - 3DES in CBC mode MAY be implemented (previously MUST)
     - AES in CBC mode MUST be implemented (previously implicitly MAY)
     - AES in Counter mode MAY be implemented (previously SHOULD)
     - Implementations that support IKEv2 SHOULD also
       implement AES GCM (new requirement)
     - DES MUST NOT be implemented or used (previously SHOULD NOT)
     - NULL encryption MUST be implemented (no change)

The intent is that these requirements are readily met by widely
available IPsec implementations.

--David (storm WG co-chair)
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
david.black@emc.com        Mobile: +1 (978) 394-7754