Re: [IPsec] New Version Notification for draft-kivinen-ipsecme-ikev2-minimal-00
I strongly support this draft. It must be useful for the implementers to develop IKEv2 to enable a kind of m2m communication with IPsec. This draft describes a scenario to use IKEv2 for a minimum specification. The document only allows one side to be a responder. I would like to a little extend it. That means it allows both sides to be a responder. Here is an example scenario, in a scenario of smart metering, both a meter and a server have a power line, but the power consumption should be lesser as much as possible. The network is lossy. The resource of the device is typically constrained, for example, memory or physical size. Shoichi Sakane On 2/23/11 11:44 PM, Tero Kivinen wrote: I wrote draft about the minimal IKEv2 implementation. It does not try to change anything in the RFC5996, it just explains what kind of implementation would be useful in some machine to machine communication scenarios and which would still be complient to the RFC5996 (with an exception of not supporting certificates). The document contains 44 pages, from which the actual protocol description is about 5 pages (IKE_SA_INIT and IKE_AUTH). Half of the document is payload format diagrams copied from RFC5996. This document is meant for people who are not using IPsec for VPNs or similar, but are thinking whether IPsec and IKEv2 could be used in for small devices for machine to machine communications. -- A new version of I-D, draft-kivinen-ipsecme-ikev2-minimal-00.txt has been successfully submitted by Tero Kivinen and posted to the IETF repository. Filename:draft-kivinen-ipsecme-ikev2-minimal Revision:00 Title: Minimal IKEv2 Creation_date: 2011-02-23 WG ID: Independent Submission Number_of_pages: 44 Abstract: This document describes minimal version of the Internet Key Exchange version 2 (IKEv2) protocol. IKEv2 is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs). IKEv2 includes several optional features, which are not needed in minimal implementations. This document describes what is required from the minimal implementation, and also describes various optimizations which can be done. The protocol described here is compliant with full IKEv2 with exception that this document only describes shared secret authentication (IKEv2 requires support for certificate authentication in addition to shared secret authentication). This document does not update or modify RFC 5996, but provides more compact description of the minimal version of the protocol. If this document and RFC 5996 conflicts then RFC 5996 is the authoritative description. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fwd: HOKEY draft draft-ietf-hokey-rfc5296bis
In case anyone wonders, my reply to Yaron was basically: I dunno will be interested to find out if you're missing something or not S. On 08/03/11 07:35, Yaron Sheffer wrote: Hi Glen, thank you for your kind words. It is always a pleasure to help a fellow security working group, and your positive and helpful feedback makes it doubly so. Back to the subject at hand: EAP is one of the rare security protocols that are truly reusable. And in fact it is used by multiple protocols, including 802.1X, IKE and the TNC protocols. With success comes responsibility. If your working group makes significant, architectural changes to the protocol, it is *your responsibility* to ensure they can be accommodated by users of the protocol. And in the case of IETF working groups, it is indeed the job of the Security AD to ensure such coordination takes place. ERP is such a major change because (correct me if I am wrong): - Its transport behavior is different from the base EAP, allowing multiple exchanges to be in flight at the same time. - ERP peers actually *degrade* the behavior of EAP, because of timeouts/retransmissions introduced when talking to non-ERP auth servers, and similarly for ERP auth servers with non-ERP peers (this behavior is spelled out quite clearly on p. 8 of the bis draft). PS: I'm glad to hear that 802.1X-2010 supports ERP. I just wonder why the bis draft does not recognize this fact. Best regards, Yaron On 03/08/2011 06:51 AM, Glen Zorn wrote: On 3/6/2011 4:43 PM, Yaron Sheffer wrote: Hi Stephen, I gather you are the incoming responsible AD for HOKEY. ERP (RFC 5296, now reincarnated as a bis document) is one of HOKEY's principal work items. The document is making major changes to EAP, and seems to have gotten a life of its own, despite the fact that AFAIU neither of its protocol users (802.1X and IKEv2) has been changed to accommodate it. It seems to me at best like wasted effort, more likely a disconnect between the working groups. First of all, I'd like to express my deep appreciation ( I think that I can speak for all the members of the hokey WG) for you kind concern for the use of our time. It is especially wonderful since AFAIK you have heretofore shown no interest at all in our activities; to extend yourself in this way for a group with which you have essentially no connection is truly magnanimous; and to go straight to the Area Director, the one person who might be able to save us from this terrible waste of effort time! I must say that I find it hard to express in words how it makes me feel. Nonetheless, I admit to some puzzlement as to the rationale for this action: the referenced draft is a chartered work item of the hokey WG, adopted after a call for consensus from the members. Of course, you could not know about the call since you aren't a WG member but it did occur. So while I do appreciate your obviously deep and selfless concern, I am inclined to let the actual members of the WG decide what (if anything) they deem worthy of effort. But, thanks again! P.S. I'm pretty sure that IEEE 802.1X-2010 supports ERP. Am I missing anything? Thanks, Yaron Original Message Subject: [IPsec] HOKEY draft draft-ietf-hokey-rfc5296bis Date: Sun, 6 Mar 2011 11:25:54 +0200 From: Yoav Nir y...@checkpoint.com To: ipsec@ietf.org ipsec@ietf.org, draft-ietf-hokey-rfc5296...@tools.ietf.org draft-ietf-hokey-rfc5296...@tools.ietf.org Hi all I have just read the subject draft, and found this in section 6 (and similar text in the introduction): Note that to support ERP, lower-layer specifications may need to be revised. Specifically, the IEEE802.1x specification must be revised to allow carrying EAP messages of the new codes defined in this document in order to support ERP. Similarly, RFC 4306 must be updated to include EAP code values higher than 4 in order to use ERP with Internet Key Exchange Protocol version 2 (IKEv2). IKEv2 may also be updated to support peer-initiated ERP for optimized operation. Other lower layers may need similar revisions. Note that this is not new text, and it appears pretty much the same way in RFC 5296. There's the obvious nit with this text, that RFC 4306 is not a reference. If it was, the id-nits would warn about this RFC being obsolete. But that's the small problem here. A bigger problem is that this text says that IKEv2 needs to be updated, but there is no draft for this update, nor has there been any message to this list about this proposed change. The simple change they require is to section 3.16: o Code (1 octet) indicates whether this message is a Request (1), Response (2), Success (3), or Failure (4). I think this could be done with an errata or a 1-page draft, if all that was required was pass-through of codes (5) and (6). But I think it's more involved than that. There's peer-initiated ERP (which would require peer-initiated IKE?) and
Re: [IPsec] New Version Notification for draft-kivinen-ipsecme-ikev2-minimal-00
I also agree that this draft is useful, and I support its going forward, either as a WG document or as an individual document. While data communications may originate from either side (sensor notifies controller, controller queries sensor, controller sends command to actuator), I think it is reasonable to require that IKE be initiated from the thing, for two reasons: 1. It cuts down the required code almost in half 2. The things often sleep for extended periods of time, so you can't depend on them being able to respond. There are two things I'm wondering about, though. Why is this draft written like a mini-RFC5996, instead of just referencing 5996 and describing a profile. You could skip all of Appendix A and much of the explanation in section 2. Also, what happens with SA expiry? According to section 2.1, the thing Cannot send delete payloads in Informational exchanges. I guess it could just create a new IKE SA if its policy says that the old one has expired. But if the SA expires first on the controller, either the thing is sleeping and will miss the DELETE payload, or it's not sleeping, and will ignore the DELETE payload. Either way, you're stuck with an SA that exists on the thing but not on the controller. I can think of three ways to avoid this: You can require that SA lifetimes be always shorter on the thing than on the controller. You can require them to explicitly send SA lifetimes. Or you can require them to implement failure detection. Yoav On Mar 8, 2011, at 3:22 AM, Shoichi Sakane wrote: I strongly support this draft. It must be useful for the implementers to develop IKEv2 to enable a kind of m2m communication with IPsec. This draft describes a scenario to use IKEv2 for a minimum specification. The document only allows one side to be a responder. I would like to a little extend it. That means it allows both sides to be a responder. Here is an example scenario, in a scenario of smart metering, both a meter and a server have a power line, but the power consumption should be lesser as much as possible. The network is lossy. The resource of the device is typically constrained, for example, memory or physical size. Shoichi Sakane On 2/23/11 11:44 PM, Tero Kivinen wrote: I wrote draft about the minimal IKEv2 implementation. It does not try to change anything in the RFC5996, it just explains what kind of implementation would be useful in some machine to machine communication scenarios and which would still be complient to the RFC5996 (with an exception of not supporting certificates). The document contains 44 pages, from which the actual protocol description is about 5 pages (IKE_SA_INIT and IKE_AUTH). Half of the document is payload format diagrams copied from RFC5996. This document is meant for people who are not using IPsec for VPNs or similar, but are thinking whether IPsec and IKEv2 could be used in for small devices for machine to machine communications. -- A new version of I-D, draft-kivinen-ipsecme-ikev2-minimal-00.txt has been successfully submitted by Tero Kivinen and posted to the IETF repository. Filename: draft-kivinen-ipsecme-ikev2-minimal Revision: 00 Title:Minimal IKEv2 Creation_date:2011-02-23 WG ID:Independent Submission Number_of_pages: 44 Abstract: This document describes minimal version of the Internet Key Exchange version 2 (IKEv2) protocol. IKEv2 is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs). IKEv2 includes several optional features, which are not needed in minimal implementations. This document describes what is required from the minimal implementation, and also describes various optimizations which can be done. The protocol described here is compliant with full IKEv2 with exception that this document only describes shared secret authentication (IKEv2 requires support for certificate authentication in addition to shared secret authentication). This document does not update or modify RFC 5996, but provides more compact description of the minimal version of the protocol. If this document and RFC 5996 conflicts then RFC 5996 is the authoritative description. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec Scanned by Check Point Total Security Gateway. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
