Although I am co-chair of ipsecme, please treat these comments as an
individual's.
In general I think a minimal subset of IKEv2 can be very useful. But I
wonder if this is too minimal:
• Bidirectional operation is one of the main advantages of IKE/IPsec
over TLS, so I think allowing only a client-server model is a major
omission. People will want to implement meshes of these small devices.
In your example, the lawnmower talks to the garage door to let it out...
• Raw public keys have very few advantages over shared keys. In a mesh,
you still need to provision all N (public) keys into each of N devices.
On the other hand, certificates (despite their well known problems)
allow for much simpler provisioning, when you need to provision a closed
group of devices and you generate your own CA. What I'd really want is a
profile of 5280 where you just sign the public key but cut off all the
identity and extensions crap. Unfortunately this is unlikely to ever
materialize.
Some Detailed Comments
• Responding to Create Child SA: does it really matter if you respond
with a "syntax error" (i.e. you don't recognize this exchange at all) or
with "no additional SAs"? The sender will tear down the IKE SA anyway.
• Why not omit AH from the minimal implementation?
• I don't understand why Appendix A is needed. And if it is, I don't
think the Cert Request and Cert payloads should be included, if they're
not supported included in the profile.
• Seems to me you should include PRF_HMAC_SHA2_256.
• A.8: For the AUTH payload you can omit DSS.
• Is ID_RFC822_ADDR relevant for this type of devices?
• B.1: I think the Delete payload is not just "nice to have", because
otherwise you have a major resource leak on the server. Which implies
the device needs to send *three* exchange types.
• B.2: "Using Raw Public Keys is much simpler, and it allows similar
scalability than certificates." As noted above, this is true for
client-server setup but not for a meshed group of peers.
Thanks,
Yaron
_______________________________________________
Lwip mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lwip
