[IPsec] IKEv2-bis, comments up to 2.16

Abstract: "It replaces" -> "This specification replaces" (otherwise "it" could refer to the protocol itself). 1: Remove bracketed first paragraph of the Introduction. 1: "IKE message flow" -> "An IKE message flow". 1.1.3: "IPsec- protected" - remove space. 1.2: in the table, add "IKE header (n

[IPsec] IKEv2-bis discussion - please jump in!

Hi everyone, Right before this document is sent to our AD, this is the last chance for us as a group to put the finishing touches on it. I'd like to urge you all to read the comments that were sent to the list in the last few days, add your own comments if necessary, and actively participate in

Re: [IPsec] HTTP_CERT_LOOKUP_SUPPORTED (was: Re: Review of rest of draft-ietf-ipsecme-ikev2 (section 2.23.1 forward))

David Wierbowski writes: > >>I agree with the wording Tero has provided and I think that is > >>what the intent of the original text was. > > > >We disagree here. The point of hash-and-URL was to prevent people from > >sending certs. There are two things here, there is HTTP_CERT_LOOKUP_SUPPORTED a

Re: [IPsec] Payload order section number (Re: Reviews of section 1 and 2 of the draft-ietf-ipsecme-ikev2)

Paul Hoffman writes: > >BTW, so we are going to leave the reference to point to only section 2 > >in the end of section 2.5? > > No, it now says sections 1 and 2. Not in the draft-ietf-ipsecme-ikev2bis-06.txt. Am I missing something, or is there newer version availabe from somewhere? -- kivi...@

[IPsec] IKEv2-bis, comments up to 2.16

I only commented to those cases where I disagreed with you (mostly I think we do not need to make the change). The other comments were ok for me. Yaron Sheffer writes: > 1.3.2: for some reason we support negotiation of DH parameters when > rekeying the IKE SA. So we should say that the INVALID_KE_

Re: [IPsec] IKEv2bis, comments about sections 3-

Paul Hoffman wrote: > - Section 3.13.1: the paragraph about Mobility Header is very > confusing; suggested rephrasing: > >Traffic selectors can use IP Protocol ID 135 to match the IPv6 >mobility header [MIPV6]. As specified in [IPSECARCH], the IPv6 >mobility header (MH) message type

Re: [IPsec] IKEv2-bis, comments up to 2.16

Hi Tero, thanks for your response. Some comments below. Yaron > -Original Message- > From: Tero Kivinen [mailto:kivi...@iki.fi] > Sent: Wednesday, January 20, 2010 14:22 > To: Yaron Sheffer > Cc: ipsec@ietf.org > Subject: [IPsec] IKEv2-bis, comments up to 2.16 > > I only commente

[IPsec] I-D Action:draft-ietf-ipsecme-traffic-visibility-12.txt

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 : Wrapped ESP for Traffic Visibility Author(s) : K. Grewal, et al. File

Re: [IPsec] IKEv2-bis, comments up to 2.16

Yaron Sheffer writes: > > > 1.4: "The processing of an INFORMATIONAL exchange is determined by > > > its component payloads." Adding "The payloads are processed in > > > strict left-to-right order" would make it deterministic, and is > > > probably what people do today. > > > > There should be no

Re: [IPsec] IKEv2-bis, comments up to 2.16

