Re: [storm] draft-ietf-storm-ipsec-ips-update - New title proposal

<Paul_Koning@Dell.com> Tue, 02 July 2013 15:08 UTC

Return-Path: <Paul_Koning@Dell.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 ED62D11E80D5 for <storm@ietfa.amsl.com>; Tue, 2 Jul 2013 08:08:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 ltgvpx6OeTId for <storm@ietfa.amsl.com>; Tue, 2 Jul 2013 08:08:00 -0700 (PDT)
Received: from ausc60pc101.us.dell.com (ausc60pc101.us.dell.com [143.166.85.206]) by ietfa.amsl.com (Postfix) with ESMTP id C391E21F9F81 for <storm@ietf.org>; Tue, 2 Jul 2013 08:07:33 -0700 (PDT)
X-LoopCount0: from 10.175.216.251
X-IronPort-AV: E=Sophos;i="4.87,980,1363150800"; d="scan'208";a="172003332"
From: <Paul_Koning@Dell.com>
To: <david.black@emc.com>
Thread-Topic: draft-ietf-storm-ipsec-ips-update - New title proposal
Thread-Index: AQHOdyadL/l6bQVh20OL/cknnJIXSplRwJWAgAAKW4CAAAZPgA==
Date: Tue, 2 Jul 2013 15:07:29 +0000
Message-ID: <C75A84166056C94F84D238A44AF9F6AD034425D9@AUSX10MPC102.AMER.DELL.COM>
References: <614F550557B82C44AC27C492ADA391AA0774F9A0@TK5EX14MBXC284.redmond.corp.microsoft.com> <8D3D17ACE214DC429325B2B98F3AE71298333250@MX15A.corp.emc.com> <614F550557B82C44AC27C492ADA391AA11EC0B32@TK5EX14MBXC283.redmond.corp.microsoft.com> <8D3D17ACE214DC429325B2B98F3AE712983332A6@MX15A.corp.emc.com>
In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712983332A6@MX15A.corp.emc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.177.90.69]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <B8119794915AC74FB5C13780F909ECD4@dell.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: storm@ietf.org
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 15:08:12 -0000

Sounds good to me.

	paul

On Jul 2, 2013, at 10:44 AM, Black, David wrote:

> 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.
>>>> 
>>>> 
>> 
>