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