Re: Revised notify_delete-2.00.diff, was Re: delete-sa-01 test

-----BEGIN PGP SIGNED MESSAGE-----


On Wed, 12 Feb 2003, Michael Richardson wrote:

> >>>>> "Sam" == Sam Sgro <[email protected]> writes:
>     Sam> You've checked in a version of the patch that has removed the notify
>     Sam> code for now. It appears to work. east-console.txt was incorrect. I
>     Sam> need to revert it to 1.6 for the test to pass.
> 
>   No, it is not.
>   The final ipsec auto --status checks to see if the ISAKMP SA is gone.
>   it is not, which is why the test fails.

I don't see how that is true. What follows is a detailed analysis.


First off, I have two test systems here I can work with: ibis and rook.  They
are analogous to "east" and "west" in the test. I've got them both patched
with delete-notify code. Here is the output of ipsec auto --status on ibis
before the connection is initiated from rook:

000 interface ipsec0/eth0 66.199.183.100 
000 
000 "ibisrook": 66.199.183.100---66.199.183.97...%any 
000 "ibisrook":   ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s;  
rekey_fuzz: 100%; keyingtries: 1 
000 "ibisrook":   policy: PSK+ENCRYPT+TUNNEL+PFS; interface: eth0; unrouted 
000 "ibisrook":   newest ISAKMP SA: #0; newest IPsec SA: #0; eroute owner: #0 
000
000



In the output of east (from OUTPUT/east-console.txt), you see something
similar at this stage of the test:

east:~#
 ipsec auto --status
000 interface ipsec0/eth1 192.1.2.23
000  
000 "SAwest-east": 192.1.2.23[@east]---192.1.2.45...%any[@west]
000 "SAwest-east":   ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s; 
rekey_fuzz: 100%; keyingtries: 1
000 "SAwest-east":   policy: RSASIG+ENCRYPT+TUNNEL+PFS; interface: eth1; 
unrouted
000 "SAwest-east":   newest ISAKMP SA: #0; newest IPsec SA: #0; eroute owner: 
#0
000  
000  


The connection is brought up, and then brought back down again on rook. Here
is the log output from ibis showing the reception of the Delete SA, and the
connection instance with rook being destroyed:

Feb 13 01:01:49 ibis Pluto[2692]: "ibisrook"[1] 66.199.183.102 #1: responding 
to Main Mode from unknown peer 66.199.183.102
Feb 13 01:01:49 ibis Pluto[2692]: "ibisrook"[1] 66.199.183.102 #1: sent MR3, 
ISAKMP SA established
Feb 13 01:01:49 ibis Pluto[2692]: "ibisrook"[1] 66.199.183.102 #2: responding 
to Quick ModeFeb 13 01:01:50 ibis Pluto[2692]: "ibisrook"[1] 66.199.183.102 
#2: IPsec SA established
Feb 13 01:01:54 ibis Pluto[2692]: "ibisrook"[1] 66.199.183.102 #1: received 
Delete SA payload: deleting IPSEC State #2
Feb 13 01:01:54 ibis Pluto[2692]: "ibisrook"[1] 66.199.183.102 #1: received 
Delete SA payload: deleting ISAKMP State #1
Feb 13 01:01:54 ibis Pluto[2692]: "ibisrook"[1] 66.199.183.102: deleting 
connection "ibisrook" instance with peer 66.199.183.102

- From experience, I know that both Delete SA requests must be received before 
the connection instance is brought down. 

The output of ipsec auto --status on ibis shows that, post Delete SA, the 
connection instance has been deleted. The output matches the state before any 
attempt by rook to connect.

[root@ibis root]# ipsec auto --status
000 interface ipsec0/eth0 66.199.183.100
000  
000 "ibisrook": 66.199.183.100---66.199.183.97...%any
000 "ibisrook":   ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s; 
rekey_fuzz: 100%; keyingtries: 1
000 "ibisrook":   policy: PSK+ENCRYPT+TUNNEL+PFS; interface: eth0; unrouted
000 "ibisrook":   newest ISAKMP SA: #0; newest IPsec SA: #0; eroute owner: #0
000  
000  

I can ping ibis in the clear after the tunnel has been brought down.

When I run delete-sa-01 and examine the console output on west
(OUTPUT/westconsole-fixed.txt), I see that the ping test from west succeeds.  
With the Delete SA code, it should, as it would only succeed if the connection
on east was taken down.

When I examine OUTPUT/eastconsole-fixed.txt, I see something very analogous to
what I observe with ibis and rook, shown above:

east:~#
 ipsec auto --status
