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

[Antony Antony]

On Thu, Dec 04, 2014 at 04:31:50PM -0500, Matt Rogers wrote:
> On 11/30, Paul Wouters ? wrote:
> > On Fri, 28 Nov 2014, Matt Rogers 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.
> > 
> > I don't think it is a corner case. It is a bug on our end. We have one
> > parent that has two children and we delete one child. We shouldn't shoot
> > the parent.
> > 
> I've been hacking on this some and I believe I'm on the right path, but I'd like
> to post what I have so far and get some input. Unfortunately ipsec states don't
> keep track of their IKE state beyond their cloned-from state (which can go away) 
> and newest_isakmp_sa (which won't get updated for the other host pair instances 
> and tends to be #0, see the grepped status below). 
> 
> I have a "connswitch" test that I have not committed yet, that sets up the test as:

can you commit test as a wip? I am curious to see what is going on. I need the same for IKEv2 and CREATE_CHILD_SA.

Have you tried A and B with different authby or with xauth? say one with rsa and the other psk?

> ...
> 004 "TUNNEL-A" #1: STATE_MAIN_I4: ISAKMP SA established {auth=RSA_SIG cipher=aes_256 integ=sha group=MODP2048}
> 002 "TUNNEL-A" #2: initiating Quick Mode RSASIG+ENCRYPT+TUNNEL+PFS+DONT_REKEY+UP+IKEV2_ALLOW+SAREF_TRACK+IKE_FRAG_ALLOW
> 117 "TUNNEL-A" #2: STATE_QUICK_I1: initiate
> 004 "TUNNEL-A" #2: STATE_QUICK_I2: sent QI2, IPsec SA established tunnel mode {ESP=>0xESPESP <0xESPESP xfrm=AES_128-HMAC_SHA1 NATOA=none NATD=none DPD=passive}
> west #
>  ipsec auto --up TUNNEL-B
> 002 "TUNNEL-B" #3: initiating Quick Mode RSASIG+ENCRYPT+TUNNEL+PFS+DONT_REKEY+UP+IKEV2_ALLOW+SAREF_TRACK+IKE_FRAG_ALLOW
> 117 "TUNNEL-B" #3: STATE_QUICK_I1: initiate
> 004 "TUNNEL-B" #3: STATE_QUICK_I2: sent QI2, IPsec SA established tunnel mode {ESP=>0xESPESP <0xESPESP xfrm=AES_128-HMAC_SHA1 NATOA=none NATD=none DPD=passive}
> west #
>  ipsec auto --up TUNNEL-C
> 002 "TUNNEL-C" #4: initiating Quick Mode RSASIG+ENCRYPT+TUNNEL+PFS+DONT_REKEY+UP+IKEV2_ALLOW+SAREF_TRACK+IKE_FRAG_ALLOW
> 117 "TUNNEL-C" #4: STATE_QUICK_I1: initiate
> 004 "TUNNEL-C" #4: STATE_QUICK_I2: sent QI2, IPsec SA established tunnel mode {ESP=>0xESPESP <0xESPESP xfrm=AES_128-HMAC_SHA1 NATOA=none NATD=none DPD=passive}
> west #
> 
> west #
>  ipsec auto --status | grep ISAKMP
> 000 "TUNNEL-A":   newest ISAKMP SA: #1; newest IPsec SA: #2; 
> 000 "TUNNEL-B":   newest ISAKMP SA: #0; newest IPsec SA: #3; 
> 000 "TUNNEL-C":   newest ISAKMP SA: #0; newest IPsec SA: #4; 
> 000 #1: "TUNNEL-A":500 STATE_MAIN_I4 (ISAKMP SA established); EVENT_SA_EXPIRE in  XXs; newest ISAKMP; lastdpd=-1s(seq in:0 out:0); idle; import:admin initiate

I am thinking why #0, why not #1? It probably need more thinking before one decide to stick parent state number in Quick mode Connection. I have ran into same issue in IKEv2. And not sure it is resolved. Curious to see test case. Also it may get tricky with rekey/re-authentication.


-antony