[strongSwan-dev] handling phase 2 creation with Juniper SRX - is this a bug?

[SM K]

I am running some tests with Strongswan 5.1.2 and a Juniper SRX 100
firewall, in a site-to-site configuration using IKEv1. The juniper is the
initiator of the tunnel. I see a problem with setting up phase 2
connections when the firewall is expiring phase 2s.

The sequence of messages that flows is
Initiator (Juniper SRX)                        Responder (Strongswan 5.1.2)
Quick Mode (1)                  -->
                                        <--           Quick Mode (2)
Informational Msg (D-1)       -->
Informational Msg (D-2)       -->
Quick Mode (3)                  -->


The two informational messages D-1 and D-2 are delete messages for the two
SAs the FW is expiring.

This sequence of messages causes the quick mode task to get into a weird
state. This is how it happens.
1. When the first quick message is received, the quick mode task
(quick_mode_t in src/libcharon/sa/ikev1/tasks/quick_mode.c)  is in QM_INIT
state.
2. When the response is sent back to the initiator, the quick_mode task is
now in QM_NEGOTIATED state, needing more to complete the phase 2 setup.
3. When the Informational Msg (D-1) is received, task_manager_v1 goes
through its set of passive tasks and gives them this message.
4. One of the passive tasks is the quick mode task that is waiting for the
third message in the quick mode handshake. When this task receives the
informational message, it is in QM_NEGOTIATED state. There is a check in
 process_r function of this task that causes it to return SUCCESS when
a INFORMATIONAL_V1 message is received in QM_NEGOTIATED state.
5. When quick_mode_t::process_r returns with a SUCCESS, task_manager_v1
 removes the task from its list and destroys it.
6. When Quick Mode (3) finally arrives, it is given to a new quick mode
task, that is now in QM_INIT state. This task now fails because the quick
mode task expects an SA payload in the message and Quick Mode (3)  only has
the HASH.
7. At this point the phase 2 connection that was being setup is dead and
the initiator and responder are out of sync.


I made a small fix and tried it out. It seems to work for me now.  The fix
was to return NOT_SUPPORTED in quick_mode_t::process_r when a
INFORMATIONAL_V1 message is received in QM_NEGOTIATED state. In
process_request in src/libcharon/sa/ikev1/task_manager_v1.c, when a task
returns NOT_SUPPORTED, i continue to the next task in the enumeration
(without sending a response). I could not find an appropriate return code
to use instead of NOT_SUPPORTED.

This seems to work for me. I want to know if this would be a valid fix for
the situation. Without this fix, the tunnel between the SRX and strongswan
is unusable after the first rekey.

regards,
smk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/dev/attachments/20140709/1658bdd3/attachment.html>