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

[<[e-mail]>]

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:[e-mail]]
>> Sent: Tuesday, July 02, 2013 10:08 AM
>> To: Black, David; [e-mail]; [e-mail]
>> 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:[e-mail]]
>>> Sent: Tuesday, July 2, 2013 9:18 AM
>>> To: Tom Talpey; [e-mail]; [e-mail]
>>> 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:[e-mail]]
>>>> Sent: Wednesday, June 26, 2013 5:11 PM
>>>> To: [e-mail]; Black, David; [e-mail]
>>>> 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.
>>>> 
>>>> 
>> 
>