Re: [IPsec] Please review draft-ietf-ipsecme-aes-ctr-ikev2-05.txt

> Security considerations explained in section 7 of [RFC3686] are > entirely relevant for this draft also. The security considerations > on fresh keys and integrity protection in section 7 of [RFC3686] are > totally applicable on using AES-CTR in IKEv2; see [RFC3686] for > details. Due

Re: [IPsec] Please review draft-ietf-ipsecme-aes-ctr-ikev2-05.txt

> Raj Singh writes: >> Section 5. IANA Considerations can be reworded in-line with >> ikev2bis. > > It would be better align it with ikev2-parameters iana registry. > >> 5. IANA Considerations >> >> IANA has already registered the type and value for AES-CTR. >> >> Name Numbe

Re: [IPsec] IETFLC comments for draft-ietf-ipsecme-ikev2bis-08

pasi.ero...@nokia.com writes: > Paul Hoffman wrote: > > > >- One of the changes is listed in Section 1.7 twice. I'd suggest > > >combining > > > > > > In section 1.3.2, changed "The KEi payload SHOULD be included" to > > > be "The KEi payload MUST be included". This also led to changes in > >

[IPsec] Issue #176: What to do with a proposal of NONE

Paul Hoffman writes: > > > Pasi says: > > Section 3.3.6 says "If one of the proposals offered is for the > Diffie-Hellman group of NONE, the responder MUST ignore the > initiator's KE payload and omit the KE payload from the response." > >

Re: [IPsec] IETFLC comments for draft-ietf-ipsecme-ikev2bis-08

At 8:16 AM +0100 3/8/10, wrote: >Well, this depends on whether you think Section 1.7 should list >textual changes in the document, or clarification/changes to the >protocol. > >IMHO, it should be the latter, but I see that currently it's really >listing the textual changes (even when they clearly

Re: [IPsec] Issue #176: What to do with a proposal of NONE

At 5:10 PM +0200 3/8/10, Tero Kivinen wrote: >Paul Hoffman writes: >> >> >> Pasi says: >> >> Section 3.3.6 says "If one of the proposals offered is for the >> Diffie-Hellman group of NONE, the responder MUST ignore the >> initiator's KE payloa

Re: [IPsec] IETFLC comments for draft-ietf-ipsecme-ikev2bis-08

Paul Hoffman writes: > At 8:16 AM +0100 3/8/10, wrote: > >Well, this depends on whether you think Section 1.7 should list > >textual changes in the document, or clarification/changes to the > >protocol. > > > >IMHO, it should be the latter, but I see that currently it's really > >listing the textu

[IPsec] IETFLC comments for draft-ietf-ipsecme-ikev2bis-08

Section 2.23, paragraph starting: "An initiator can use port 4500 for both IKE and ESP, regardless of whether or not there is a NAT, even at the beginning of IKE.". What does, "even at the beginning of IKE" mean? Does it mean, "even when sending an IKE_SA_INIT request" or "even at any poi

[IPsec] comments on draft-ietf-ipsecme-aes-ctr-ikev2-05.txt

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

Re: [IPsec] Issue #176: What to do with a proposal of NONE

I agree. From: Paul Hoffman To: Tero Kivin

[IPsec] Response to Pasi's AD comments on the roadmap draft

Here are our responses to Pasi's AD comments on the roadmap doc. We have indicated which changes we plan to make, and which ones we would prefer to handle somewhat differently. We would appreciate hearing from the list, both those who agree and those who don't. We will send a separate email lis

[IPsec] Pasi's AD comments on roadmap doc - RFCs to add/delete

Here are the RFCs that Pasi suggested adding/removing from the roadmap doc. If anyone has any strong opinions either pro or con, now's the time to speak up. Sheila and Suresh several groups of RFCs that Pasi wants us t

Re: [IPsec] comments on draft-ietf-ipsecme-aes-ctr-ikev2-05.txt

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

Re: [IPsec] comments on draft-ietf-ipsecme-aes-ctr-ikev2-05.txt

Hi, Let me take this opportunity to point out that RFC 5297 describes an AES-CTR variant that does not have the performance benefits that GCM has but provides nonce misuse/abuse resistance. It is a much more robust alternative than CCM because security is not voided if the nonce/counter happe

Re: [IPsec] comments on draft-ietf-ipsecme-aes-ctr-ikev2-05.txt

At 11:17 AM -0800 3/8/10, Dan Harkins wrote: > Let me take this opportunity to point out that RFC 5297 describes >an AES-CTR variant that does not have the performance benefits that >GCM has but provides nonce misuse/abuse resistance. It feels like your comment is unrelated to this thread, unless

Re: [IPsec] Issue #176: What to do with a proposal of NONE

Me too. From: ipsec-boun...@ietf.org [ipsec-boun...@ietf.org] On Behalf Of David Wierbowski [wierb...@us.ibm.com] Sent: Monday, March 08, 2010 19:55 To: Paul Hoffman Cc: IPsecme WG; ipsec-boun...@ietf.org Subject: Re: [IPsec] Issue #176: What to do with a p