On Tue, 22 Sep 2015, Tero Kivinen wrote:
- 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"
While I'm normally the first to call out initiator/responder because
ipsec is a peer protocol and not a client/server protocol, in this case,
because you are removing responder code, it is really a client
implementation now. So I do think "client" is more descriptive than
"initiator" in this case, but I won't fight you over it.
- 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.
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? Or did you mean "Support for sending an
empty INFORMATIONAL message" only as an IKE RESPONDER? 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)
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.
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?
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.
- 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.
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? Send a
Delete/notify? The minimal ike client cannot process that informational
message? 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. 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?
- 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.
That's stretching the meaning of "require more code" :)
Paul