Subject: [IPsec] I-D Action:draft-ietf-ipsecme-aes-ctr-ikev2-00.txt

From: [email-masked]
Date: Mon, 27 Jul 2009 04:30:01 -0700 (PDT)

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, et al.
	Filename        : draft-ietf-ipsecme-aes-ctr-ikev2-00.txt
	Pages           : 14
	Date            : 2009-07-27

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 27 Jul 2009 22:06:19 +0300

Thanks for getting this draft out. Here's a few comments, in general I would
like to copy RFC 3686 as much as possible. Specifically, more of Sec. 2.1 of
that RFC needs to appear here.

2.1: All IKEv2 implementations *that implement AES-CTR* MUST support...
(after all, this is a SHOULD algorithm).

3.2: RFC 4306, sec. 3.14 says the integrity checksum is a MUST in this
payload. So there's no need to justify it. Also, instead of pointing out a
"likely choice", please refer the reader to RFC 4307.

4. The second paragraph is critical to understanding how the Encrypted
Payload is created. But it's extremely unclear: is this "counter block" put
explicitly into the payload? Where? In fact, why is the counter block
different from that defined by RFC 3686?

Block Counter: the sentence "The block counter field is the least
significant 32 bits of the counter block" is confusing. Why not just say
that the counter is 32 bits, and it's allowed to wrap around when it reaches
0xFFFF.

Thanks,
	Yaron

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Monday, July 27, 2009 13:30
> To: [email-masked]
> Cc: [email-masked]
> Subject: [IPsec] I-D Action:draft-ietf-ipsecme-aes-ctr-ikev2-00.txt
>

---

From: shenshuo 00102542 <[email-masked]>
Date: Tue, 28 Jul 2009 05:20:12 +0800

Hi, Yaron,
Thanks for the detailed comments. We will address these following issues soon in the next version.

Sean

> 2.1: All IKEv2 implementations *that implement AES-CTR* MUST 
> support...(after all, this is a SHOULD algorithm).
> 
> > This draft is a work item of the IP Security Maintenance and 
> Extensions> Working Group of the IETF.
> > 
> > 
> > http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-aes-ctr-
> ikev2-
> > 00.txt
> >