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.
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?
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, and mention the IKEv2 transforms
that have all of the advantages of AES-CTR already exist.
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.
David
On Mar 3, 2010, at 9:51 AM, Paul Hoffman wrote:
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the IP Security Maintenance and
Extensions Working Group of the IETF.
Title : Using Advanced Encryption Standard (AES) Counter Mode
with IKEv2
Author(s) : S. Shen, Y. Mao, S. murthy
Filename : draft-ietf-ipsecme-aes-ctr-ikev2-05.txt
Pages : 10
Date : 2010-3-2
This document describes the usage of Advanced Encryption Standard
Counter Mode (AES-CTR), with an explicit initialization vector, by
IKEv2 for encrypting the IKEv2 exchanges that follow the IKE_SA_INIT
exchange.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-aes-ctr-ikev2-05.txt
Based on Pasi's AD review, the authors significantly shortened the
document. It seems prudent to have the WG review the new, shorter
version. In particular, it would be good for developers to look at
the new short document and see if it is complete enough to implement
from.
This review cycle will end in a week, but please do the review early
in case problems are found.
--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
