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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxx




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]