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

"Black, David" <david.black@emc.com> Tue, 09 July 2013 16:54 UTC

Return-Path: <david.black@emc.com>
X-Original-To: storm@ietfa.amsl.com
Delivered-To: storm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F97221F9E1D for <storm@ietfa.amsl.com>; Tue, 9 Jul 2013 09:54:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H4k8asLz6iuJ for <storm@ietfa.amsl.com>; Tue, 9 Jul 2013 09:54:08 -0700 (PDT)
Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 171EC21F9E32 for <storm@ietf.org>; Tue, 9 Jul 2013 09:54:07 -0700 (PDT)
Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r69Gs0Hj014328 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Jul 2013 12:54:03 -0400
Received: from mailhub.lss.emc.com (mailhubhoprd02.lss.emc.com [10.254.221.253]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Tue, 9 Jul 2013 12:53:43 -0400
Received: from mxhub04.corp.emc.com (mxhub04.corp.emc.com [10.254.141.106]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r69GrhD6004479; Tue, 9 Jul 2013 12:53:43 -0400
Received: from mxhub37.corp.emc.com (128.222.70.104) by mxhub04.corp.emc.com (10.254.141.106) with Microsoft SMTP Server (TLS) id 8.3.297.1; Tue, 9 Jul 2013 12:53:43 -0400
Received: from mx15a.corp.emc.com ([169.254.1.184]) by mxhub37.corp.emc.com ([128.222.70.104]) with mapi; Tue, 9 Jul 2013 12:53:42 -0400
From: "Black, David" <david.black@emc.com>
To: Tom Talpey <ttalpey@microsoft.com>, "Paul_Koning@Dell.com" <Paul_Koning@Dell.com>
Date: Tue, 9 Jul 2013 12:53:41 -0400
Thread-Topic: Comments on draft-ietf-storm-ipsec-ips-update
Thread-Index: Ac5yqwuewpr4eeBIT2quJXY1BPmnxAASCVKwABICU1AAH1Nd4AI/1d7QAAG3MlAAAIbegAAA/D2w
Message-ID: <8D3D17ACE214DC429325B2B98F3AE712983F2DAC@MX15A.corp.emc.com>
References: <614F550557B82C44AC27C492ADA391AA0774F9A0@TK5EX14MBXC284.redmond.corp.microsoft.com> <8D3D17ACE214DC429325B2B98F3AE71298332C1E@MX15A.corp.emc.com> <614F550557B82C44AC27C492ADA391AA07750ACC@TK5EX14MBXC284.redmond.corp.microsoft.com> <8D3D17ACE214DC429325B2B98F3AE71298332DB8@MX15A.corp.emc.com> <614F550557B82C44AC27C492ADA391AA11EEABF7@TK5EX14MBXC284.redmond.corp.microsoft.com> <8D3D17ACE214DC429325B2B98F3AE712983F2DA1@MX15A.corp.emc.com> <614F550557B82C44AC27C492ADA391AA11EEAE54@TK5EX14MBXC284.redmond.corp.microsoft.com>
In-Reply-To: <614F550557B82C44AC27C492ADA391AA11EEAE54@TK5EX14MBXC284.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EMM-MHVC: 1
Cc: "storm@ietf.org" <storm@ietf.org>
Subject: Re: [storm] Comments on draft-ietf-storm-ipsec-ips-update
X-BeenThere: storm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Storage Maintenance WG <storm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/storm>, <mailto:storm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/storm>
List-Post: <mailto:storm@ietf.org>
List-Help: <mailto:storm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/storm>, <mailto:storm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Jul 2013 16:54:20 -0000

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

Thanks,
--David


> -----Original Message-----
> From: Tom Talpey [mailto:ttalpey@microsoft.com]
> Sent: Tuesday, July 09, 2013 12:28 PM
> To: Black, David; Paul_Koning@Dell.com
> Cc: storm@ietf.org
> Subject: RE: Comments on draft-ietf-storm-ipsec-ips-update
>
> 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:david.black@emc.com]
> > Sent: Tuesday, July 9, 2013 12:22 PM
> > To: Tom Talpey; Paul_Koning@Dell.com
> > Cc: storm@ietf.org
> > 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:ttalpey@microsoft.com]
> > > Sent: Tuesday, July 09, 2013 11:26 AM
> > > To: Black, David; Paul_Koning@Dell.com
> > > Cc: storm@ietf.org
> > > 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:david.black@emc.com]
> > > > Sent: Friday, June 28, 2013 12:54 AM
> > > > To: Tom Talpey; storm@ietf.org; Paul_Koning@Dell.com
> > > > Subject: RE: Comments on draft-ietf-storm-ipsec-ips-update
> > > >
> > > > Inline ...
> > > >
> > > > Thanks,
> > > > --David
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Tom Talpey [mailto:ttalpey@microsoft.com]
> > > > > Sent: Thursday, June 27, 2013 4:37 PM
> > > > > To: Black, David; storm@ietf.org; Paul_Koning@Dell.com
> > > > > 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:david.black@emc.com]
> > > > > > Sent: Thursday, June 27, 2013 1:41 AM
> > > > > > To: Tom Talpey; storm@ietf.org; Paul_Koning@Dell.com
> > > > > > 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:ttalpey@microsoft.com]
> > > > > > > Sent: Wednesday, June 26, 2013 5:11 PM
> > > > > > > To: storm@ietf.org; Black, David; Paul_Koning@Dell.com
> > > > > > > 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.
> > > > > > >
> > > > > > >
> > > > >
> > >
>