From: The IESG <iesg-secretary(_at_)ietf(_dot_)org>
To: IETF-Announce <ietf-announce(_at_)ietf(_dot_)org>
Cc: lwip(_at_)ietf(_dot_)org
Subject: Last Call: <draft-ietf-lwig-ikev2-minimal-02.txt> (Minimal IKEv2) to
Informational RFC
Date: Fri, 18 Sep 2015 07:27:27 -0700
The IESG has received a request from the Light-Weight Implementation
Guidance WG (lwig) to consider the following document:
- 'Minimal IKEv2'
<draft-ietf-lwig-ikev2-minimal-02.txt> as Informational RFC
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf(_at_)ietf(_dot_)org mailing lists by 2015-10-02. Exceptionally, comments
may be
sent to iesg(_at_)ietf(_dot_)org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.
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.
- Support for sending an empty INFORMATIONAL message is included. I
assume this is to allow full implementations to do liveness probes.
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.
- 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.
- 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.
Paul