From Internet-Drafts@ietf.org Wed Jun 5 12:52:20 2013 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26C5821F9AD1; Wed, 5 Jun 2013 12:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.542 X-Spam-Level: X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pgswhd2t1SMn; Wed, 5 Jun 2013 12:52:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0068721F9AB3; Wed, 5 Jun 2013 12:51:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130605195117.18860.46929.idtracker@ietfa.amsl.com> Date: Wed, 05 Jun 2013 12:51:17 -0700 Cc: storm@ietf.org Subject: [storm] I-D ACTION:draft-ietf-storm-ipsec-ips-update-00.txt X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 19:52:20 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the STORage Maintenance Working Group of the IETF. Title : IP Storage: IPsec Requirements Update for IPsec v3 Author(s) : D. Black, et al Filename : draft-ietf-storm-ipsec-ips-update Pages : 13 Date : June 5, 2013 RFC 3723 includes requirements for IPsec usage with IP Storage protocols (e.g., iSCSI) based on IPsec v2 (RFC 2401 and related RFCs). This document updates those requirements to IPsec v3 (RFC 4301 and related RFCs) and updates implementation requirements to reflect developments in cryptography since RFC 3723 was published. [RFC Editor: The "Updates:" list above has been truncated by xml2rfc. The complete list is - Updates: 3720, 3723, 3821, 3822, 4018, 4172, 4173, 4174, 5040, 5041, 5042, 5043, 5044, 5045, 5046, 5047, 5048 (if approved) ] A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-storm-ipsec-ips-update-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-storm-ipsec-ips-update"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2013-06-05125117.I-D@ietf.org> --NextPart-- From david.black@emc.com Wed Jun 5 13:02:36 2013 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3999F21F9AB8 for ; Wed, 5 Jun 2013 13:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RncvpL62iOrB for ; Wed, 5 Jun 2013 13:02:29 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 9F7B621F9B5F for ; Wed, 5 Jun 2013 13:02:25 -0700 (PDT) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r55K26R7012616 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 5 Jun 2013 16:02:09 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd06.lss.emc.com [10.254.222.130]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor) for ; Wed, 5 Jun 2013 16:01:48 -0400 Received: from mxhub06.corp.emc.com (mxhub06.corp.emc.com [128.222.70.203]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r55K1aa3012479 for ; Wed, 5 Jun 2013 16:01:48 -0400 Received: from mx15a.corp.emc.com ([169.254.1.184]) by mxhub06.corp.emc.com ([128.222.70.203]) with mapi; Wed, 5 Jun 2013 16:01:43 -0400 From: "Black, David" To: "storm@ietf.org" Date: Wed, 5 Jun 2013 16:01:42 -0400 Thread-Topic: I-D ACTION:draft-ietf-storm-ipsec-ips-update-00.txt Thread-Index: Ac5iJnGtVfuFKI0HT/ehgqMorrQ4NgAAH/UQ Message-ID: <8D3D17ACE214DC429325B2B98F3AE712980C9E7D@MX15A.corp.emc.com> References: <20130605195117.18860.46929.idtracker@ietfa.amsl.com> In-Reply-To: <20130605195117.18860.46929.idtracker@ietfa.amsl.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-EMM-MHVC: 1 Subject: Re: [storm] I-D ACTION:draft-ietf-storm-ipsec-ips-update-00.txt X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 20:02:36 -0000 This is the long-promised draft that updates the IPsec requirements to incl= ude the 430x RFCs, and make other requirements changes as previously discus= sed on the list. I want to thank Paul Koning for signing up to co-author i= t. This draft will be headed directly into WG Last Call early next week (Tom w= ill do the honors, as I'm a co-author of this draft), because both the cons= olidated iSCSI and iSER drafts will have normative references to this new d= raft. Thanks, --David > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org= ] On > Behalf Of Internet-Drafts@ietf.org > Sent: Wednesday, June 05, 2013 3:51 PM > To: i-d-announce@ietf.org > Cc: storm@ietf.org > Subject: I-D ACTION:draft-ietf-storm-ipsec-ips-update-00.txt >=20 > A new Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the STORage Maintenance Working Group of the > IETF. >=20 > Title : IP Storage: IPsec Requirements Update for IPsec v3 > Author(s) : D. Black, et al > Filename : draft-ietf-storm-ipsec-ips-update > Pages : 13 > Date : June 5, 2013 >=20 > RFC 3723 includes requirements for IPsec usage with IP Storage > protocols (e.g., iSCSI) based on IPsec v2 (RFC 2401 and related > RFCs). This document updates those requirements to IPsec v3 (RFC > 4301 and related RFCs) and updates implementation requirements to > reflect developments in cryptography since RFC 3723 was published. >=20 > [RFC Editor: The "Updates:" list above has been truncated by > xml2rfc. > The complete list is - Updates: 3720, 3723, 3821, 3822, 4018, 4172, > 4173, 4174, 5040, 5041, 5042, 5043, 5044, 5045, 5046, 5047, 5048 (if > approved) ] >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-storm-ipsec-ips-update-00.= txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. From internet-drafts@ietf.org Thu Jun 6 09:25:15 2013 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 891B321F999E; Thu, 6 Jun 2013 09:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.33 X-Spam-Level: X-Spam-Status: No, score=-102.33 tagged_above=-999 required=5 tests=[AWL=0.270, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rDRfqIpwZRgp; Thu, 6 Jun 2013 09:25:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B625921F99BB; Thu, 6 Jun 2013 09:25:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130606162505.1599.49413.idtracker@ietfa.amsl.com> Date: Thu, 06 Jun 2013 09:25:05 -0700 Cc: storm@ietf.org Subject: [storm] I-D Action: draft-ietf-storm-iser-14.txt X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 16:25:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the STORage Maintenance Working Group of the = IETF. Title : iSCSI Extensions for RDMA Specification Author(s) : Michael Ko Alexander Nezhinsky Filename : draft-ietf-storm-iser-14.txt Pages : 98 Date : 2013-06-06 Abstract: iSCSI Extensions for Remote Direct Memory Access (RDMA) provides the RDMA data transfer capability to iSCSI by layering iSCSI on top of an RDMA-Capable Protocol. An RDMA-Capable Protocol provides RDMA Read and Write services, which enable data to be transferred directly into SCSI I/O Buffers without intermediate data copies. This document describes the extensions to the iSCSI protocol to support RDMA services as provided by an RDMA-Capable Protocol. This document obsoletes RFC 5046. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-storm-iser There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-storm-iser-14 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-storm-iser-14 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Internet-Drafts@ietf.org Fri Jun 7 10:57:20 2013 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37B5121F8B35; Fri, 7 Jun 2013 10:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.48 X-Spam-Level: X-Spam-Status: No, score=-102.48 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00IKHd5iJjZM; Fri, 7 Jun 2013 10:57:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 186BE21F8EAE; Fri, 7 Jun 2013 10:57:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130607175713.7003.93575.idtracker@ietfa.amsl.com> Date: Fri, 07 Jun 2013 10:57:13 -0700 Cc: storm@ietf.org Subject: [storm] I-D ACTION:draft-ietf-storm-ipsec-ips-update-01.txt X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 17:57:20 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the STORage Maintenance Working Group of the IETF. Title : IP Storage: IPsec Requirements Update for IPsec v3 Author(s) : D. Black, et al Filename : draft-ietf-storm-ipsec-ips-update Pages : 14 Date : June 7, 2013 RFC 3723 includes requirements for IPsec usage with IP Storage protocols (e.g., iSCSI) based on IPsec v2 (RFC 2401 and related RFCs). This document updates those requirements to IPsec v3 (RFC 4301 and related RFCs) and updates implementation requirements to reflect developments in cryptography since RFC 3723 was published. [RFC Editor: The "Updates:" list above has been truncated by xml2rfc. The complete list is - Updates: 3720, 3723, 3821, 3822, 4018, 4172, 4173, 4174, 5040, 5041, 5042, 5043, 5044, 5045, 5046, 5047, 5048 (if approved) ] A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-storm-ipsec-ips-update-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-storm-ipsec-ips-update"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2013-06-07105711.I-D@ietf.org> --NextPart-- From ttalpey@microsoft.com Tue Jun 18 16:30:41 2013 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B92C21F8B04 for ; Tue, 18 Jun 2013 16:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8aVyauicYTuR for ; Tue, 18 Jun 2013 16:30:35 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0235.outbound.protection.outlook.com [207.46.163.235]) by ietfa.amsl.com (Postfix) with ESMTP id B86C511E8116 for ; Tue, 18 Jun 2013 16:30:28 -0700 (PDT) Received: from BY2FFO11FD007.protection.gbl (10.1.15.202) by BY2FFO11HUB025.protection.gbl (10.1.14.111) with Microsoft SMTP Server (TLS) id 15.0.707.0; Tue, 18 Jun 2013 23:30:27 +0000 Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD007.mail.protection.outlook.com (10.1.14.128) with Microsoft SMTP Server (TLS) id 15.0.707.0 via Frontend Transport; Tue, 18 Jun 2013 23:30:27 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.79]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.03.0136.001; Tue, 18 Jun 2013 23:30:22 +0000 From: Tom Talpey To: "storm@ietf.org" Thread-Topic: Working Group Last Call - IP Storage: IPsec Requirements Update for IPsec v3 Thread-Index: Ac5seEbW6YTVKeIwQ4e5vN67Pyl/4A== Importance: high X-Priority: 1 Date: Tue, 18 Jun 2013 23:30:21 +0000 Message-ID: <614F550557B82C44AC27C492ADA391AA0773D280@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.78] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(189002)(54356001)(65816001)(81542001)(44976003)(79102001)(31966008)(55846006)(56776001)(76482001)(74706001)(47446002)(59766001)(51856001)(74366001)(56816003)(74662001)(46102001)(53806001)(54316002)(50466002)(6806003)(77982001)(63696002)(47736001)(74502001)(74876001)(46406003)(81342001)(23726002)(66066001)(76786001)(69226001)(15202345002)(16406001)(80022001)(50986001)(77096001)(49866001)(47776003)(76796001)(47976001)(20776003)(76176001)(33656001)(4396001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB025; H:TK5EX14HUBC102.redmond.corp.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0881A7A935 Subject: [storm] Working Group Last Call - IP Storage: IPsec Requirements Update for IPsec v3 X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 23:30:41 -0000 This message is to announce the STORM working group Last Call on the follow= ing document: IP Storage: IPsec Requirements Update for IPsec v3 http://www.ietf.org/internet-drafts/draft-ietf-storm-ipsec-ips-update-01.tx= t This new document is created to align IP Storage IPsec profiles with IPsec-= v3 requirements. The iSCSI consolidated draft and also the iSER draft will = make normative references to this new document, therefore it is desirable t= o move it into the publication pipeline promptly, to unblock these other dr= afts. Last Call comments are due by Wednesday, July 3 at midnight Eastern time (t= wo weeks from today). Please send all technical comments to the storm mailing list: storm@ietf.or= g . Editorial comments may be sent directly to the draft authors: draft-ietf-st= orm-ipsec-ips-update@tools.ietf.org . Tom Talpey STORM WG co-chair From david.black@emc.com Tue Jun 18 17:03:15 2013 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEC5B11E80AD for ; Tue, 18 Jun 2013 17:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0KW3OSNNJGo1 for ; Tue, 18 Jun 2013 17:03:10 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id B633821F961F for ; Tue, 18 Jun 2013 17:02:51 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r5J02prJ017974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 18 Jun 2013 20:02:51 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor) for ; Tue, 18 Jun 2013 20:02:39 -0400 Received: from mxhub12.corp.emc.com (mxhub12.corp.emc.com [10.254.92.107]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r5J02bL0004062 for ; Tue, 18 Jun 2013 20:02:37 -0400 Received: from mx15a.corp.emc.com ([169.254.1.184]) by mxhub12.corp.emc.com ([10.254.92.107]) with mapi; Tue, 18 Jun 2013 20:02:36 -0400 From: "Black, David" To: "storm@ietf.org" Date: Tue, 18 Jun 2013 20:02:36 -0400 Thread-Topic: [storm] Working Group Last Call - IP Storage: IPsec Requirements Update for IPsec v3 Thread-Index: Ac5seEbW6YTVKeIwQ4e5vN67Pyl/4AAB6URA Message-ID: <8D3D17ACE214DC429325B2B98F3AE7129826537B@MX15A.corp.emc.com> References: <614F550557B82C44AC27C492ADA391AA0773D280@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <614F550557B82C44AC27C492ADA391AA0773D280@TK5EX14MBXC284.redmond.corp.microsoft.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-EMM-MHVC: 1 Subject: Re: [storm] Working Group Last Call - IP Storage: IPsec Requirements Update for IPsec v3 X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 00:03:15 -0000 FYI - The following two typos are already fixed in my working version that will become the -02: Section 2.2, next to last line on page: "birthday" -> "birthday" Section 3.2, third paragraph, first line: "that that" -> "that" Thanks, --David > -----Original Message----- > From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf Of= Tom > Talpey > Sent: Tuesday, June 18, 2013 7:30 PM > To: storm@ietf.org > Subject: [storm] Working Group Last Call - IP Storage: IPsec Requirements > Update for IPsec v3 > Importance: High >=20 > This message is to announce the STORM working group Last Call on the foll= owing > document: >=20 > IP Storage: IPsec Requirements Update for IPsec v3 > http://www.ietf.org/internet-drafts/draft-ietf-storm-ipsec-ips-update-01.= txt >=20 > This new document is created to align IP Storage IPsec profiles with IPse= c-v3 > requirements. The iSCSI consolidated draft and also the iSER draft will m= ake > normative references to this new document, therefore it is desirable to m= ove > it into the publication pipeline promptly, to unblock these other drafts. >=20 > Last Call comments are due by Wednesday, July 3 at midnight Eastern time = (two > weeks from today). >=20 > Please send all technical comments to the storm mailing list: storm@ietf.= org . > Editorial comments may be sent directly to the draft authors: draft-ietf- > storm-ipsec-ips-update@tools.ietf.org . >=20 > Tom Talpey > STORM WG co-chair >=20 > _______________________________________________ > storm mailing list > storm@ietf.org > https://www.ietf.org/mailman/listinfo/storm From roweber@ieee.org Wed Jun 19 02:51:36 2013 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 170F821F9F8D for ; Wed, 19 Jun 2013 02:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id trfz1-VbsAqT for ; Wed, 19 Jun 2013 02:51:31 -0700 (PDT) Received: from vms173021pub.verizon.net (vms173021pub.verizon.net [206.46.173.21]) by ietfa.amsl.com (Postfix) with ESMTP id 6543121F9F88 for ; Wed, 19 Jun 2013 02:51:31 -0700 (PDT) Received: from [198.18.74.134] ([unknown] [12.23.99.130]) by vms173021.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0MOM006HWWPUYD00@vms173021.mailsrvcs.net> for storm@ietf.org; Wed, 19 Jun 2013 04:51:30 -0500 (CDT) Message-id: <51C17F29.1000909@ieee.org> Date: Wed, 19 Jun 2013 04:51:37 -0500 From: Ralph Weber User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-version: 1.0 To: storm@ietf.org References: <614F550557B82C44AC27C492ADA391AA0773D280@TK5EX14MBXC284.redmond.corp.microsoft.com> <8D3D17ACE214DC429325B2B98F3AE7129826537B@MX15A.corp.emc.com> In-reply-to: <8D3D17ACE214DC429325B2B98F3AE7129826537B@MX15A.corp.emc.com> Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit Subject: Re: [storm] Working Group Last Call - IP Storage: IPsec Requirements Update for IPsec v3 X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 09:51:36 -0000 Pardon my dyslexia, if applicable, but what exactly is the change in 2.2? All the best, .Ralph On 6/18/2013 7:02 PM, Black, David wrote: > FYI - The following two typos are already fixed in my working version > that will become the -02: > > Section 2.2, next to last line on page: "birthday" -> "birthday" > > Section 3.2, third paragraph, first line: "that that" -> "that" > > Thanks, > --David > >> -----Original Message----- >> From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf Of Tom >> Talpey >> Sent: Tuesday, June 18, 2013 7:30 PM >> To: storm@ietf.org >> Subject: [storm] Working Group Last Call - IP Storage: IPsec Requirements >> Update for IPsec v3 >> Importance: High >> >> This message is to announce the STORM working group Last Call on the following >> document: >> >> IP Storage: IPsec Requirements Update for IPsec v3 >> http://www.ietf.org/internet-drafts/draft-ietf-storm-ipsec-ips-update-01.txt >> >> This new document is created to align IP Storage IPsec profiles with IPsec-v3 >> requirements. The iSCSI consolidated draft and also the iSER draft will make >> normative references to this new document, therefore it is desirable to move >> it into the publication pipeline promptly, to unblock these other drafts. >> >> Last Call comments are due by Wednesday, July 3 at midnight Eastern time (two >> weeks from today). >> >> Please send all technical comments to the storm mailing list: storm@ietf.org . >> Editorial comments may be sent directly to the draft authors: draft-ietf- >> storm-ipsec-ips-update@tools.ietf.org . >> >> Tom Talpey >> STORM WG co-chair >> >> _______________________________________________ >> storm mailing list >> storm@ietf.org >> https://www.ietf.org/mailman/listinfo/storm > _______________________________________________ > storm mailing list > storm@ietf.org > https://www.ietf.org/mailman/listinfo/storm > > From david.black@emc.com Wed Jun 19 07:49:40 2013 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A94F721F9CE3 for ; Wed, 19 Jun 2013 07:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GpH1VvqMX7ZQ for ; Wed, 19 Jun 2013 07:49:35 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 261AF21F8F4A for ; Wed, 19 Jun 2013 07:49:30 -0700 (PDT) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r5JEnRIM031144 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Jun 2013 10:49:28 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd04.lss.emc.com [10.254.222.226]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Wed, 19 Jun 2013 10:49:07 -0400 Received: from mxhub33.corp.emc.com (mxhub33.corp.emc.com [10.254.93.81]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r5JEmxZn002973; Wed, 19 Jun 2013 10:49:07 -0400 Received: from mx15a.corp.emc.com ([169.254.1.184]) by mxhub33.corp.emc.com ([::1]) with mapi; Wed, 19 Jun 2013 10:49:04 -0400 From: "Black, David" To: Ralph Weber , "storm@ietf.org" Date: Wed, 19 Jun 2013 10:49:03 -0400 Thread-Topic: [storm] Working Group Last Call - IP Storage: IPsec Requirements Update for IPsec v3 Thread-Index: Ac5s0qCqZm2mv0AIQRGWXFL2Oe74pAAKVUww Message-ID: <8D3D17ACE214DC429325B2B98F3AE7129826546B@MX15A.corp.emc.com> References: <614F550557B82C44AC27C492ADA391AA0773D280@TK5EX14MBXC284.redmond.corp.microsoft.com> <8D3D17ACE214DC429325B2B98F3AE7129826537B@MX15A.corp.emc.com> <51C17F29.1000909@ieee.org> In-Reply-To: <51C17F29.1000909@ieee.org> 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-EMM-MHVC: 1 Subject: Re: [storm] Working Group Last Call - IP Storage: IPsec Requirements Update for IPsec v3 X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 14:49:40 -0000 Groan - spelling correctors strike again ... missed the mistake in the draf= t but corrected it in the email :-). The typo correction will be: Section 2.2, next to last line on page: "birthdaya" -> "birthday" Thanks, --David > -----Original Message----- > From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf Of > Ralph Weber > Sent: Wednesday, June 19, 2013 5:52 AM > To: storm@ietf.org > Subject: Re: [storm] Working Group Last Call - IP Storage: IPsec Requirem= ents > Update for IPsec v3 >=20 > Pardon my dyslexia, if applicable, but what exactly is the change in 2.2? >=20 > All the best, >=20 > .Ralph >=20 > On 6/18/2013 7:02 PM, Black, David wrote: > > FYI - The following two typos are already fixed in my working version > > that will become the -02: > > > > Section 2.2, next to last line on page: "birthday" -> "birthday" > > > > Section 3.2, third paragraph, first line: "that that" -> "that" > > > > Thanks, > > --David > > > >> -----Original Message----- > >> From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf= Of > Tom > >> Talpey > >> Sent: Tuesday, June 18, 2013 7:30 PM > >> To: storm@ietf.org > >> Subject: [storm] Working Group Last Call - IP Storage: IPsec Requireme= nts > >> Update for IPsec v3 > >> Importance: High > >> > >> This message is to announce the STORM working group Last Call on the > following > >> document: > >> > >> IP Storage: IPsec Requirements Update for IPsec v3 > >> http://www.ietf.org/internet-drafts/draft-ietf-storm-ipsec-ips-update- > 01.txt > >> > >> This new document is created to align IP Storage IPsec profiles with I= Psec- > v3 > >> requirements. The iSCSI consolidated draft and also the iSER draft wil= l > make > >> normative references to this new document, therefore it is desirable t= o > move > >> it into the publication pipeline promptly, to unblock these other draf= ts. > >> > >> Last Call comments are due by Wednesday, July 3 at midnight Eastern ti= me > (two > >> weeks from today). > >> > >> Please send all technical comments to the storm mailing list: > storm@ietf.org . > >> Editorial comments may be sent directly to the draft authors: draft-ie= tf- > >> storm-ipsec-ips-update@tools.ietf.org . > >> > >> Tom Talpey > >> STORM WG co-chair > >> > >> _______________________________________________ > >> storm mailing list > >> storm@ietf.org > >> https://www.ietf.org/mailman/listinfo/storm > > _______________________________________________ > > storm mailing list > > storm@ietf.org > > https://www.ietf.org/mailman/listinfo/storm > > > > >=20 > _______________________________________________ > storm mailing list > storm@ietf.org > https://www.ietf.org/mailman/listinfo/storm From internet-drafts@ietf.org Mon Jun 24 09:56:05 2013 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 456C411E8168; Mon, 24 Jun 2013 09:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.547 X-Spam-Level: X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HNPa6dURU0ed; Mon, 24 Jun 2013 09:56:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BCCB01F0D1B; Mon, 24 Jun 2013 09:55:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130624165556.31985.96907.idtracker@ietfa.amsl.com> Date: Mon, 24 Jun 2013 09:55:56 -0700 Cc: storm@ietf.org Subject: [storm] I-D Action: draft-ietf-storm-iscsi-cons-09.txt X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 16:56:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the STORage Maintenance Working Group of the = IETF. Title : iSCSI Protocol (Consolidated) Author(s) : Mallikarjun Chadalapaka Julian Satran Kalman Meth David Black Filename : draft-ietf-storm-iscsi-cons-09.txt Pages : 344 Date : 2013-06-23 Abstract: This document describes a transport protocol for SCSI that works on top of TCP. The iSCSI protocol aims to be fully compliant with the standardized SCSI Architecture Model (SAM-2). RFC 3720 defined the original iSCSI protocol. RFC 3721 discusses iSCSI Naming examples and discovery techniques. Subsequently, RFC 3980 added an additional naming format to iSCSI protocol. RFC 4850 followed up by adding a new public extension key to iSCSI. RFC 5048 offered a number of clarifications and a few improvements and corrections to the original iSCSI protocol. This document obsoletes RFCs 3720, 3980, 4850 and 5048 by consolidating them into a single document and making additional updates to the consolidated specification. This document also updates RFC 3721. The text in this document thus supersedes the text in all the noted RFCs wherever there is a difference in semantics. Note: This version of the draft does not yet incorporate planned resolutions to some Last Call comments regarding Kerberos and IPsec-related security considerations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-storm-iscsi-cons There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-storm-iscsi-cons-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-storm-iscsi-cons-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Internet-Drafts@ietf.org Mon Jun 24 09:57:36 2013 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E697821F9AFA; Mon, 24 Jun 2013 09:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.508 X-Spam-Level: X-Spam-Status: No, score=-102.508 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WrmUgEf7ziMY; Mon, 24 Jun 2013 09:57:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 78F8F11E816F; Mon, 24 Jun 2013 09:57:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130624165723.2401.47332.idtracker@ietfa.amsl.com> Date: Mon, 24 Jun 2013 09:57:23 -0700 Cc: storm@ietf.org Subject: [storm] I-D ACTION:draft-ietf-storm-iscsi-cons-09.txt X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 16:57:36 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the STORage Maintenance Working Group of the IETF. Title : iSCSI Protocol (Consolidated) Author(s) : M. Chadalapaka, et al Filename : draft-ietf-storm-iscsi-cons Pages : 344 Date : June 24, 2013 This document describes a transport protocol for SCSI that works on top of TCP. The iSCSI protocol aims to be fully compliant with the standardized SCSI Architecture Model (SAM-2). RFC 3720 defined the original iSCSI protocol. RFC 3721 discusses iSCSI Naming examples and discovery techniques. Subsequently, RFC 3980 added an additional naming format to iSCSI protocol. RFC 4850 followed up by adding a new public extension key to iSCSI. RFC 5048 offered a number of clarifications and a few improvements and corrections to the original iSCSI protocol. This document obsoletes RFCs 3720, 3980, 4850 and 5048 by consolidating them into a single document and making additional updates to the consolidated specification. This document also updates RFC 3721. The text in this document thus supersedes the text in all the noted RFCs wherever there is a difference in semantics. Note: This version of the draft does not yet incorporate planned resolutions to some Last Call comments regarding Kerberos and IPsec-related security considerations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-storm-iscsi-cons-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-storm-iscsi-cons"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2013-06-24095722.I-D@ietf.org> --NextPart-- From internet-drafts@ietf.org Mon Jun 24 12:03:57 2013 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9B4821E816D; Mon, 24 Jun 2013 12:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.526 X-Spam-Level: X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a6wiMIl-D3Fl; Mon, 24 Jun 2013 12:03:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF0F21E815B; Mon, 24 Jun 2013 12:03:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130624190357.31902.11106.idtracker@ietfa.amsl.com> Date: Mon, 24 Jun 2013 12:03:57 -0700 Cc: storm@ietf.org Subject: [storm] I-D Action: draft-ietf-storm-iscsi-sam-07.txt X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 19:03:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the STORage Maintenance Working Group of the = IETF. Title : Internet Small Computer Systems Interface (iSCSI) SCSI F= eatures Update Author(s) : Frederick Knight Mallikarjun Chadalapaka Filename : draft-ietf-storm-iscsi-sam-07.txt Pages : 1 Date : 2013-06-24 Abstract: Internet Small Computer Systems Interface (iSCSI) is a SCSI transport protocol that maps the SCSI family of protocols onto TCP/IP. The iSCSI protocol as specified in [draft-ietf-storm- iscsi-cons-xx] (and as previously specified by the combination of RFC 3720 and RFC 5048) is based on the SAM-2 (SCSI Architecture Model - 2) version of the SCSI family of protocols. This document defines enhancements to the iSCSI protocol to support certain additional features of the SCSI protocol that were defined in SAM-3, SAM-4, and SAM-5. This document is a companion document to [draft-ietf-storm- iscsi-cons-xx]. -------------------------------------------------------- RFC EDITORS NOTE: The above references to [draft-ietf-storm- iscsi-cons-xx] should reference the RFC number assigned to that document, and this note should be removed. -------------------------------------------------------- The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-storm-iscsi-sam There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-storm-iscsi-sam-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-storm-iscsi-sam-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From david.black@emc.com Wed Jun 26 08:31:51 2013 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1806B21F9943 for ; Wed, 26 Jun 2013 08:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2XvOPwXCuB6J for ; Wed, 26 Jun 2013 08:31:47 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 734B221F96E9 for ; Wed, 26 Jun 2013 08:31:44 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r5QFVhKB006230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 26 Jun 2013 11:31:43 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd06.lss.emc.com [10.254.222.130]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor) for ; Wed, 26 Jun 2013 11:31:37 -0400 Received: from mxhub18.corp.emc.com (mxhub18.corp.emc.com [10.254.93.47]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r5QFVaX3003282 for ; Wed, 26 Jun 2013 11:31:37 -0400 Received: from mx15a.corp.emc.com ([169.254.1.184]) by mxhub18.corp.emc.com ([10.254.93.47]) with mapi; Wed, 26 Jun 2013 11:31:36 -0400 From: "Black, David" To: "storm@ietf.org" Importance: high X-Priority: 1 Date: Wed, 26 Jun 2013 11:31:35 -0400 Thread-Topic: Working Group Last Call - Internet Small Computer Systems Interface (iSCSI) SCSI Features Update Thread-Index: Ac5ygj3sWxaWDkFoRoC9kV90iexXtw== Message-ID: <8D3D17ACE214DC429325B2B98F3AE71298332AE9@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: [storm] Working Group Last Call - Internet Small Computer Systems Interface (iSCSI) SCSI Features Update X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 15:31:51 -0000 This message is to announce the STORM working group Last Call on the follow= ing document: Internet Small Computer Systems Interface (iSCSI) SCSI Features Update draft-ietf-storm-iscsi-sam-07.txt https://datatracker.ietf.org/doc/draft-ietf-storm-iscsi-sam/ This document defines enhancements to the iSCSI protocol to support certain= additional features of the SCSI protocol that were defined in SAM-3, SAM-4, and SAM-5. This document is a = companion document to [draft-ietf-storm-iscsi-cons-xx]. Last Call comments are due by Wednesday, July 10 at midnight Eastern time (= two weeks from today). With luck, that'll leave just enough time to get a = revised version of the draft submitted before the July 15th cutoff for the = Berlin meetings. Please send all technical comments to the storm mailing list: storm@ietf.or= g . Editorial comments may be sent directly to the draft authors: draft-ietf-st= orm-iscsi-sam@tools.ietf.org . The primary purpose of this second WG Last Call is to review the specificat= ion of the iSCSIProtocolLevel key and related behavior. I can already see = that some changes will be needed, as the new IANA registry for the values o= f that key has to be expanded to include a description string, so that we c= an put the magic words "no version claimed" into that new registry for the = value. This is necessary in order to use the values of that key in constru= cting version descriptor values for iSCSI in SCSI standard inquiry data (se= e subclause 6.6.2 of the current working draft revision of SPC-4). The diff of the current -07 version of this draft against the -06 version i= s not easy to work with. If I can find the time next week, I'll try to pos= t a diff against a reformatted -06 version that removes a lot of difference= s caused by text movement. -- David Black STORM WG co-chair ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- From ttalpey@microsoft.com Wed Jun 26 14:11:48 2013 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A6FF21F9B16 for ; Wed, 26 Jun 2013 14:11:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rTVwoxF+vR+z for ; Wed, 26 Jun 2013 14:11:41 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0236.outbound.protection.outlook.com [207.46.163.236]) by ietfa.amsl.com (Postfix) with ESMTP id CA86921F9978 for ; Wed, 26 Jun 2013 14:11:35 -0700 (PDT) Received: from BN1AFFO11FD016.protection.gbl (10.58.52.204) by BN1BFFO11HUB024.protection.gbl (10.58.53.134) with Microsoft SMTP Server (TLS) id 15.0.707.0; Wed, 26 Jun 2013 21:11:32 +0000 Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.37) by BN1AFFO11FD016.mail.protection.outlook.com (10.58.52.76) with Microsoft SMTP Server (TLS) id 15.0.707.0 via Frontend Transport; Wed, 26 Jun 2013 21:11:32 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.79]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.03.0136.001; Wed, 26 Jun 2013 21:11:29 +0000 From: Tom Talpey To: "storm@ietf.org" , "david.black@emc.com" , "Paul_Koning@Dell.com" Thread-Topic: Comments on draft-ietf-storm-ipsec-ips-update Thread-Index: Ac5yqwuewpr4eeBIT2quJXY1BPmnxA== Date: Wed, 26 Jun 2013 21:11:29 +0000 Message-ID: <614F550557B82C44AC27C492ADA391AA0774F9A0@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(189002)(47776003)(20776003)(81542001)(47446002)(53806001)(76796001)(50466002)(59766001)(46102001)(31966008)(79102001)(77096001)(76482001)(56776001)(16406001)(54316002)(74366001)(76786001)(51856001)(33656001)(46406003)(54356001)(77982001)(56816003)(6806003)(81342001)(47736001)(63696002)(23726002)(65816001)(47976001)(74662001)(69226001)(74502001)(76176001)(50986001)(49866001)(4396001)(74706001)(66066001)(74876001)(55846006)(80022001); DIR:OUT; SFP:; SCL:1; SRVR:BN1BFFO11HUB024; H:TK5EX14HUBC103.redmond.corp.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 08897B549D Subject: [storm] Comments on draft-ietf-storm-ipsec-ips-update X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 21:11:48 -0000 I have the following comments from a review of the latest draft. 1) In section 1 Introduction, the term "IP Storage protocols" is not define= d. For example, it's not clear whether NFS or SMB are intended to fall unde= r this scope. And the document later refers to the various iWARP specificat= ions, which are not limited to transporting storage. Assuming that's not th= e intent, I suggest defining the term, or restating it more generically. Te= chnically speaking, this comment applies to the title of the document as we= ll. =20 2) In section 1 Introduction, the text in the following sentence is vague: ... IP storage protocols can be expected to operate at high data rates (multiple Gigabits/second); the requirements in this document are strongly influenced by that expectation, and hence may not be appropriate for use of IPsec with other protocols that do not operate at high data rates. It's not clear what requirements may not be appropriate, and why. Indeed, l= ater discussion makes specific requirements for >1Gb, and is silent on lowe= r speed. If the requirements are not applicable in some cases, the cases sh= ould be named. Perhaps simply dropping the entire parenthetical statement "...and hence ma= y not...high data rates". 3) In section 1.2 Updated RFCs, the word "update" appears but it's not clea= r what is updated in the many affected documents. Are there any required ch= anges, outside of extending their RFC3723 references? And presumably, it is= not the intention to retroactively make these requirements, therefore any = existing RFC3723-compliant security approach remains intact? Perhaps the s= tatement would be more accurately "provides updated reference guidance for = IPsec security requirements beyond those of RFC3723." The requirements for IPsec usage with IP storage in RFC 3723 are used by a number of protocols. For that reason, beyond updating RFC 3723, this document also updates the IPsec requirements for each protocol specification that uses RFC 3723, i.e., the following RFCs in addition to RFC 3723: =20 4) [editorial] In section 2.2 the word "astronomical" is unnecessary and sh= ould be deleted. Is there a reference for the 2^69 birthday bound of AES bl= ocks? Point the discussion there. 3GB on a multi-gigabit/sec link. In contrast, AES has a 128 bit block size, which results in an astronomical birthdaya bound (2^69 bytes). AES CBC is the primary mandatory-to-implement cryptographic The word "may" in the relevant requirement is not in RFC2119 form: o Implementations that support IKEv2 SHOULD also implement AES GCM with 128-bit keys; other key sizes may be supported. 5) Also in section 2.2, the following requirement is unclear whether AES in= CBC mode MUST be supported, or whether any use of AES in CBC mode MUST be = implemented with a specific minimum key size. It seems the statement is "AE= S in CBC mode SHOULD be supported, with keys that MUST be at least 128 bits= in length." Correct? o AES in CBC mode MUST be implemented with 128-bit keys; other key sizes MAY be supported, and 6) Finally, in section 2.2 there is a new MUST requirement. This would appe= ar to introduce an incompatibility with RFC 3723. Is it a SHOULD? In addition, NULL encryption [RFC2410] MUST be implemented to enable use of SAs that provide data origin authentication and data integrity, but not confidentiality. Other transforms MAY be implemented in addition to those listed above. From david.black@emc.com Wed Jun 26 22:42:17 2013 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F1FA21F921F for ; Wed, 26 Jun 2013 22:42:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.3 X-Spam-Level: X-Spam-Status: No, score=-101.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t1AbtV+z2XFY for ; Wed, 26 Jun 2013 22:42:11 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 1A37C21F9301 for ; Wed, 26 Jun 2013 22:42:07 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r5R5ffDG008775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Jun 2013 01:41:41 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd04.lss.emc.com [10.254.222.226]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Thu, 27 Jun 2013 01:41:21 -0400 Received: from mxhub13.corp.emc.com (mxhub13.corp.emc.com [128.222.70.234]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r5R5fKYg007983; Thu, 27 Jun 2013 01:41:20 -0400 Received: from mx15a.corp.emc.com ([169.254.1.184]) by mxhub13.corp.emc.com ([128.222.70.234]) with mapi; Thu, 27 Jun 2013 01:41:20 -0400 From: "Black, David" To: Tom Talpey , "storm@ietf.org" , "Paul_Koning@Dell.com" Date: Thu, 27 Jun 2013 01:41:19 -0400 Thread-Topic: Comments on draft-ietf-storm-ipsec-ips-update Thread-Index: Ac5yqwuewpr4eeBIT2quJXY1BPmnxAASCVKw Message-ID: <8D3D17ACE214DC429325B2B98F3AE71298332C1E@MX15A.corp.emc.com> References: <614F550557B82C44AC27C492ADA391AA0774F9A0@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <614F550557B82C44AC27C492ADA391AA0774F9A0@TK5EX14MBXC284.redmond.corp.microsoft.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-EMM-MHVC: 1 Subject: Re: [storm] Comments on draft-ietf-storm-ipsec-ips-update X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 05:42:17 -0000 Tom, Thanks for the thorough review. Most of this is editorial - the one item that is a technical issue is that the encryption algorithm requirement changes may not be backwards compatibl= e, as 3DES is no longer appropriate for this use; AES CBC is the new mandatory to implement encryption algorithm in this draft. I could leave 3DES as mandatory to implement for backwards compatibility if that helps, but AES C= BC really has to be mandatory to implement due to the problems w/3DES at high data rates. If both AES CBC and 3DES are supported, AES CBC SHOULD be used in preference to 3DES. > 1) In section 1 Introduction, the term "IP Storage protocols" is not defi= ned. > For example, it's not clear whether NFS or SMB are intended to fall under= this > scope. And the document later refers to the various iWARP specifications, > which are not limited to transporting storage. Assuming that's not the in= tent, > I suggest defining the term, or restating it more generically. Technicall= y > speaking, this comment applies to the title of the document as well. I took another look at RFC 3723 - it's entitled "Securing Block Storage Protocols over IP" although, as you point out, its IPsec requirements have been applied to iWARP. I've referred to these requirements as the IP Stora= ge IPsec requirements, in part due to the name of the working group that devel= oped them. The draft title might be better restated to reference RFC 3723, and = I'll see about changing the text from use of "IP Storage protocols" to talking about protocols that use the RFC 3723 IPsec requirements. The first paragr= aph of the introduction will need to be expanded to explain this. > 2) In section 1 Introduction, the text in the following sentence is vague= : >=20 > ... IP storage protocols can > be expected to operate at high data rates (multiple Gigabits/second); > the requirements in this document are strongly influenced by that > expectation, and hence may not be appropriate for use of IPsec with > other protocols that do not operate at high data rates. >=20 > It's not clear what requirements may not be appropriate, and why. Indeed, > later discussion makes specific requirements for >1Gb, and is silent on l= ower > speed. If the requirements are not applicable in some cases, the cases sh= ould > be named. >=20 > Perhaps simply dropping the entire parenthetical statement "...and hence = may > not...high data rates". Sure. > 3) In section 1.2 Updated RFCs, the word "update" appears but it's not cl= ear > what is updated in the many affected documents. Are there any required > changes, outside of extending their RFC3723 references? Section 1.2 says that it "updates the IPsec requirements for each protocol specification that uses RFC 3723" I think that sufficiently defines the sc= ope. > And presumably, it is > not the intention to retroactively make these requirements, therefore any > existing RFC3723-compliant security approach remains intact? =20 Actually, that is the intention, particularly the 3DES to AES CBC change in mandatory encryption algorithm due to birthday problems with 3DES at high d= ata rates. Older implementations may still claim compliance to RFC 3723 prior = to this update, but the intent of this update is to move away from 3DES in all cases. > 4) [editorial] In section 2.2 the word "astronomical" is unnecessary and > should be deleted Ok. > Is there a reference for the 2^69 birthday bound of AES > blocks? Point the discussion there. The birthday bound calculation for AES is in an email message and hence I'll need to reproduce that in an added appendix. > The word "may" in the relevant requirement is not in RFC2119 form: >=20 > o Implementations that support IKEv2 SHOULD also implement AES GCM > with 128-bit keys; other key sizes may be supported Ok. > 5) Also in section 2.2, the following requirement is unclear whether AES = in > CBC mode MUST be supported, or whether any use of AES in CBC mode MUST be > implemented with a specific minimum key size. It seems the statement is "= AES > in CBC mode SHOULD be supported, with keys that MUST be at least 128 bits= in > length." Correct? > > o AES in CBC mode MUST be implemented with 128-bit keys; other key > sizes MAY be supported, and The requirement is basically correct as stated, AES in CBC mode with 128-bi= t keys MUST be supported. Other key sizes for AES in CBC mode are OPTIONAL. I can rephrase in that form if it helps. > 6) Finally, in section 2.2 there is a new MUST requirement. This would ap= pear > to introduce an incompatibility with RFC 3723. Is it a SHOULD? It's not new - the requirement exists in RFC 3723, as the last sentence in section 2.3.1 on Transforms: ESP with NULL encryption MUST be supported for authentication. That is the same requirement expressed in a different fashion. Thanks, --David > -----Original Message----- > From: Tom Talpey [mailto:ttalpey@microsoft.com] > Sent: Wednesday, June 26, 2013 5:11 PM > To: storm@ietf.org; Black, David; Paul_Koning@Dell.com > Subject: Comments on draft-ietf-storm-ipsec-ips-update >=20 > I have the following comments from a review of the latest draft. >=20 >=20 >=20 > 1) In section 1 Introduction, the term "IP Storage protocols" is not defi= ned. > For example, it's not clear whether NFS or SMB are intended to fall under= this > scope. And the document later refers to the various iWARP specifications, > which are not limited to transporting storage. Assuming that's not the in= tent, > I suggest defining the term, or restating it more generically. Technicall= y > speaking, this comment applies to the title of the document as well. >=20 >=20 >=20 > 2) In section 1 Introduction, the text in the following sentence is vague= : >=20 > ... IP storage protocols can > be expected to operate at high data rates (multiple Gigabits/second); > the requirements in this document are strongly influenced by that > expectation, and hence may not be appropriate for use of IPsec with > other protocols that do not operate at high data rates. >=20 > It's not clear what requirements may not be appropriate, and why. Indeed, > later discussion makes specific requirements for >1Gb, and is silent on l= ower > speed. If the requirements are not applicable in some cases, the cases sh= ould > be named. >=20 > Perhaps simply dropping the entire parenthetical statement "...and hence = may > not...high data rates". >=20 >=20 >=20 > 3) In section 1.2 Updated RFCs, the word "update" appears but it's not cl= ear > what is updated in the many affected documents. Are there any required > changes, outside of extending their RFC3723 references? And presumably, i= t is > not the intention to retroactively make these requirements, therefore any > existing RFC3723-compliant security approach remains intact? Perhaps the > statement would be more accurately "provides updated reference guidance f= or > IPsec security requirements beyond those of RFC3723." >=20 > The requirements for IPsec usage with IP storage in RFC 3723 are used > by a number of protocols. For that reason, beyond updating RFC 3723, > this document also updates the IPsec requirements for each protocol > specification that uses RFC 3723, i.e., the following RFCs in > addition to RFC 3723: >=20 >=20 >=20 > 4) [editorial] In section 2.2 the word "astronomical" is unnecessary and > should be deleted. Is there a reference for the 2^69 birthday bound of AE= S > blocks? Point the discussion there. >=20 > 3GB on a multi-gigabit/sec link. In contrast, AES has a 128 bit > block size, which results in an astronomical birthdaya bound (2^69 > bytes). AES CBC is the primary mandatory-to-implement cryptographic >=20 > The word "may" in the relevant requirement is not in RFC2119 form: >=20 > o Implementations that support IKEv2 SHOULD also implement AES GCM > with 128-bit keys; other key sizes may be supported. >=20 >=20 >=20 > 5) Also in section 2.2, the following requirement is unclear whether AES = in > CBC mode MUST be supported, or whether any use of AES in CBC mode MUST be > implemented with a specific minimum key size. It seems the statement is "= AES > in CBC mode SHOULD be supported, with keys that MUST be at least 128 bits= in > length." Correct? >=20 > o AES in CBC mode MUST be implemented with 128-bit keys; other key > sizes MAY be supported, and >=20 >=20 >=20 > 6) Finally, in section 2.2 there is a new MUST requirement. This would ap= pear > to introduce an incompatibility with RFC 3723. Is it a SHOULD? >=20 > In addition, NULL encryption [RFC2410] MUST be implemented to enable > use of SAs that provide data origin authentication and data > integrity, but not confidentiality. Other transforms MAY be > implemented in addition to those listed above. >=20 >=20 From ttalpey@microsoft.com Thu Jun 27 13:37:10 2013 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4577721F9F9E for ; Thu, 27 Jun 2013 13:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id epFiTNwPV2Fb for ; Thu, 27 Jun 2013 13:37:04 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0211.outbound.protection.outlook.com [207.46.163.211]) by ietfa.amsl.com (Postfix) with ESMTP id 88D2B21F9F9F for ; Thu, 27 Jun 2013 13:37:00 -0700 (PDT) Received: from BY2FFO11FD023.protection.gbl (10.1.15.204) by BY2FFO11HUB002.protection.gbl (10.1.14.144) with Microsoft SMTP Server (TLS) id 15.0.717.3; Thu, 27 Jun 2013 20:36:59 +0000 Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD023.mail.protection.outlook.com (10.1.15.212) with Microsoft SMTP Server (TLS) id 15.0.707.0 via Frontend Transport; Thu, 27 Jun 2013 20:36:58 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.79]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.03.0136.001; Thu, 27 Jun 2013 20:36:49 +0000 From: Tom Talpey To: "Black, David" , "storm@ietf.org" , "Paul_Koning@Dell.com" Thread-Topic: Comments on draft-ietf-storm-ipsec-ips-update Thread-Index: Ac5yqwuewpr4eeBIT2quJXY1BPmnxAASCVKwABICU1A= Date: Thu, 27 Jun 2013 20:36:49 +0000 Message-ID: <614F550557B82C44AC27C492ADA391AA07750ACC@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <614F550557B82C44AC27C492ADA391AA0774F9A0@TK5EX14MBXC284.redmond.corp.microsoft.com> <8D3D17ACE214DC429325B2B98F3AE71298332C1E@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71298332C1E@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(51704005)(51914003)(377454003)(189002)(199002)(13464003)(164054003)(51444003)(69226001)(59766001)(55846006)(54316002)(81542001)(81342001)(79102001)(74876001)(74366001)(74662001)(31966008)(56816003)(50466002)(77096001)(54356001)(77982001)(56776001)(76482001)(74502001)(76796001)(46102001)(76786001)(44976004)(51856001)(47446002)(74706001)(53806001)(47736001)(49866001)(46406003)(47976001)(50986001)(23726002)(65816001)(63696002)(20776003)(47776003)(6806003)(33656001)(4396001)(16406001)(66066001)(80022001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB002; H:TK5EX14HUBC105.redmond.corp.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 08902E536D Subject: Re: [storm] Comments on draft-ietf-storm-ipsec-ips-update X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 20:37:10 -0000 > ... I could leave > 3DES as mandatory to implement for backwards compatibility if that helps, > but AES CBC really has to be mandatory to implement due to the problems > w/3DES at high data rates. If both AES CBC and 3DES are supported, AES C= BC > SHOULD be used in preference to 3DES. I'm ok with this, as long as these requirements are clearly stated. Any 3DE= S support seems to me an implementation choice - a target could validly ref= use to do so based on data privacy requirements. So I would agree it is not= a MUST. > that developed them. The draft title might be better restated to referen= ce > RFC 3723, and I'll see about changing the text from use of "IP Storage > protocols" to talking about protocols that use the RFC 3723 IPsec > requirements. The first paragraph of the introduction will need to be > expanded to explain this. Sounds good, I'll look for the new proposed text. > > 3) In section 1.2 Updated RFCs, the word "update" appears but it's not > > clear what is updated in the many affected documents. Are there any > > required changes, outside of extending their RFC3723 references? >=20 > Section 1.2 says that it "updates the IPsec requirements for each protoco= l > specification that uses RFC 3723" I think that sufficiently defines the = scope. Well, at least I was confused. Consider the reader of one of the original d= ocuments, who might follow the RFC3723 reference and be redirected to this = new document. How would they read "updates"? It could mean "replaces" or "a= dds", and the difference will be important to an implementation. The text s= hould strive for clarity. > Actually, that is the intention, particularly the 3DES to AES CBC change = in > mandatory encryption algorithm due to birthday problems with 3DES at high > data rates. Older implementations may still claim compliance to RFC 3723 > prior to this update, but the intent of this update is to move away from = 3DES > in all cases. Absolutely. As long as it is clear that this document deprecates 3DES. > The birthday bound calculation for AES is in an email message and hence I= 'll > need to reproduce that in an added appendix. I guess that would help. I'd be ok with a milder statement which leaves bir= thday bounds to other documents. Surely, storage is not the only upper laye= r which seeks to protect its messages at high data rates, so others may hav= e discussed? > The requirement is basically correct as stated, AES in CBC mode with 128-= bit > keys MUST be supported. Other key sizes for AES in CBC mode are > OPTIONAL. > I can rephrase in that form if it helps. I think that would clarify the intent, yes. If you choose OPTIONAL, note th= at there are other places in the document which refer to key size. And, ins= tead of "other", would "longer" be better guidance? > It's not new - the requirement exists in RFC 3723, as the last sentence i= n > section 2.3.1 on Transforms: >=20 > ESP with NULL encryption MUST be supported for authentication. >=20 > That is the same requirement expressed in a different fashion. Ah, ok. The text immediately prior to this paragraph reads "In addition", w= hich makes it appear to be a new requirement as are the others. Stating tha= t it is an existing requirement of RFC3723 would suffice. Tom. > -----Original Message----- > From: Black, David [mailto:david.black@emc.com] > Sent: Thursday, June 27, 2013 1:41 AM > To: Tom Talpey; storm@ietf.org; Paul_Koning@Dell.com > Subject: RE: Comments on draft-ietf-storm-ipsec-ips-update >=20 > Tom, >=20 > Thanks for the thorough review. >=20 > Most of this is editorial - the one item that is a technical issue is tha= t the > encryption algorithm requirement changes may not be backwards > compatible, as 3DES is no longer appropriate for this use; AES CBC is the= new > mandatory to implement encryption algorithm in this draft. I could leave > 3DES as mandatory to implement for backwards compatibility if that helps, > but AES CBC really has to be mandatory to implement due to the problems > w/3DES at high data rates. If both AES CBC and 3DES are supported, AES C= BC > SHOULD be used in preference to 3DES. >=20 > > 1) In section 1 Introduction, the term "IP Storage protocols" is not de= fined. > > For example, it's not clear whether NFS or SMB are intended to fall > > under this scope. And the document later refers to the various iWARP > > specifications, which are not limited to transporting storage. > > Assuming that's not the intent, I suggest defining the term, or > > restating it more generically. Technically speaking, this comment appli= es to > the title of the document as well. >=20 > I took another look at RFC 3723 - it's entitled "Securing Block Storage > Protocols over IP" although, as you point out, its IPsec requirements hav= e > been applied to iWARP. I've referred to these requirements as the IP > Storage IPsec requirements, in part due to the name of the working group > that developed them. The draft title might be better restated to referen= ce > RFC 3723, and I'll see about changing the text from use of "IP Storage > protocols" to talking about protocols that use the RFC 3723 IPsec > requirements. The first paragraph of the introduction will need to be > expanded to explain this. >=20 > > 2) In section 1 Introduction, the text in the following sentence is vag= ue: > > > > ... IP storage protocols can > > be expected to operate at high data rates (multiple Gigabits/second)= ; > > the requirements in this document are strongly influenced by that > > expectation, and hence may not be appropriate for use of IPsec with > > other protocols that do not operate at high data rates. > > > > It's not clear what requirements may not be appropriate, and why. > > Indeed, later discussion makes specific requirements for >1Gb, and is > > silent on lower speed. If the requirements are not applicable in some > > cases, the cases should be named. > > > > Perhaps simply dropping the entire parenthetical statement "...and > > hence may not...high data rates". >=20 > Sure. >=20 > > 3) In section 1.2 Updated RFCs, the word "update" appears but it's not > > clear what is updated in the many affected documents. Are there any > > required changes, outside of extending their RFC3723 references? >=20 > Section 1.2 says that it "updates the IPsec requirements for each protoco= l > specification that uses RFC 3723" I think that sufficiently defines the = scope. >=20 > > And presumably, it is > > not the intention to retroactively make these requirements, therefore > > any existing RFC3723-compliant security approach remains intact? >=20 > Actually, that is the intention, particularly the 3DES to AES CBC change = in > mandatory encryption algorithm due to birthday problems with 3DES at high > data rates. Older implementations may still claim compliance to RFC 3723 > prior to this update, but the intent of this update is to move away from = 3DES > in all cases. >=20 > > 4) [editorial] In section 2.2 the word "astronomical" is unnecessary > > and should be deleted >=20 > Ok. >=20 > > Is there a reference for the 2^69 birthday bound of AES blocks? Point > > the discussion there. >=20 > The birthday bound calculation for AES is in an email message and hence I= 'll > need to reproduce that in an added appendix. >=20 > > The word "may" in the relevant requirement is not in RFC2119 form: > > > > o Implementations that support IKEv2 SHOULD also implement AES GCM > > with 128-bit keys; other key sizes may be supported >=20 > Ok. >=20 > > 5) Also in section 2.2, the following requirement is unclear whether > > AES in CBC mode MUST be supported, or whether any use of AES in CBC > > mode MUST be implemented with a specific minimum key size. It seems > > the statement is "AES in CBC mode SHOULD be supported, with keys that > > MUST be at least 128 bits in length." Correct? > > > > o AES in CBC mode MUST be implemented with 128-bit keys; other key > > sizes MAY be supported, and >=20 > The requirement is basically correct as stated, AES in CBC mode with 128-= bit > keys MUST be supported. Other key sizes for AES in CBC mode are > OPTIONAL. > I can rephrase in that form if it helps. >=20 > > 6) Finally, in section 2.2 there is a new MUST requirement. This would > > appear to introduce an incompatibility with RFC 3723. Is it a SHOULD? >=20 > It's not new - the requirement exists in RFC 3723, as the last sentence i= n > section 2.3.1 on Transforms: >=20 > ESP with NULL encryption MUST be supported for authentication. >=20 > That is the same requirement expressed in a different fashion. >=20 > Thanks, > --David >=20 >=20 > > -----Original Message----- > > From: Tom Talpey [mailto:ttalpey@microsoft.com] > > Sent: Wednesday, June 26, 2013 5:11 PM > > To: storm@ietf.org; Black, David; Paul_Koning@Dell.com > > Subject: Comments on draft-ietf-storm-ipsec-ips-update > > > > I have the following comments from a review of the latest draft. > > > > > > > > 1) In section 1 Introduction, the term "IP Storage protocols" is not de= fined. > > For example, it's not clear whether NFS or SMB are intended to fall > > under this scope. And the document later refers to the various iWARP > > specifications, which are not limited to transporting storage. > > Assuming that's not the intent, I suggest defining the term, or > > restating it more generically. Technically speaking, this comment appli= es to > the title of the document as well. > > > > > > > > 2) In section 1 Introduction, the text in the following sentence is vag= ue: > > > > ... IP storage protocols can > > be expected to operate at high data rates (multiple Gigabits/second)= ; > > the requirements in this document are strongly influenced by that > > expectation, and hence may not be appropriate for use of IPsec with > > other protocols that do not operate at high data rates. > > > > It's not clear what requirements may not be appropriate, and why. > > Indeed, later discussion makes specific requirements for >1Gb, and is > > silent on lower speed. If the requirements are not applicable in some > > cases, the cases should be named. > > > > Perhaps simply dropping the entire parenthetical statement "...and > > hence may not...high data rates". > > > > > > > > 3) In section 1.2 Updated RFCs, the word "update" appears but it's not > > clear what is updated in the many affected documents. Are there any > > required changes, outside of extending their RFC3723 references? And > > presumably, it is not the intention to retroactively make these > > requirements, therefore any existing RFC3723-compliant security > > approach remains intact? Perhaps the statement would be more > > accurately "provides updated reference guidance for IPsec security > requirements beyond those of RFC3723." > > > > The requirements for IPsec usage with IP storage in RFC 3723 are use= d > > by a number of protocols. For that reason, beyond updating RFC 3723= , > > this document also updates the IPsec requirements for each protocol > > specification that uses RFC 3723, i.e., the following RFCs in > > addition to RFC 3723: > > > > > > > > 4) [editorial] In section 2.2 the word "astronomical" is unnecessary > > and should be deleted. Is there a reference for the 2^69 birthday > > bound of AES blocks? Point the discussion there. > > > > 3GB on a multi-gigabit/sec link. In contrast, AES has a 128 bit > > block size, which results in an astronomical birthdaya bound (2^69 > > bytes). AES CBC is the primary mandatory-to-implement > > cryptographic > > > > The word "may" in the relevant requirement is not in RFC2119 form: > > > > o Implementations that support IKEv2 SHOULD also implement AES GCM > > with 128-bit keys; other key sizes may be supported. > > > > > > > > 5) Also in section 2.2, the following requirement is unclear whether > > AES in CBC mode MUST be supported, or whether any use of AES in CBC > > mode MUST be implemented with a specific minimum key size. It seems > > the statement is "AES in CBC mode SHOULD be supported, with keys that > > MUST be at least 128 bits in length." Correct? > > > > o AES in CBC mode MUST be implemented with 128-bit keys; other key > > sizes MAY be supported, and > > > > > > > > 6) Finally, in section 2.2 there is a new MUST requirement. This would > > appear to introduce an incompatibility with RFC 3723. Is it a SHOULD? > > > > In addition, NULL encryption [RFC2410] MUST be implemented to enable > > use of SAs that provide data origin authentication and data > > integrity, but not confidentiality. Other transforms MAY be > > implemented in addition to those listed above. > > > > From david.black@emc.com Thu Jun 27 21:54:44 2013 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11AAD21F9C13 for ; Thu, 27 Jun 2013 21:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SsApjL2UmKHR for ; Thu, 27 Jun 2013 21:54:38 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 42DFE21F9B35 for ; Thu, 27 Jun 2013 21:54:35 -0700 (PDT) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r5S4sVAH012754 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Jun 2013 00:54:33 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd06.lss.emc.com [10.254.222.130]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Fri, 28 Jun 2013 00:54:12 -0400 Received: from mxhub13.corp.emc.com (mxhub13.corp.emc.com [128.222.70.234]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r5S4sCCm029029; Fri, 28 Jun 2013 00:54:12 -0400 Received: from mx15a.corp.emc.com ([169.254.1.184]) by mxhub13.corp.emc.com ([128.222.70.234]) with mapi; Fri, 28 Jun 2013 00:54:11 -0400 From: "Black, David" To: Tom Talpey , "storm@ietf.org" , "Paul_Koning@Dell.com" Date: Fri, 28 Jun 2013 00:54:09 -0400 Thread-Topic: Comments on draft-ietf-storm-ipsec-ips-update Thread-Index: Ac5yqwuewpr4eeBIT2quJXY1BPmnxAASCVKwABICU1AAH1Nd4A== Message-ID: <8D3D17ACE214DC429325B2B98F3AE71298332DB8@MX15A.corp.emc.com> References: <614F550557B82C44AC27C492ADA391AA0774F9A0@TK5EX14MBXC284.redmond.corp.microsoft.com> <8D3D17ACE214DC429325B2B98F3AE71298332C1E@MX15A.corp.emc.com> <614F550557B82C44AC27C492ADA391AA07750ACC@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <614F550557B82C44AC27C492ADA391AA07750ACC@TK5EX14MBXC284.redmond.corp.microsoft.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-EMM-MHVC: 1 Subject: Re: [storm] Comments on draft-ietf-storm-ipsec-ips-update X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 04:54:44 -0000 Inline ... Thanks, --David > -----Original Message----- > From: Tom Talpey [mailto:ttalpey@microsoft.com] > Sent: Thursday, June 27, 2013 4:37 PM > To: Black, David; storm@ietf.org; Paul_Koning@Dell.com > Subject: RE: Comments on draft-ietf-storm-ipsec-ips-update >=20 > > ... I could leave > > 3DES as mandatory to implement for backwards compatibility if that help= s, > > but AES CBC really has to be mandatory to implement due to the problems > > w/3DES at high data rates. If both AES CBC and 3DES are supported, AES= CBC > > SHOULD be used in preference to 3DES. >=20 > I'm ok with this, as long as these requirements are clearly stated. Any 3= DES > support seems to me an implementation choice - a target could validly ref= use > to do so based on data privacy requirements. So I would agree it is not a > MUST. Good - in that case, I'll leave the requirements as they are - the birthday effects on 3DES justify it becoming a MAY, with AES CBC as the new MUST. I= 'll add the "SHOULD be used in preference" sentence. > > that developed them. The draft title might be better restated to refer= ence > > RFC 3723, and I'll see about changing the text from use of "IP Storage > > protocols" to talking about protocols that use the RFC 3723 IPsec > > requirements. The first paragraph of the introduction will need to be > > expanded to explain this. >=20 > Sounds good, I'll look for the new proposed text. >=20 > > > 3) In section 1.2 Updated RFCs, the word "update" appears but it's no= t > > > clear what is updated in the many affected documents. Are there any > > > required changes, outside of extending their RFC3723 references? > > > > Section 1.2 says that it "updates the IPsec requirements for each proto= col > > specification that uses RFC 3723" I think that sufficiently defines th= e > scope. >=20 > Well, at least I was confused. Consider the reader of one of the original > documents, who might follow the RFC3723 reference and be redirected to th= is > new document. How would they read "updates"? It could mean "replaces" or > "adds", and the difference will be important to an implementation. The te= xt > should strive for clarity. Sections 2 and 3 and their subsections are clear about what's going on, but= the introduction could use a summary of what is extended vs. actually changed t= hat section 1.2 could then refer to (the older IPsec requirements are reproduce= d here so that everything is in one place). I'll do that. =20 > > Actually, that is the intention, particularly the 3DES to AES CBC chang= e in > > mandatory encryption algorithm due to birthday problems with 3DES at hi= gh > > data rates. Older implementations may still claim compliance to RFC 37= 23 > > prior to this update, but the intent of this update is to move away fro= m > 3DES > > in all cases. >=20 > Absolutely. As long as it is clear that this document deprecates 3DES. Ok, I need to add text to say that the MUST for 3DES and the SHOULD for AES CTR have each been replaced by a MAY. =20 > > The birthday bound calculation for AES is in an email message and hence= I'll > > need to reproduce that in an added appendix. >=20 > I guess that would help. I'd be ok with a milder statement which leaves > birthday bounds to other documents. Surely, storage is not the only upper > layer which seeks to protect its messages at high data rates, so others m= ay > have discussed? Nope, have a reference for 3DES birthday bound, but not AES. > > The requirement is basically correct as stated, AES in CBC mode with 12= 8-bit > > keys MUST be supported. Other key sizes for AES in CBC mode are > > OPTIONAL. > > I can rephrase in that form if it helps. >=20 > I think that would clarify the intent, yes. If you choose OPTIONAL, note = that > there are other places in the document which refer to key size. And, inst= ead > of "other", would "longer" be better guidance? >=20 > > It's not new - the requirement exists in RFC 3723, as the last sentence= in > > section 2.3.1 on Transforms: > > > > ESP with NULL encryption MUST be supported for authentication. > > > > That is the same requirement expressed in a different fashion. >=20 > Ah, ok. The text immediately prior to this paragraph reads "In addition", > which makes it appear to be a new requirement as are the others. Stating = that > it is an existing requirement of RFC3723 would suffice. Ah, it's missing from the RFC3723 list at the start of 2.2 - I'll add text = there to make that clear. >=20 > Tom. >=20 >=20 >=20 > > -----Original Message----- > > From: Black, David [mailto:david.black@emc.com] > > Sent: Thursday, June 27, 2013 1:41 AM > > To: Tom Talpey; storm@ietf.org; Paul_Koning@Dell.com > > Subject: RE: Comments on draft-ietf-storm-ipsec-ips-update > > > > Tom, > > > > Thanks for the thorough review. > > > > Most of this is editorial - the one item that is a technical issue is t= hat > the > > encryption algorithm requirement changes may not be backwards > > compatible, as 3DES is no longer appropriate for this use; AES CBC is t= he > new > > mandatory to implement encryption algorithm in this draft. I could lea= ve > > 3DES as mandatory to implement for backwards compatibility if that help= s, > > but AES CBC really has to be mandatory to implement due to the problems > > w/3DES at high data rates. If both AES CBC and 3DES are supported, AES= CBC > > SHOULD be used in preference to 3DES. > > > > > 1) In section 1 Introduction, the term "IP Storage protocols" is not > defined. > > > For example, it's not clear whether NFS or SMB are intended to fall > > > under this scope. And the document later refers to the various iWARP > > > specifications, which are not limited to transporting storage. > > > Assuming that's not the intent, I suggest defining the term, or > > > restating it more generically. Technically speaking, this comment app= lies > to > > the title of the document as well. > > > > I took another look at RFC 3723 - it's entitled "Securing Block Storage > > Protocols over IP" although, as you point out, its IPsec requirements h= ave > > been applied to iWARP. I've referred to these requirements as the IP > > Storage IPsec requirements, in part due to the name of the working grou= p > > that developed them. The draft title might be better restated to refer= ence > > RFC 3723, and I'll see about changing the text from use of "IP Storage > > protocols" to talking about protocols that use the RFC 3723 IPsec > > requirements. The first paragraph of the introduction will need to be > > expanded to explain this. > > > > > 2) In section 1 Introduction, the text in the following sentence is v= ague: > > > > > > ... IP storage protocols can > > > be expected to operate at high data rates (multiple Gigabits/secon= d); > > > the requirements in this document are strongly influenced by that > > > expectation, and hence may not be appropriate for use of IPsec wit= h > > > other protocols that do not operate at high data rates. > > > > > > It's not clear what requirements may not be appropriate, and why. > > > Indeed, later discussion makes specific requirements for >1Gb, and is > > > silent on lower speed. If the requirements are not applicable in some > > > cases, the cases should be named. > > > > > > Perhaps simply dropping the entire parenthetical statement "...and > > > hence may not...high data rates". > > > > Sure. > > > > > 3) In section 1.2 Updated RFCs, the word "update" appears but it's no= t > > > clear what is updated in the many affected documents. Are there any > > > required changes, outside of extending their RFC3723 references? > > > > Section 1.2 says that it "updates the IPsec requirements for each proto= col > > specification that uses RFC 3723" I think that sufficiently defines th= e > scope. > > > > > And presumably, it is > > > not the intention to retroactively make these requirements, therefore > > > any existing RFC3723-compliant security approach remains intact? > > > > Actually, that is the intention, particularly the 3DES to AES CBC chang= e in > > mandatory encryption algorithm due to birthday problems with 3DES at hi= gh > > data rates. Older implementations may still claim compliance to RFC 37= 23 > > prior to this update, but the intent of this update is to move away fro= m > 3DES > > in all cases. > > > > > 4) [editorial] In section 2.2 the word "astronomical" is unnecessary > > > and should be deleted > > > > Ok. > > > > > Is there a reference for the 2^69 birthday bound of AES blocks? Point > > > the discussion there. > > > > The birthday bound calculation for AES is in an email message and hence= I'll > > need to reproduce that in an added appendix. > > > > > The word "may" in the relevant requirement is not in RFC2119 form: > > > > > > o Implementations that support IKEv2 SHOULD also implement AES GC= M > > > with 128-bit keys; other key sizes may be supported > > > > Ok. > > > > > 5) Also in section 2.2, the following requirement is unclear whether > > > AES in CBC mode MUST be supported, or whether any use of AES in CBC > > > mode MUST be implemented with a specific minimum key size. It seems > > > the statement is "AES in CBC mode SHOULD be supported, with keys that > > > MUST be at least 128 bits in length." Correct? > > > > > > o AES in CBC mode MUST be implemented with 128-bit keys; other ke= y > > > sizes MAY be supported, and > > > > The requirement is basically correct as stated, AES in CBC mode with 12= 8-bit > > keys MUST be supported. Other key sizes for AES in CBC mode are > > OPTIONAL. > > I can rephrase in that form if it helps. > > > > > 6) Finally, in section 2.2 there is a new MUST requirement. This woul= d > > > appear to introduce an incompatibility with RFC 3723. Is it a SHOULD? > > > > It's not new - the requirement exists in RFC 3723, as the last sentence= in > > section 2.3.1 on Transforms: > > > > ESP with NULL encryption MUST be supported for authentication. > > > > That is the same requirement expressed in a different fashion. > > > > Thanks, > > --David > > > > > > > -----Original Message----- > > > From: Tom Talpey [mailto:ttalpey@microsoft.com] > > > Sent: Wednesday, June 26, 2013 5:11 PM > > > To: storm@ietf.org; Black, David; Paul_Koning@Dell.com > > > Subject: Comments on draft-ietf-storm-ipsec-ips-update > > > > > > I have the following comments from a review of the latest draft. > > > > > > > > > > > > 1) In section 1 Introduction, the term "IP Storage protocols" is not > defined. > > > For example, it's not clear whether NFS or SMB are intended to fall > > > under this scope. And the document later refers to the various iWARP > > > specifications, which are not limited to transporting storage. > > > Assuming that's not the intent, I suggest defining the term, or > > > restating it more generically. Technically speaking, this comment app= lies > to > > the title of the document as well. > > > > > > > > > > > > 2) In section 1 Introduction, the text in the following sentence is v= ague: > > > > > > ... IP storage protocols can > > > be expected to operate at high data rates (multiple Gigabits/secon= d); > > > the requirements in this document are strongly influenced by that > > > expectation, and hence may not be appropriate for use of IPsec wit= h > > > other protocols that do not operate at high data rates. > > > > > > It's not clear what requirements may not be appropriate, and why. > > > Indeed, later discussion makes specific requirements for >1Gb, and is > > > silent on lower speed. If the requirements are not applicable in some > > > cases, the cases should be named. > > > > > > Perhaps simply dropping the entire parenthetical statement "...and > > > hence may not...high data rates". > > > > > > > > > > > > 3) In section 1.2 Updated RFCs, the word "update" appears but it's no= t > > > clear what is updated in the many affected documents. Are there any > > > required changes, outside of extending their RFC3723 references? And > > > presumably, it is not the intention to retroactively make these > > > requirements, therefore any existing RFC3723-compliant security > > > approach remains intact? Perhaps the statement would be more > > > accurately "provides updated reference guidance for IPsec security > > requirements beyond those of RFC3723." > > > > > > The requirements for IPsec usage with IP storage in RFC 3723 are u= sed > > > by a number of protocols. For that reason, beyond updating RFC 37= 23, > > > this document also updates the IPsec requirements for each protoco= l > > > specification that uses RFC 3723, i.e., the following RFCs in > > > addition to RFC 3723: > > > > > > > > > > > > 4) [editorial] In section 2.2 the word "astronomical" is unnecessary > > > and should be deleted. Is there a reference for the 2^69 birthday > > > bound of AES blocks? Point the discussion there. > > > > > > 3GB on a multi-gigabit/sec link. In contrast, AES has a 128 bit > > > block size, which results in an astronomical birthdaya bound (2^69 > > > bytes). AES CBC is the primary mandatory-to-implement > > > cryptographic > > > > > > The word "may" in the relevant requirement is not in RFC2119 form: > > > > > > o Implementations that support IKEv2 SHOULD also implement AES GC= M > > > with 128-bit keys; other key sizes may be supported. > > > > > > > > > > > > 5) Also in section 2.2, the following requirement is unclear whether > > > AES in CBC mode MUST be supported, or whether any use of AES in CBC > > > mode MUST be implemented with a specific minimum key size. It seems > > > the statement is "AES in CBC mode SHOULD be supported, with keys that > > > MUST be at least 128 bits in length." Correct? > > > > > > o AES in CBC mode MUST be implemented with 128-bit keys; other ke= y > > > sizes MAY be supported, and > > > > > > > > > > > > 6) Finally, in section 2.2 there is a new MUST requirement. This woul= d > > > appear to introduce an incompatibility with RFC 3723. Is it a SHOULD? > > > > > > In addition, NULL encryption [RFC2410] MUST be implemented to enab= le > > > use of SAs that provide data origin authentication and data > > > integrity, but not confidentiality. Other transforms MAY be > > > implemented in addition to those listed above. > > > > > > >=20 From ttalpey@microsoft.com Sun Jun 30 18:42:01 2013 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 033FF21F9EB0 for ; Sun, 30 Jun 2013 18:42:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e3Kx0He1xZ8R for ; Sun, 30 Jun 2013 18:41:53 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0243.outbound.protection.outlook.com [207.46.163.243]) by ietfa.amsl.com (Postfix) with ESMTP id C461F21F9E92 for ; Sun, 30 Jun 2013 18:41:53 -0700 (PDT) Received: from BY2FFO11FD005.protection.gbl (10.1.15.200) by BY2FFO11HUB008.protection.gbl (10.1.14.166) with Microsoft SMTP Server (TLS) id 15.0.717.3; Mon, 1 Jul 2013 01:41:52 +0000 Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD005.mail.protection.outlook.com (10.1.14.126) with Microsoft SMTP Server (TLS) id 15.0.707.0 via Frontend Transport; Mon, 1 Jul 2013 01:41:52 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.146]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.03.0136.001; Mon, 1 Jul 2013 01:41:51 +0000 From: Tom Talpey To: "storm@ietf.org" Thread-Topic: [storm] Working Group Last Call - IP Storage: IPsec Requirements Update for IPsec v3 Thread-Index: Ac5seEbW6YTVKeIwQ4e5vN67Pyl/4AJgxNqg Importance: high X-Priority: 1 Date: Mon, 1 Jul 2013 01:41:50 +0000 Message-ID: <614F550557B82C44AC27C492ADA391AA11EB1E90@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <614F550557B82C44AC27C492ADA391AA0773D280@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <614F550557B82C44AC27C492ADA391AA0773D280@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(13464003)(189002)(199002)(51704005)(377454003)(23726002)(80022001)(66066001)(50986001)(47736001)(47776003)(65816001)(47976001)(56816003)(46406003)(54356001)(81542001)(4396001)(6806003)(33656001)(16406001)(20776003)(63696002)(77096001)(49866001)(74706001)(50466002)(53806001)(47446002)(79102001)(81342001)(55846006)(56776001)(76796001)(77982001)(74876001)(69226001)(74662001)(46102001)(44976004)(74502001)(83072001)(74366001)(59766001)(31966008)(15202345003)(76786001)(54316002)(51856001)(76482001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB008; H:TK5EX14HUBC104.redmond.corp.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 089473E5FE Subject: Re: [storm] Working Group Last Call - IP Storage: IPsec Requirements Update for IPsec v3 X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 01:42:01 -0000 REMINDER - last call comment period for this document closes on Wednesday, = July 3 at midnight eastern daylight time (4am Thursday July 4 UTC). > -----Original Message----- > From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf > Of Tom Talpey > Sent: Tuesday, June 18, 2013 7:30 PM > To: storm@ietf.org > Subject: [storm] Working Group Last Call - IP Storage: IPsec Requirements > Update for IPsec v3 > Importance: High >=20 > This message is to announce the STORM working group Last Call on the > following document: >=20 > IP Storage: IPsec Requirements Update for IPsec v3 > http://www.ietf.org/internet-drafts/draft-ietf-storm-ipsec-ips-update- > 01.txt >=20 > This new document is created to align IP Storage IPsec profiles with IPse= c-v3 > requirements. The iSCSI consolidated draft and also the iSER draft will m= ake > normative references to this new document, therefore it is desirable to > move it into the publication pipeline promptly, to unblock these other dr= afts. >=20 > Last Call comments are due by Wednesday, July 3 at midnight Eastern time > (two weeks from today). >=20 > Please send all technical comments to the storm mailing list: storm@ietf.= org . > Editorial comments may be sent directly to the draft authors: draft-ietf- > storm-ipsec-ips-update@tools.ietf.org . >=20 > Tom Talpey > STORM WG co-chair >=20 > _______________________________________________ > storm mailing list > storm@ietf.org > https://www.ietf.org/mailman/listinfo/storm