[Top] [All Lists]

Re: Last Call: <draft-ietf-lwig-ikev2-minimal-02.txt> (Minimal IKEv2) to Informational RFC (fwd)

2015-09-22 10:05:45
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

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

   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" :)