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
