Paul Wouters writes: > I hadn't seen this document until now. I've read the document and have some > comments that might require another iteration. Sorry that I did not see > this document before. > > - The title is a bit misleading. This is not a "minimal IKEv2 implementation". > It is a "minimal IKEv2 client implementation". I would like to see > that more clearly specified in the title and abstract so it becomes > clear that two "minimal IKEv2" implementations cannot establish an > IKEv2 connection with each other. More exactly minimal IKEv2 initiator implementation. Changed the title to "Minimal IKEv2 Initiator Implementation" and modified abstract to say that minimal do require more complete version for the other end: Abstract This document describes minimal initiator 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 describes mainly shared secret authentication (IKEv2 requires support for certificate authentication in addition to shared secret authentication). This minimal initiator implementation can only talk to the IKEv2 implementation which supports also acting as responder, thus two minimal initiator implementations cannot talk to each other. > - Support for sending an empty INFORMATIONAL message is included. I > assume this is to allow full implementations to do liveness probes. No, it is included as it is mandatory feature of the IKEv2, and it is not limited only to the empty INFORMATIONAL messages, the full IKEv2 server can also send other kind of Notification payloads inside the INFORMATIONAL exchanges, and minimal version will ignore them. The minimal version still needs to respond to them with empty INFORMATIONAL message, as otherwise it would violate the IKEv2 protocol. > However, if the server this client connects to is restarted, the > client, especially if it only sends answerless data like syslog UDP > packets, has no way of finding out it is sending un-decryptable > messages. And due to minimal ikev2, the server cannot initiate to > the client to recover from this situation. So either this limitation > should be mentioned, or the spec should also include the minimal client > sending empty INFORMATIONAL messages for liveness check. In the use cases we assumed that device is sleeping most of the time, and during the sleeping it will forget all state, including IKEv2 SAs. This is also required, as while the device is sleeping the server might do liveness check, and delete the IKEv2 SA anyways. So every time the device wakes up it creates IKEv2 SA again. I.e what is described in the B.1. I now made it more clear in the use cases section: Those devices are usually sleeping long times, and only wakes up because of user interaction or periodically. The data transfer is always initiated from the sleeping node and after they send packets there might be ACKs or other packets coming back before they go back to sleep. If some data needs to be transferred from server node to the small device, it can be implemented by polling, i.e. small node periodically polls for the server to see if it for example have some configuration changes or similar. While the device is sleeping it will not maintain the IKEv2 SA, i.e., it will always create the IKEv2 SA again when it wakes up. This means there is no need to do liveness checks for the server, as after the device wakes up again the minimal implementation will start from the beginning again. > - It would be nice if the document would add a notification message, so > it can convey via a notification payload that it is a "minimal IKEv2 > client". This will help diagnosing issues later when people > incorrectly try to run these clients using impossible configurations. > Such notification could also help the server in treating these clients > as "INITIAL CONTACT" clients. As those clients are complient IKEv2 peers, I do not think there is need for that. If client want them to be treated as INITIAL CONTACT clients, they can add that notify, or the server might be configure to have very short timeouts for resource cleanup for them. I do not think there is need for such notify. > - It would be nice if the document could state minimal ikev2 also > supports RFC 7619 (AUTH NULL) support, which uses the PSK method as > well so basically no new code needs to be added to support this. This > could increase the usage of minimal ikev2 implementations for Opportunistic > Security against pervasive monitoring. As this document describes minimal IKEv2 initiator implementation using PSK, that would mean that the PSK will authenticate both ends, so there is no point of oding AUTH NULL. Also AUTH NULL would require more code, as it is using different Authentication Method number. Yes, the AUTH NULL is usefull in cases where the initiators have raw public key to authenticate initiator to the server, but initiator does not care who he sends data to, thus does not require server to be authenticated. Added following paragraph to the end of B.2: In these setups it might be possible that the authentication of the server is not needed at all. If the minimal device is sending for example sensor information to the server, the server wants to verify that the sensor is who he claims to be using raw public keys, but sensor does not really care who the server is. In such cases the NULL authentication method ([RFC7619]) would be useful, as it allows devices to do single-sided authentication. -- kivinen@xxxxxx