000 interface ipsec0/eth1 192.1.2.23
000  
000 "SAwest-east": 192.1.2.23[@east]---192.1.2.45...%any[@west]
000 "SAwest-east":   ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s; 
rekey_fuzz: 100%; keyingtries: 1
000 "SAwest-east":   policy: RSASIG+ENCRYPT+TUNNEL+PFS; interface: eth1; 
unrouted
000 "SAwest-east":   newest ISAKMP SA: #0; newest IPsec SA: #0; eroute owner: 
#0
000  
000  
east:~#


However, the test fails as the east console output doesn't match. Why? Here is 
eastconsole.diff:

- --- east-console.txt    Wed Feb 12 00:39:18 2003
+++ OUTPUT/eastconsole-fixed.txt        Thu Feb 13 00:09:24 2003
@@ -91,6 +91,11 @@
  ipsec auto --status
 000 interface ipsec0/eth1 192.1.2.23
 000  
+000 "SAwest-east": 192.1.2.23[@east]---192.1.2.45...%any[@west]
+000 "SAwest-east":   ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s; 
rekey_fuzz: 100%; keyingtries: 1
+000 "SAwest-east":   policy: RSASIG+ENCRYPT+TUNNEL+PFS; interface: eth1; 
unrouted
+000 "SAwest-east":   newest ISAKMP SA: #0; newest IPsec SA: #0; eroute owner: 
#0
+000  
 000  
 east:~#

- From v1.7 of east-console.txt, this is the output of the final ipsec auto 
- --status, and why the test fails. This is the code chunk we disagree on.

east:~#
 ipsec auto --status
000 interface ipsec0/eth1 192.1.2.23
000  
000  
east:~#


This output doesn't reflect what I've seen upon a successful delete of both
IPSEC and ISAKMP SAs using Mathieu's code either virtually (UML) or with real
world machines, as I've demonstrated above.

If the ISAKMP SA were not deleted, and only the IPSEC SA were deleted, then I 
expect the output of ipsec auto --status would mimic that seen when an IPSEC 
SA is allowed to expire (employing a short keylife on rook and rekey=no):

[root@ibis root]# ipsec auto --status
000 interface ipsec0/eth0 66.199.183.100
000  
000 "ibisrook"[2]: 66.199.183.100---66.199.183.97...66.199.183.102
000 "ibisrook"[2]:   ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s; 
rekey_fuzz: 100%; keyingtries: 1
000 "ibisrook"[2]:   policy: PSK+ENCRYPT+TUNNEL+PFS; interface: eth0; 
prospective erouted
000 "ibisrook"[2]:   newest ISAKMP SA: #3; newest IPsec SA: #0; eroute owner: 
#0
000 "ibisrook": 66.199.183.100---66.199.183.97...%any
000 "ibisrook":   ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s; 
rekey_fuzz: 100%; keyingtries: 1
000 "ibisrook":   policy: PSK+ENCRYPT+TUNNEL+PFS; interface: eth0; unrouted
000 "ibisrook":   newest ISAKMP SA: #0; newest IPsec SA: #0; eroute owner: #0
000  
000 #3: "ibisrook"[2] 66.199.183.102 STATE_MAIN_R3 (sent MR3, ISAKMP SA 
established); EVENT_SA_REPLACE in 3305s; newest ISAKMP
000  

... which v1.7 of east-console.txt doesn't reflect.

v 1.7 would indicate the deletion of the connection itself from Pluto's
internal database. Here is output from ibis and rook which would match your
code: 

[root@ibis root]# ipsec auto --delete ibisrook
[root@ibis root]# ipsec auto --status
000 interface ipsec0/eth0 66.199.183.100
000  
000  
000  

Deletion of the roadwarrior connection isn't the the goal here:  deletion of
the connection instance is. There is a statement about security policy here,
as defined in the code: "If we have no SAs for a Roadwarrior connection
instance, unroute and delete that connection instance." Non-roadwarrior
connections that employ auto --add do not appear to be unrouted.


- -- 
Sam Sgro
[email protected]

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv
Comment: For the matching public key, finger the Reply-To: address.

iQCVAwUBPkspykOSC4btEQUtAQHCJwQAmnARgw7nryipAvOhH+1Qr7eq6Lz+KiTh
d+WAQA6C4OVgyxtkjdbpGe6rhNHpxR8qaG6xVmzuBbaEK3ibepW+sQFU3cu03cfH
o2rOFt3qYhcgvasj5dOjcxTOLpx1ayk93Jt7B8lRIRa8WljTiwFLnqSOAu/uC8Dl
5uug5lNM23c=
=jb/U
-----END PGP SIGNATURE-----