Paul Wouters writes: > > 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. > > I am confused. Sure, _responding_ to an INFORMATIONAL is mandatory in > IKEv2, so minimal IKE must also do it. But why do you need support > for _sending_ an INFORMATIONAL? In the draft there is only requirement for replying with empty INFORMATIONAL response to the requests. No support for INFORMATIONAL requests is required. > Or did you mean "Support for sending an > empty INFORMATIONAL message" only as an IKE RESPONDER? Where is that text? I cannot find it in the draft. > If so, you should clarify that. If you do mean it should support > sending INFORMATIONAL IKE REQUESTs, you should explain why (and then > also explain related to the below paragraph, why then not support > Delete/Notify) There is no requirement for sending INFORMATIONAL IKE REQUESTS in the draft from the initiator / client, so it would be bit hard to explain what you ask for. Can you tell me which part of the draft has caused you to be confused? In section 2.2 we clearly state: Minimal implementation MUST be able to reply to INFORMATIONAL request by sending empty response back: I.e. we only reply to requests by sending empty response back. No requirement for sending requests is for minimal clients. > So in your use case, I don't understand why the minimal ike client > doesn't just send a Delete/Notify to tear down the IPsec SA. Possibly > you don't want to support sending IKE INFORMATIONAL REQUEST packets? Yep. And sending those are not mandatory, and the server must be able to cope even if we do not send those. To make the draft really minimal we left that out. But on the other hand it was added to the B.1 as it is one of the useful extensions to implement. > And while you changed your use case, you did not actually address the > problem I described above for those clients that do keep an IPsec SA > open. I still think it would be good to mention, and possibly recommend > that minimal IKE clients always setup a new IKE and IPsec SA to prevent > my problem scenario. Such implementation would no longer be minimal, thus it would be something bit more than minimal implementation, but not yet full implementation. That is one of the reasons I do not want to have notify specifying that client is minimal implementation, as the level of minimalness will be different in different cases. Some implementors will implement really the bare minimal. Some will also add support for sending delete notifications. Some use Raw public keys etc. > >> - 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. > > Well no. they cannot detect that the remote endpoint got rebooted other > than by pre-emptively restarting the SA from scratch. Yes, and they cannot cope with IP-address changes, as there is no MOBIKE support, they cannot work across NATs, as there is no NAT traversal, and so on. There is lot of things minimal implementations cannot do, but for the described use case it is useful, and it is still complient to the IKEv2 (with one exception that it does not support certificates). The use case is to wake up, create IKE and IPsec SA, send few packets, go back to sleep. In most cases the send few packets, is really send few packets, and got some kind of ack back, so if there is no ack, the client can try again little bit later (i.e. instead of going to sleep for an hour, only sleep for minute, and then try again). > > 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. > > Even if the server uses very short timeouts, what will it do? After timeout it will do liveness check, i.e., send empty INFORMATIONAL request to the client. If client is still awake and IKE SA is there, it will reply with empty INFORMATIONAL response to it. If not, the server will resend message until it times out, and then deletes the IKE SA. > Send a Delete/notify? It can also do that, but as minimal implementation will ignore the delete, there is no point of that. It should start with liveness check first. > The minimal ike client cannot process that informational message? Section 2.2 do require minimal implementations to be able to receive INFORMATIONAL exchanges, and reply to them with empty INFORMATIONAL response. > Worse, your spec makes it return an empty informational response > which is indistinguishable from the response of a successfull IKE SA > delete, which is also an empty informational. Yes. But server should only do that after liveness check. > So short timeouts would make the situation worse - it > would be like the remote gateway crashed all the time without the > client being able to recover. The only short cut I can see here is > if the minimal IKE client treats all incoming informational messages > as fatal, and deletes the IKE SA with the IPsec SA. So perhaps say > that? No, as that would make liveness checks from the server cause the client to restart. > > 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. > > That's stretching the meaning of "require more code" :) We we are talking about devices having few kB of memory, every single bit count... -- kivinen@xxxxxx