[strongSwan-dev] Force separate CHILD SA negotiation

[Tobias Brunner]

Hi Emeric,

> Is there a way not to negotiate the first CHILD SA during the IKE_AUTH message (i.e. force the CREATE_CHILD_SA message?)

No, currently not.  What's your use case for this?

> I think it would require to implement the RFC6023?

Yes, or creating some dummy CHILD_SA during IKE_AUTH.

> Would that be a hard work to do?

The responder side is relatively straight forward.  For proper support
we'd have to send the notify defined in that RFC in the IKE_SA_INIT
response and could handle incomplete IKE_AUTH messages a bit nicer than
we currently do.  With the extension the initiator does not explicitly
indicate that it doesn't want to establish a CHILD_SA with the IKE_SA,
the responder will just receive an incomplete IKE_AUTH message and has
to deduce from what's missing that the initiator is correctly
implementing RFC 6023 and not merely sending an invalid message.
Currently, if these payloads are missing this will result in a failure
to create the CHILD_SA.  Something like "traffic selectors (null) ===
(null) inacceptable" will be logged.  But since this is not treated as
fatal error, by default, the IKE_SA will just be kept established
without a CHILD_SA (depends on charon.close_ike_on_child_failure).  This
behavior is actually (mis-)used for the mediation extension, where
connections to the mediation server don't have a CHILD_SA.

The initiator side is a bit trickier.  While creating an IKE_SA without
any CHILD_SAs is technically already possible (again due to the
mediation extension), creating the first CHILD_SA delayed is currently
not (except perhaps by creating an empty IKE_SA first and then manually
initiating the CHILD_SA).  And this can currently not be controlled, all
management tools initiate CHILD_SAs and only implicitly IKE_SAs.  Also,
initiating childless IKE_SAs does currently not depend on whether the
responder supports RFC 6023 or not (the mediation extension predates
that RFC), so this could result in a failed IKE_SA after receiving an
INVALID_SYNTAX notify (or a DELETE after the creation finished
successfully but the peer deletes the IKE_SA due to the failed CHILD_SA).
Another question is whether there should be a graceful fallback on
creating the CHILD_SA during the IKE_AUTH exchange if the peer does not
support the extension or if the SA is just aborted in that case (the
latter is easier to implement, in particular if there is no CHILD_SA to
initiate).
Then there is the question how this is configured.  One possibility
might be the following setting for connections defined in the
swanctl.conf `connections` section:

  childless = allow|never|force

  allow (default) = Create CHILD_SA during IKE_AUTH exchange but
    accept childless IKE_SAs as responder (i.e. send the notify defined
    in RFC 6023 and handle modified IKE_AUTHs properly)
  never = Create CHILD_SA during IKE_AUTH exchange but, as responder,
    fail if initiator tries to create a childless IKE_SA (i.e. don't
    send the notify, and actually fail if payloads are missing or the
    creation fails for other reasons, so this implicitly enables
    charon.close_ike_on_child_failure for this connection during the
    IKE_AUTH exchange - perhaps also later)
  force = Create a childless IKE_SA and create the CHILD_SA, if any,
    with a separate CREATE_CHILD_SA exchange, abort if the responder
    does not support childless IKE_SAs, as responder this is the same
    as `allow`

With this we could also add a `swanctl --initiate --ike` command (in
addition to the existing `--initiate --child` command) and, if the
setting is set to `force`, allow initiating only the IKE_SA without any
CHILD_SAs (and use the same mechanism for mediation connections).

Regards,
Tobias