Hi Tero, I meant exactly what your last paragraph says: the simultaneous rekey text is descriptive. We should describe what happens when a "new" peer meets an "old" peer, given that BOTH are legitimate. Thanks, Yaron > -Original Message- > From: Tero Kivinen [mailto:kivi...@ik

Re: [IPsec] Payload order section number (Re: Reviews of section 1 and 2 of the draft-ietf-ipsecme-ikev2)

At 12:35 PM +0200 1/20/10, Tero Kivinen wrote: >Paul Hoffman writes: >> >BTW, so we are going to leave the reference to point to only section 2 >> >in the end of section 2.5? >> >> No, it now says sections 1 and 2. > >Not in the draft-ietf-ipsecme-ikev2bis-06.txt. Am I missing something, >or is the

Re: [IPsec] HTTP_CERT_LOOKUP_SUPPORTED (was: Re: Review of rest of draft-ietf-ipsecme-ikev2 (section 2.23.1 forward))

At 12:01 AM -0500 1/20/10, David Wierbowski wrote: > >>I agree with the wording Tero has provided and I think that is >>>what the intent of the original text was. >> >>We disagree here. The point of hash-and-URL was to prevent people from >sending certs. > >We do not disagree. The point of hash-an

Re: [IPsec] new traffic visibility draft

So we finally have a draft that attempts to resolve all the issues that were raised by the IESG. As you know, some important changes were made, so if you care about the draft (basically every regular participant expressed an opinion during the poll...), please reread it now. Thanks, Yar

[IPsec] Issue #147: Allowing limited retransmission of one-way IKE messages

Either in 2.1 or in 1.5 we should say something about allowing limited retransmission of the rare one-way IKE messages, for reliability. --Paul Hoffman, Director --VPN Consortium ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinf

[IPsec] Issue #149: Use of "SA" and "SA pair"

2.8: "The responder can be assured that the initiator is prepared to receive messages on an SA if either (1) it has received a cryptographically valid message on the new SA." this should really be "...on the new SA's dual SA" (or better wording thereof) since there's a pair of SAs, and we are de

[IPsec] Issue #150: What happens if the peer receives TEMPORARY_FAILURE and does not understand it

2.8.2: we should add a sentence on what happens if the peer receives TEMPORARY_FAILURE and does not understand it (because it's new to this spec). --Paul Hoffman, Director --VPN Consortium ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailm

[IPsec] Issue #152: EAP failure and acknowledgement

2.16: if the responder sends an EAP Failure, is this IKE message acknowledged by the initiator? --Paul Hoffman, Director --VPN Consortium ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Issue #153: List of EAP methods

3.16: I suggest to remove the table quoted from the EAP RFC. There are dozens of methods now in the IANA registry, many of which are preferable to the ones mentioned here. --Paul Hoffman, Director --VPN Consortium ___ IPsec mailing list IPsec@ietf.org

[IPsec] Issue #151: Explicit calculation of AUTH

2.16: it would be useful if we added the explicit calculation of AUTH. For example, is the padding string required for EAP as well? There are two cases, with MSK and with SK_pi+SK_pr. --Paul Hoffman, Director --VPN Consortium ___ IPsec mailing list IPs

[IPsec] Issue #148: Historical cookie discussion

In 2.6, first paragraph: the historical discussion going back to the previous century is very confusing to a newcomer: instead of saying what a cookie is, we tell a story. I suggest to remove this discussion or move it to the end of the section. Can we separate the cookie discussion into its ow

Re: [IPsec] Issue #152: EAP failure and acknowledgement

In fact, the whole message sequence of EAP Failure is not described anywhere, and is at best hinted in 2.21.2, which in general assumes the basic 2-message IKE_AUTH exchange. Yaron > -Original Message- > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf > Of

Re: [IPsec] IKEv2-bis, comments up to 2.16

Thanks for the in-depth review; I expect we will hear more for sections after 2.16. I have incorporated all the editor comments and opened issues for many of the technical ones. Here is my list of ones that I have rejected; it does not include ones that Tero responded to and you agreed to drop.

Re: [IPsec] IKEv2-bis, comments up to 2.16

Hi Paul, Thanks for rejecting my issues so quickly :-) Please see some comments below. I have deleted issues where I accept the rejection. Yaron > -Original Message- > > = > 1.4.1: the last paragraph springs a surprise by defining the behavior > of IKE SA deletion while dis

[IPsec] I-D Action:draft-ietf-ipsecme-ikev2bis-07.txt

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 : Internet Key Exchange Protocol: IKEv2 Author(s) : C. Kaufman, et al.

[IPsec] New IKEv2bis draft posted; please help close out the open issues

Greetings again. The -07 draft is now posted. You can see the numerous diffs at . Please review them to be sure I didn't screw anything up. But, more importantly, there are 22 open issues (

Re: [IPsec] Issue #150: What happens if the peer receives TEMPORARY_FAILURE and does not understand it

Tero Kivinen and David Wierbowski had some discussions on and off the list that resulted in the new text in 2.8.2 that mentions sending TEMPOARY_FAILURE and I acted as the scribe. I have been a proponent of avoiding sending TEMPORARY_FAILURE to a peer that does not understand it by incrementing

Re: [IPsec] Issue #150: What happens if the peer receives TEMPORARY_FAILURE and does not understand it

We can't really prescribe actions for (presumably older) implementations that don't support this spec. Such implementations will do what it says in RFC 4306 and the clarifications document: TEMPORARY_FAILURE is an error notification, so therefore the exchange failed. In that case the old SA r

Re: [IPsec] Issue #153: List of EAP methods

Agree. Certainly types 4-6 have to be removed, as they are just methods, and we RECOMMEND not to use them. I can see some value in mentioning type 1 (Identity), because later in that same section we mention that the responder should not send such requests. I think we should remove all the rest,

Re: [IPsec] Issue #152: EAP failure and acknowledgement

We do have this: The responder MAY at any time terminate the IKE exchange by sending an EAP payload containing the Failure message. I guess "terminate" means that the initiator does not send any more messages. This is also on

Re: [IPsec] Issue #148: Historical cookie discussion

I think remove. Also the reference to PHOTURIS On Jan 20, 2010, at 11:01 PM, Paul Hoffman wrote: > In 2.6, first paragraph: the historical discussion going back to the previous > century is very confusing to a newcomer: instead of saying what a cookie is, > we tell a story. I suggest to remove

Re: [IPsec] Issue #150: What happens if the peer receives TEMPORARY_FAILURE and does not understand it

See my earlier mail exchange with Tero. That section is descriptive, not prescriptive, and we should describe why the (new) message sequence works fine with older clients, even though they obviously don't support the new notification. What you say below may be sufficient: there's stale state lyi

[IPsec] Issue #154: Sending dummy messages during rekey

Sec. 2.8: "An initiator MAY send a dummy message on a newly created SA if it has no messages queued in order to assure the responder that the initiator is ready to receive messages." A dummy (higher level protocol) message on an IPsec SA is way out of scope. Whether such messages even exist is

Re: [IPsec] Issue #138: Calculations involving Ni/Nr

I agree, and I don't think you need brackets: only the first 64 bits of Ni and the first 64 bits of Nr are used in calculating SKEYSEED, but all the bits are used for input to the prf+ function. (although I personally did not find it confusing) On Jan 19, 2010, at 4:25 AM, Paul Hoffman wrote: