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

From: "Black, David" <[email-masked]>
Date: Tue, 2 Jul 2013 09:18:00 -0400

> 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:[email-masked]]
> Sent: Wednesday, June 26, 2013 5:11 PM
> To: [email-masked]; Black, David; [email-masked]
> 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.
> 
>

---

From: Tom Talpey <[email-masked]>
Date: Tue, 2 Jul 2013 14:07:49 +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.

> From: Black, David [mailto:[email-masked]]
> Sent: Tuesday, July 2, 2013 9:18 AM
> To: Tom Talpey; [email-masked]; [email-masked]
> Subject: draft-ietf-storm-ipsec-ips-update - New title proposal
> Importance: High
> 
> 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;
> 
> > 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.
> >
> >
> >
> > 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."
> >
> > 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.
> >
> > 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?
> >
> > 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?
> >

---

From: "Black, David" <[email-masked]>
Date: Tue, 2 Jul 2013 10:44:53 -0400

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

> Sent: Tuesday, July 02, 2013 10:08 AM
> To: Black, David; [email-masked]; [email-masked]
> Subject: RE: draft-ietf-storm-ipsec-ips-update - New title proposal
> 
> 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.
> 
> title,

---

From: <[email-masked]>
Date: Tue, 2 Jul 2013 15:07:29 +0000

Sounds good to me.

	paul

---

From: Tom Talpey <[email-masked]>
Date: Tue, 9 Jul 2013 15:25:57 +0000

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.  

> Sent: Friday, June 28, 2013 12:54 AM
> Subject: RE: Comments on draft-ietf-storm-ipsec-ips-update
> 
> Inline ...
> 
> Thanks,
> --David
> 
> 
> > Sent: Thursday, June 27, 2013 4:37 PM
> > 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.
> >
> >
> >
> > > Sent: Thursday, June 27, 2013 1:41 AM
> > > 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.
> > > > restating it more generically. Technically speaking, this comment
> > > > applies
> > to
> > > 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.
> > >
> > > > 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.
> > > >
> > > 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.
> > >
> > > >       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?
> > > >
> > > 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
> > >
> > >
> > > > 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.
> > > > restating it more generically. Technically speaking, this comment
> > > > applies
> > to
> > > > 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.
> > > >
> > > > 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
> > > > 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.
> > > >
> > > > 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?
> > > >
> > > > 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?
> > > >

---

From: "Black, David" <[email-masked]>
Date: Tue, 9 Jul 2013 12:21:36 -0400

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

> Sent: Tuesday, July 09, 2013 11:26 AM
> To: Black, David; [email-masked]
> Cc: [email-masked]
> 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".
>

---

From: Tom Talpey <[email-masked]>
Date: Tue, 9 Jul 2013 16:27:51 +0000

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.

> Sent: Tuesday, July 9, 2013 12:22 PM
> To: Tom Talpey; [email-masked]
> Cc: [email-masked]
> > I reviewed the updated 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
> > 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
> > > > > 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.
> > > >
> > > > 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.
> > > > > 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.
> > > >
> > > > > > 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.
> > > >
> > > > 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.
> > > >
> > > 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.
> > > >
> > > > 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?
> > >
> > > > > 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 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?
> > > >
> > > > 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.
> > > >
> > > >
> > > >
> > > > > Most of this is editorial - the one item that is a technical
> > > > > issue is that
> > > > the
> > > > > 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.
> > > > > > Assuming that's not the intent, I suggest defining the term,
> > > > > > or restating it more generically. Technically speaking, this
> > > > > > comment applies
> > > > to
> > > > > 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:
> > > > > >
> > > > > > 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
> > > > > 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.
> > > > >
> > > > > The birthday bound calculation for AES is in an email message
> > > > > and hence I'll need to reproduce that in an added appendix.
> > > > >
> > > > > >    o  Implementations that support IKEv2 SHOULD also implement
> > > > > > AES
> > > GCM
> > > > > > 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
> > > > > >    o  AES in CBC mode MUST be implemented with 128-bit keys;
> > > > > > other
> > > key
> > > > > 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.
> > > > > > 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?
> > > > >
> > > > > > 1) In section 1 Introduction, the term "IP Storage protocols"
> > > > > > is not
> > > > defined.
> > > > > > Assuming that's not the intent, I suggest defining the term,
> > > > > > or restating it more generically. Technically speaking, this
> > > > > > comment applies
> > > > to
> > > > > > 2) In section 1 Introduction, the text in the following
> > > > > > sentence is
> > vague:
> > > > > >
> > > > > > 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
> > > > > > RFC3723-compliant security approach remains intact?  Perhaps
> > > > > > the statement would be more accurately "provides updated
> > > > > > reference guidance for IPsec security
> > > > > >    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,
> > > > > >    o  Implementations that support IKEv2 SHOULD also implement
> > > > > > AES
> > > GCM
> > > > > > 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
> > > > > >    o  AES in CBC mode MUST be implemented with 128-bit keys;
> > > > > > other
> > > key
> > > > > > 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

---

From: "Black, David" <[email-masked]>
Date: Tue, 9 Jul 2013 12:53:41 -0400

Great, I'll do that - the resulting -03 with these two changes should be coming later today.

Thanks,
--David

> Sent: Tuesday, July 09, 2013 12:28 PM
> 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.
>