[storm] storm WG - iSCSI standards work completed!!

"Black, David" <david.black@emc.com> Wed, 27 November 2013 22:00 UTC

Return-Path: <david.black@emc.com>
X-Original-To: storm@ietfa.amsl.com
Delivered-To: storm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97C811ADFEE for <storm@ietfa.amsl.com>; Wed, 27 Nov 2013 14:00:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, 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 DbX3yoB18cRg for <storm@ietfa.amsl.com>; Wed, 27 Nov 2013 14:00:08 -0800 (PST)
Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by ietfa.amsl.com (Postfix) with ESMTP id D3AA71AD937 for <storm@ietf.org>; Wed, 27 Nov 2013 14:00:03 -0800 (PST)
Received: from maildlpprd52.lss.emc.com (maildlpprd52.lss.emc.com [10.106.48.156]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rARM0030027708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <storm@ietf.org>; Wed, 27 Nov 2013 17:00:01 -0500
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com rARM0030027708
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1385589601; bh=2BRtQ5/ev8aFWBT84+Ly5YmI3gw=; h=From:To:Date:Subject:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=OKGWO7ZA9f7Np3AclAY/9M8xlyfwogQ9/AGw/An4QveLyevpwXz7YsFqxsKAlpVpc 4IV57h7NI6jCFrlvhFTsmNQRAwI3ov2/EfowSMPYa99s22jnyl131lGLGIGtaZyDeD kZndtOXuL9AGZGGndFkVBTL3TjjANbHXZb+9nn54=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com rARM0030027708
Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com [10.106.48.18]) by maildlpprd52.lss.emc.com (RSA Interceptor) for <storm@ietf.org>; Wed, 27 Nov 2013 16:59:51 -0500
Received: from mxhub07.corp.emc.com (mxhub07.corp.emc.com [128.222.70.204]) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rARLxpaU030331 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <storm@ietf.org>; Wed, 27 Nov 2013 16:59:51 -0500
Received: from mx15a.corp.emc.com ([169.254.1.239]) by mxhub07.corp.emc.com ([128.222.70.204]) with mapi; Wed, 27 Nov 2013 16:59:50 -0500
From: "Black, David" <david.black@emc.com>
To: "storm@ietf.org" <storm@ietf.org>
Date: Wed, 27 Nov 2013 16:59:50 -0500
Thread-Topic: storm WG - iSCSI standards work completed!!
Thread-Index: Ac7ru/x6gOBQC2gjSfeW3F2V6YiAcw==
Message-ID: <8D3D17ACE214DC429325B2B98F3AE712026ADFAD84@MX15A.corp.emc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd53.lss.emc.com
X-RSA-Classifications: DLM_1, public
Subject: [storm] storm WG - iSCSI standards work completed!!
X-BeenThere: storm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Storage Maintenance WG <storm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/storm>, <mailto:storm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/storm/>
List-Post: <mailto:storm@ietf.org>
List-Help: <mailto:storm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/storm>, <mailto:storm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Nov 2013 22:00:10 -0000

The approval announcement below completes the technical work on the revised
iSCSI standards in the storm WG.  This is a major accomplishment, and I want
to thank everyone involved starting with the authors of the drafts.

Thank you!!

In addition to checks required as the drafts are processed into RFCs (e.g.,
questions from IANA, Authors 48 Hours checks) I still need to write a couple
of RFC Editor notes to make these updates to the Consolidated iSCSI draft:

(A) OCSP is now allowed for checking certificates in addition to use of CRLs.

(B) Extended sequence numbers (ESNs) are now required for ESPv2 (IPsec v2 -
	RFC 2406) in addition to ESPv3 (IPsec v3 - RFC 4303).

The "long pole" for publication of these new RFCs is going to be some SCSI
standards work at T10 to support use of iSCSI Protocol Level values in SCSI
version descriptors.  Fred Knight and I hope to get this done at the January
2014 T10 meetings, and with luck, RFC publication will follow not too long
thereafter - before the London IETF meeting week if things go quickly, but
that's not a certainty.

Thanks,
--David


> -----Original Message-----
> From: IETF-Announce [mailto:ietf-announce-bounces@ietf.org] On Behalf Of The
> IESG
> Sent: Wednesday, November 27, 2013 8:50 AM
> To: IETF-Announce
> Cc: storm mailing list; storm chair; RFC Editor
> Subject: Protocol Action: 'Securing Block Storage Protocols over IP: RFC 3723
> Requirements Update for IPsec v3' to Proposed Standard (draft-ietf-storm-
> ipsec-ips-update-04.txt)
> 
> The IESG has approved the following document:
> - 'Securing Block Storage Protocols over IP: RFC 3723 Requirements Update
>    for IPsec v3'
>   (draft-ietf-storm-ipsec-ips-update-04.txt) as Proposed Standard
> 
> This document is the product of the STORage Maintenance Working Group.
> 
> The IESG contact persons are Martin Stiemerling and Spencer Dawkins.
> 
> A URL of this Internet Draft is:
> http://datatracker.ietf.org/doc/draft-ietf-storm-ipsec-ips-update/
> 
> 
> 
> 
> Technical Summary
> 
>    RFC 3723 specifies IPsec requirements for block storage protocols
>    over IP (e.g., iSCSI) based on IPsec v2 (RFC 2401 and related RFCs);
>    those requirements have subsequently been applied to remote direct
>    data placement protocols, e.g., RDMAP.  This document updates RFC
>    3723's IPsec requirements to IPsec v3 (RFC 4301 and related RFCs) and
>    makes some changes to required algorithms based on developments in
>    cryptography since RFC 3723 was published.
> 
> Working Group Summary
> 
>    This document updates the IPsec requirements in RFC 3723 and all RFCs
>    to which those requirements apply.  The iSCSI maintenance work in
>    the storm WG had originally intended to only update the IPsec
>    requirements for iSCSI.  Two developments changed this approach:
> 
>    o Cryptographic developments upended RFC 3723's requirement for 3DES
>      as the mandatory to implement encryption transform.  The protocols
>      to which RFC 3723 applies can approach 3DES's birthday bound and
>      need to rekey in less than a minute on high-speed links.
> 
>    o iSER (iSCSI extensions for RDMA) uses RFC 3723 IPsec requirements
>      twice, once for iSCSI and once for the underlying rddp (iWARP)
>      RDMA protocol.  An RFC 3723 update is needed for the latter in
>      order to avoid inconsistent IPsec requirements in the same protocol
>      stack.
> 
>    David McGrew and Steve Kent (respectively) deserve credit for surfacing
>    the above two concerns that lead to creation of this document.  This
>    document has not been controversial in the storm WG.
> 
> 
> Document Quality
> 
>    This document specifies a profile of widely implemented protocols,
>    IPsec v2 and v3.  The specified cryptographic transforms have been
>    selected as ones that are commonly available in IPsec implementations.
> 
>    Sean Turner (SEC AD) and Paul Hoffman (ipsecme WG chair) were both
>    notably helpful in providing advice on transform selection.  Yaron
>    Sheffer (ipsecme WG chair) provided a thorough review that significantly
>    improved the quality of this document.  Tom Talpey (storm WG chair)
>    provided a thorough WG Last Call review.
> 
>    The document shepherd is very pleased with the help received from
>    both ipsecme WG co-chairs and the AD responsible for the ipsecme WG.
> 
> Personnel
> 
>    Document Shepherd: David Black (storm WG co-chair, david.black@emc.com)
>    Responsible Area Director: Martin Stiemerling (Transport,
> martin.stiemerling@neclab.eu)
> 
> 
>