[Swan-dev] shared IKE SA interop bug with cisco

[Paul Wouters 🔓]

Matt wrote the problem below. I am still confused what exactly is
happening and why we would need his patch for this. I would think
that if we --down tunnelA we should notice the phase1 is still used
by tunnelB and leave/move it around instead?

Paul

Description of problem:

When defining multiple connections to a single peer that differ in IPsec
SA options (peer subnet, etc), depending on the order that the
connections are associated with the host pair, the common IKE SA if
rekeyed by the peer can be associated to a connection different than the
one it started with. For example:

conn base
     left=192.168.1.2
     ...

conn TUNNEL-A
     also=base
     right=192.168.1.10
     rightsubnet=10.0.1.0/24
     ...

conn TUNNEL-B
     also=base
     right=192.168.1.10
     rightsubnet=10.0.2.0/24
     ...

connections are added in this order:
TUNNEL-A
TUNNEL-B

Left initiates with TUNNEL-A and then brings up TUNNEL-B. The IKE SA is
associated with TUNNEL-A. The peer now rekeys the IKE SA, and since
TUNNEL-B was the last connection to be associated with the host pair, it
is found first in the structure (connect_to_host_pair() is performed on
add and results in the last to be connected is the first seen in the
host pair list) . The new IKE SA is now under the TUNNEL-B connection.

This switching is not normally a problem (this can happen pluto to pluto
with no ill effects). However, it has been observed that a Cisco ASA
peer may block IPsec traffic of the peer subnets for both the
switched-from and switched-to connections after the IKE SA is rekeyed
and deleted from the pluto end. So in the example above, if the intent
is to bring TUNNEL-A up temporarily, bring it down and leave TUNNEL-B
active, if TUNNEL-B catches the rekey and the operator deletes the new
IKE-SA, then the ASA will start to block both 10.0.1.0 and 10.0.2.0. If
the IKE SA manages to persist to the original connection then this
behavior isn't seen.

So my proposed solution to work around this is the attached patch, which
adds a conn option of 'preferred_ike=yes|no" with the default of no. For
connections that have a common host pair, setting preferred_ike=yes on
one of them will allow that connection to take priority and respond to
the incoming IKE exchange. This only applies when there is no
discernable policy choice for the connection and overrides what would
normally be a pick of the first negotiable connection in the host pair
list.