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