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(_at_)iki(_dot_)fi