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

[Tom Talpey <[e-mail]>]

Sure, I'm ok with the new disambiguation. Editorially, I would suggest removing the second use of "For brevity", to make a simple declarative statement in 1.3.

Tom.

> -----Original Message-----
> From: Black, David [mailto:[e-mail]]
> Sent: Tuesday, July 9, 2013 12:22 PM
> To: Tom Talpey; [e-mail]
> Cc: [e-mail]
> Subject: RE: Comments on draft-ietf-storm-ipsec-ips-update
> Importance: High
> 
> Tom,
> 
> > I reviewed the updated draft-ietf-storm-ipsec-ips-update-02 and the
> > changes address my earlier concerns, thanks.
> 
> Thank you for checking quickly.
> 
> > I did notice one new issue, the new text has a redundancy which is
> > stated slightly differently in its two appearances. In section 1, I
> > suggest deleting the last paragraph, which restates the second
> > paragraph while adding the (imo
> > risky) term "any future protocols".
> 
> I see the concern.  I'd prefer to mention the term "block storage protocols"
> in the introduction, as that term is used there with its broader meaning, but
> you're correct about the duplication wrt Section 1.3.
> 
> Would the following two text changes suffice to address this? -
> 
> Section 1:
> 
> OLD
>    For brevity, this document uses the term "block storage protocols" to
>    refer to all protocols to which RFC 3723's requirements (as updated
>    by the requirements in this document) are applicable.
> NEW
>    For brevity, this document uses the term "block storage protocols" to
>    refer to all protocols to which RFC 3723's requirements apply, see
>    Section 1.3 for details.
> 
> Section 1.3:
> 
> OLD
>    For brevity, this document uses the term "block storage protocols" to
>    refer to all of the above protocols (and any future protocols) to
>    which RFC 3723's requirements (as updated by the requirements in this
>    document) are applicable.
> NEW
>    For brevity, this document uses the term "block storage protocols" to
>    refer to the protocols listed above to which RFC 3723's requirements
>   (as updated by the requirements in this document) apply.
> 
> If so, I'll submit a -03 version to make those changes
> 
> Thanks,
> --David
> 
> > -----Original Message-----
> > From: Tom Talpey [mailto:[e-mail]]
> > Sent: Tuesday, July 09, 2013 11:26 AM
> > To: Black, David; [e-mail]
> > Cc: [e-mail]
> > Subject: RE: Comments on draft-ietf-storm-ipsec-ips-update
> >
> > I reviewed the udated draft-ietf-storm-ipsec-ips-update-02 and the
> > changes address my earlier concerns, thanks.
> >
> > I did notice one new issue, the new text has a redundancy which is
> > stated slightly differently in its two appearances. In section 1, I
> > suggest deleting the last paragraph, which restates the second
> > paragraph while adding the (imo
> > risky) term "any future protocols".
> >
> >       For brevity, this document uses the term "block storage protocols" to
> >        refer to all of the above protocols (and any future protocols) to
> >        which RFC 3723's requirements (as updated by the requirements in this
> >        document) are applicable.
> >
> >
> > > -----Original Message-----
> > > From: Black, David [mailto:[e-mail]]
> > > Sent: Friday, June 28, 2013 12:54 AM
> > > To: Tom Talpey; [e-mail]; [e-mail]
> > > Subject: RE: Comments on draft-ietf-storm-ipsec-ips-update
> > >
> > > Inline ...
> > >
> > > Thanks,
> > > --David
> > >
> > >
> > > > -----Original Message-----
> > > > From: Tom Talpey [mailto:[e-mail]]
> > > > Sent: Thursday, June 27, 2013 4:37 PM
> > > > To: Black, David; [e-mail]; [e-mail]
> > > > Subject: RE: Comments on draft-ietf-storm-ipsec-ips-update
> > > >
> > > > > ...  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.
> > > >
> > > > I'm ok with this, as long as these requirements are clearly stated.
> > > > Any 3DES support seems to me an implementation choice - a target
> > > > could validly refuse to do so based on data privacy requirements.
> > > > So I would agree it is not a MUST.
> > >
> > > Good - in that case, I'll leave the requirements as they are - the
> > > birthday effects on 3DES justify it becoming a MAY, with AES CBC as the
> new MUST.
> > > I'll add the "SHOULD be used in preference" sentence.
> > >
> > > > > 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.
> > > >
> > > > Sounds good, I'll look for the new proposed text.
> > > >
> > > > > > 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.
> > > >
> > > > Well, at least I was confused. Consider the reader of one of the
> > > > original documents, who might follow the RFC3723 reference and be
> > > > redirected to this new document. How would they read "updates"? It
> > > > could mean "replaces" or "adds", and the difference will be
> > > > important to an implementation. The text should strive for clarity.
> > >
> > > Sections 2 and 3 and their subsections are clear about what's going
> > > on, but the introduction could use a summary of what is extended vs.
> > > actually changed that section 1.2 could then refer to (the older
> > > IPsec requirements are reproduced here so that everything is in one
> place).  I'll do that.
> > >
> > > > > 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.
> > > >
> > > > Absolutely. As long as it is clear that this document deprecates 3DES.
> > >
> > > Ok, I need to add text to say that the MUST for 3DES and the SHOULD
> > > for AES CTR have each been replaced by a MAY.
> > >
> > > > > The birthday bound calculation for AES is in an email message
> > > > > and hence I'll need to reproduce that in an added appendix.
> > > >
> > > > I guess that would help. I'd be ok with a milder statement which
> > > > leaves birthday bounds to other documents. Surely, storage is not
> > > > the only upper layer which seeks to protect its messages at high
> > > > data rates, so others may have discussed?
> > >
> > > Nope, have a reference for 3DES birthday bound, but not AES.
> > >
> > >
> > > > > 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.
> > > >
> > > > I think that would clarify the intent, yes. If you choose
> > > > OPTIONAL, note that there are other places in the document which
> > > > refer to key size. And, instead of "other", would "longer" be better
> guidance?
> > > >
> > > > > 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.
> > > >
> > > > Ah, ok. The text immediately prior to this paragraph reads "In
> > > > addition", which makes it appear to be a new requirement as are
> > > > the others. Stating that it is an existing requirement of RFC3723
> > > > would
> > suffice.
> > >
> > > Ah, it's missing from the RFC3723 list at the start of 2.2 - I'll
> > > add text
> > there to
> > > make that clear.
> > >
> > > >
> > > > Tom.
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Black, David [mailto:[e-mail]]
> > > > > Sent: Thursday, June 27, 2013 1:41 AM
> > > > > To: Tom Talpey; [e-mail]; [e-mail]
> > > > > Subject: RE: Comments on draft-ietf-storm-ipsec-ips-update
> > > > >
> > > > > 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.
> > > > > >
> > > > > >
> > > >
> >