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

[Matt Rogers]

On 11/25, Paul Wouters ? wrote:
> 
> 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?
> 

The use of preferred_ike is really just to manually work around this cisco quirk,
and it's kind of a corner case. What you described above may be a better
solution (it doesn't happen that way now) but in practice I don't know if 
it would help avoid the cisco behavior like preferred_ike does.

Matt

> 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.
> 
> _______________________________________________
> Swan-dev mailing list
> Swan-dev at lists.libreswan.org
> https://lists.libreswan.org/mailman/listinfo/swan-dev