Re: [storm] draft-ietf-storm-ipsec-ips-update - New title proposal
"Black, David" <david.black@emc.com> Tue, 02 July 2013 14:45 UTC
Return-Path: <david.black@emc.com>
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 4CA9821F9F77 for <storm@ietfa.amsl.com>; Tue, 2 Jul 2013 07:45:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.499
X-Spam-Level:
X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 vJebhVQl-WiG for <storm@ietfa.amsl.com>; Tue, 2 Jul 2013 07:45:12 -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 8546A21F9E91 for <storm@ietf.org>; Tue, 2 Jul 2013 07:45:12 -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 r62Ej4Sb014954 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Jul 2013 10:45:05 -0400
Received: from mailhub.lss.emc.com (mailhubhoprd05.lss.emc.com [10.254.222.129]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Tue, 2 Jul 2013 10:44:54 -0400
Received: from mxhub01.corp.emc.com (mxhub01.corp.emc.com [10.254.141.103]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r62EisbW001801; Tue, 2 Jul 2013 10:44:54 -0400
Received: from mx15a.corp.emc.com ([169.254.1.184]) by mxhub01.corp.emc.com ([10.254.141.103]) with mapi; Tue, 2 Jul 2013 10:44:54 -0400
From: "Black, David" <david.black@emc.com>
To: Tom Talpey <ttalpey@microsoft.com>, "storm@ietf.org" <storm@ietf.org>, "Paul_Koning@Dell.com" <Paul_Koning@Dell.com>
Date: Tue, 02 Jul 2013 10:44:53 -0400
Thread-Topic: draft-ietf-storm-ipsec-ips-update - New title proposal
Thread-Index: AQHOdyake/EKhFKYKkimVm1d8CF5RplRbEWwgAAKXTA=
Message-ID: <8D3D17ACE214DC429325B2B98F3AE712983332A6@MX15A.corp.emc.com>
References: <614F550557B82C44AC27C492ADA391AA0774F9A0@TK5EX14MBXC284.redmond.corp.microsoft.com> <8D3D17ACE214DC429325B2B98F3AE71298333250@MX15A.corp.emc.com> <614F550557B82C44AC27C492ADA391AA11EC0B32@TK5EX14MBXC283.redmond.corp.microsoft.com>
In-Reply-To: <614F550557B82C44AC27C492ADA391AA11EC0B32@TK5EX14MBXC283.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] draft-ietf-storm-ipsec-ips-update - New title proposal
X-BeenThere: storm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Storage Maintenance WG <storm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/storm>, <mailto:storm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/storm>
List-Post: <mailto:storm@ietf.org>
List-Help: <mailto:storm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/storm>, <mailto:storm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Jul 2013 14:45:18 -0000
Yes - that filename will remain as-is. I'll make that title change in the -02 version that I submit after WG Last Call completes, and as part of that, all use of "IP Storage protocols" (and any other use of "IP Storage" will get removed. Thanks, --David > -----Original Message----- > From: Tom Talpey [mailto:ttalpey@microsoft.com] > Sent: Tuesday, July 02, 2013 10:08 AM > To: Black, David; storm@ietf.org; Paul_Koning@Dell.com > Subject: RE: draft-ietf-storm-ipsec-ips-update - New title proposal > > Looks good to me. The addition of "Block" is good context, and mirroring the > previous title is a good approach. > > I assume the I-D tag (draft-storm-ipsec-ips-update) does not need to change, > since it will be replaced when promoted to RFC. > > Tom. > > > -----Original Message----- > > From: Black, David [mailto:david.black@emc.com] > > Sent: Tuesday, July 2, 2013 9:18 AM > > To: Tom Talpey; storm@ietf.org; Paul_Koning@Dell.com > > Subject: draft-ietf-storm-ipsec-ips-update - New title proposal > > Importance: High > > > > > 1) In section 1 Introduction, the term "IP Storage protocols" is not > defined. > > [... snip ...] > > > Technically speaking, this comment applies to the title of the document as > > well. > > > > I need to propose a new draft title, as that'll be needed to update > references > > in other drafts. The straightforward thing to do is start from RFC 3723's > title, > > Securing Block Storage Protocols over IP. Therefore I propose the following > > new title for draft-ietf-storm-ipsec-ips-update; > > > > Securing Block Storage Protocols over IP: > > RFC 3723 Requirements Update for IPsec v3 > > > > The abstract and introduction will explain that these requirements have been > > applied to protocols beyond block storage. > > > > Does that work? > > > > 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 applies > to > > the title of the document as well. > > > > > > > > > > > > 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, 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 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: > > > > > > > > > > > > 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. > > > > > > >
- [storm] Comments on draft-ietf-storm-ipsec-ips-up… Tom Talpey
- Re: [storm] Comments on draft-ietf-storm-ipsec-ip… Black, David
- Re: [storm] Comments on draft-ietf-storm-ipsec-ip… Tom Talpey
- Re: [storm] Comments on draft-ietf-storm-ipsec-ip… Black, David
- [storm] draft-ietf-storm-ipsec-ips-update - New t… Black, David
- Re: [storm] draft-ietf-storm-ipsec-ips-update - N… Tom Talpey
- Re: [storm] draft-ietf-storm-ipsec-ips-update - N… Black, David
- Re: [storm] draft-ietf-storm-ipsec-ips-update - N… Paul_Koning
- Re: [storm] Comments on draft-ietf-storm-ipsec-ip… Tom Talpey
- Re: [storm] Comments on draft-ietf-storm-ipsec-ip… Black, David
- Re: [storm] Comments on draft-ietf-storm-ipsec-ip… Tom Talpey
- Re: [storm] Comments on draft-ietf-storm-ipsec-ip… Black, David