[storm] Comments on draft-ietf-storm-ipsec-ips-update

[Tom Talpey <[e-mail]>]

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.