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

Tom Talpey <ttalpey@microsoft.com> Tue, 09 July 2013 16:28 UTC

Return-Path: <ttalpey@microsoft.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 0222821F9E66 for <storm@ietfa.amsl.com>; Tue, 9 Jul 2013 09:28:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level:
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 dkigHOiHcwVs for <storm@ietfa.amsl.com>; Tue, 9 Jul 2013 09:28:29 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0240.outbound.protection.outlook.com [207.46.163.240]) by ietfa.amsl.com (Postfix) with ESMTP id A8CCA21F9E3C for <storm@ietf.org>; Tue, 9 Jul 2013 09:28:29 -0700 (PDT)
Received: from BY2FFO11FD025.protection.gbl (10.1.15.204) by BY2FFO11HUB002.protection.gbl (10.1.14.144) with Microsoft SMTP Server (TLS) id 15.0.717.3; Tue, 9 Jul 2013 16:28:28 +0000
Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD025.mail.protection.outlook.com (10.1.15.214) with Microsoft SMTP Server (TLS) id 15.0.717.3 via Frontend Transport; Tue, 9 Jul 2013 16:28:28 +0000
Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.79]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.03.0136.001; Tue, 9 Jul 2013 16:27:51 +0000
From: Tom Talpey <ttalpey@microsoft.com>
To: "Black, David" <david.black@emc.com>, "Paul_Koning@Dell.com" <Paul_Koning@Dell.com>
Thread-Topic: Comments on draft-ietf-storm-ipsec-ips-update
Thread-Index: Ac5yqwuewpr4eeBIT2quJXY1BPmnxAASCVKwABICU1AAH1Nd4AI/1d7QAAG3MlAAAIbegA==
Date: Tue, 9 Jul 2013 16:27:51 +0000
Message-ID: <614F550557B82C44AC27C492ADA391AA11EEAE54@TK5EX14MBXC284.redmond.corp.microsoft.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>
In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712983F2DA1@MX15A.corp.emc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.51.34]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(51914003)(377454003)(51704005)(31014004)(199002)(189002)(13464003)(164054003)(51444003)(33656001)(46406003)(63696002)(47446002)(44976004)(77982001)(50466002)(74366001)(76482001)(76796001)(77096001)(23726002)(79102001)(83072001)(54316002)(56776001)(53806001)(74706001)(31966008)(54356001)(81342001)(81542001)(59766001)(66066001)(47736001)(49866001)(6806003)(80022001)(74662001)(55846006)(50986001)(56816003)(47976001)(47776003)(76786001)(74876001)(46102001)(20776003)(4396001)(51856001)(16406001)(65816001)(69226001)(74502001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB002; H:TK5EX14HUBC104.redmond.corp.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en;
X-OriginatorOrg: microsoft.onmicrosoft.com
X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY)
X-Forefront-PRVS: 0902222726
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:28:36 -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.

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