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

Tom Talpey <ttalpey@microsoft.com> Tue, 02 July 2013 14:08 UTC

Return-Path: <ttalpey@microsoft.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 694FE21F9E45 for <storm@ietfa.amsl.com>; Tue, 2 Jul 2013 07:08:21 -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 erIeJNDx+84T for <storm@ietfa.amsl.com>; Tue, 2 Jul 2013 07:08:15 -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 15E9F21F9E4A for <storm@ietf.org>; Tue, 2 Jul 2013 07:08:09 -0700 (PDT)
Received: from BN1BFFO11FD007.protection.gbl (10.58.52.201) by BN1AFFO11HUB007.protection.gbl (10.58.52.117) with Microsoft SMTP Server (TLS) id 15.0.717.3; Tue, 2 Jul 2013 14:08:07 +0000
Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.37) by BN1BFFO11FD007.mail.protection.outlook.com (10.58.53.67) with Microsoft SMTP Server (TLS) id 15.0.707.0 via Frontend Transport; Tue, 2 Jul 2013 14:08:07 +0000
Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.146]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.03.0136.001; Tue, 2 Jul 2013 14:07:49 +0000
From: Tom Talpey <ttalpey@microsoft.com>
To: "Black, David" <david.black@emc.com>, "storm@ietf.org" <storm@ietf.org>, "Paul_Koning@Dell.com" <Paul_Koning@Dell.com>
Thread-Topic: draft-ietf-storm-ipsec-ips-update - New title proposal
Thread-Index: AQHOdyake/EKhFKYKkimVm1d8CF5RplRbEWw
Date: Tue, 2 Jul 2013 14:07:49 +0000
Message-ID: <614F550557B82C44AC27C492ADA391AA11EC0B32@TK5EX14MBXC283.redmond.corp.microsoft.com>
References: <614F550557B82C44AC27C492ADA391AA0774F9A0@TK5EX14MBXC284.redmond.corp.microsoft.com> <8D3D17ACE214DC429325B2B98F3AE71298333250@MX15A.corp.emc.com>
In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71298333250@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.35]
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:(189002)(377454003)(199002)(51704005)(164054003)(13464003)(54316002)(77096001)(33656001)(69226001)(77982001)(6806003)(23726002)(74706001)(59766001)(80022001)(50466002)(66066001)(65816001)(47736001)(74876001)(76796001)(50986001)(46102001)(55846006)(47976001)(76786001)(49866001)(56816003)(79102001)(46406003)(81342001)(76482001)(51856001)(31966008)(16406001)(561944002)(54356001)(74502001)(74366001)(81542001)(63696002)(74662001)(4396001)(56776001)(53806001)(47776003)(47446002)(83072001)(20776003); DIR:OUT; SFP:; SCL:1; SRVR:BN1AFFO11HUB007; H:TK5EX14HUBC102.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: 0895DF8FFD
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:08:21 -0000

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