At 8:33 AM -0800 3/8/10, David McGrew wrote: >The statement that "Although the [RFC4307] specifies that the AES-CTR >encryption algorithm feature SHOULD be supported by IKEv2, no existing >document specifies how IKEv2 can support the feature" is not completely >correct. RFC 5282 specifies how to use AES in the Galois Counter Mode (GCM) >and Counter and CBC-MAC (CCM) modes of operation.
David, that sounds like you are saying that GCM and CCM modes are the same at the CTR mode, which we all know is not true. The statement in the current draft is true, and I would not want to muddy it by saying ", but other RFCs specify how IKEv2 can support other modes". >Neither this draft nor RFC 4307 provides any rationale for why or when AES-CTR >should be used. If it is considered useful because CTR can be pipelined or >implemented in parallel, then the considerations of >http://tools.ietf.org/html/draft-mcgrew-esp-ah-algo-update-00#section-3 would >apply. What value is there is promoting the use of AES-CTR when better >technical alternatives exist and are on standards track? Because implementers might do it anyway, regardless of whether there might be better alternatives. We have already heard that some have. >If the sole motivation for this standard is to correct the inconsistency >between RFC 4307 and RFC 3686, then the draft should include a statement to >that effect, Agree, but... > and mention the IKEv2 transforms that have all of the advantages of AES-CTR > already exist. Disagree. GCM and CCM have the disadvantage of being more complex than CTR, and that complexity brings more safety. Instead, this draft can point to RFC 5282 as another way to do *similar* things. >The draft is not very clear on how AES-CTR is supposed to be implemented. >What is the counter format and what is the increment function? If the intent >is to copy RFC 3686 then this needs to be made more explicit. A sentence on each of those would be good additions to section 2. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
