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

["Black, David" <[e-mail]>]

Tom,

Thanks for the thorough review.

Most of this is editorial - the one item that is a technical issue is that
the encryption algorithm requirement changes may not be backwards compatible,
as 3DES is no longer appropriate for this use; AES CBC is the new mandatory
to implement encryption algorithm in this draft.  I could leave 3DES as
mandatory to implement for backwards compatibility if that helps, but AES CBC
really has to be mandatory to implement due to the problems w/3DES at
high data rates.  If both AES CBC and 3DES are supported, AES CBC SHOULD be
used in preference to 3DES.

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

I took another look at RFC 3723 - it's entitled "Securing Block Storage
Protocols over IP" although, as you point out, its IPsec requirements have
been applied to iWARP.  I've referred to these requirements as the IP Storage
IPsec requirements, in part due to the name of the working group that developed
them.  The draft title might be better restated to reference RFC 3723, and I'll
see about changing the text from use of "IP Storage protocols" to talking
about protocols that use the RFC 3723 IPsec requirements.  The first paragraph
of the introduction will need to be expanded to explain this.

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

Sure.

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

Section 1.2 says that it "updates the IPsec requirements for each protocol
specification that uses RFC 3723"  I think that sufficiently defines the scope.

> And presumably, it is
> not the intention to retroactively make these requirements, therefore any
> existing RFC3723-compliant security approach remains intact?  

Actually, that is the intention, particularly the 3DES to AES CBC change in
mandatory encryption algorithm due to birthday problems with 3DES at high data
rates.  Older implementations may still claim compliance to RFC 3723 prior to
this update, but the intent of this update is to move away from 3DES in all
cases.

> 4) [editorial] In section 2.2 the word "astronomical" is unnecessary and
> should be deleted

Ok.

> Is there a reference for the 2^69 birthday bound of AES
> blocks? Point the discussion there.

The birthday bound calculation for AES is in an email message and hence
I'll need to reproduce that in an added appendix.

> 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

Ok.

> 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

The requirement is basically correct as stated, AES in CBC mode with 128-bit
keys MUST be supported.  Other key sizes for AES in CBC mode are OPTIONAL.
I can rephrase in that form if it helps.

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

It's not new - the requirement exists in RFC 3723, as the last sentence in
section 2.3.1 on Transforms:

  ESP with NULL encryption MUST be supported for authentication.

That is the same requirement expressed in a different fashion.

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