Re: delete-sa-01 test

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


On Fri, 7 Feb 2003, Michael Richardson wrote:

>     Sam> Mathieu: given that both SAs are in the process of being deleted, is
>     Sam> there a logic to not sending a delete for the IPSec SA as well?
> 
>   Mathieu, could we ask to to take a look?

I've set up two testing machines locally so I could peruse the logs easily.
Here is debugging output which - it seems to imply the IPSEC Delete SA request
never gets issued from the machine --down'ing the connection.

Some irrelevancies were deleted.

At the time STATE_QUICK_I2 is deleted, the IPSEC SA is not:

Feb  9 02:42:15 rook Pluto[21823]: "ibisrook": terminating SAs using this 
connection
Feb  9 02:42:15 rook Pluto[21823]: "ibisrook" #2: deleting state 
(STATE_QUICK_I2)
Feb  9 02:42:15 rook Pluto[21823]: | no Phase 1 state for Delete
Feb  9 02:42:15 rook Pluto[21823]: | ICOOKIE:  d7 52 c1 a3  48 dc 8d f4
Feb  9 02:42:15 rook Pluto[21823]: | RCOOKIE:  5d ad 90 20  4d 74 06 02
Feb  9 02:42:15 rook Pluto[21823]: | peer:  42 c7 b7 64
Feb  9 02:42:15 rook Pluto[21823]: | state hash entry 3
Feb  9 02:42:15 rook Pluto[21823]: | replace with shunt eroute 
66.199.183.102/32 -> 66.199.183.100/32 => %trap
Feb  9 02:42:15 rook Pluto[21823]: | finish_pfkey_msg: SADB_X_ADDFLOW message 
16 for flow %trap
*snip*
Feb  9 02:42:15 rook Pluto[21823]: | pfkey_get: SADB_X_ADDFLOW message 16
Feb  9 02:42:15 rook Pluto[21823]: | delete [email protected]
Feb  9 02:42:15 rook Pluto[21823]: | finish_pfkey_msg: SADB_DELETE message 17 
for Delete SA [email protected]
*snip*
Feb  9 02:42:15 rook Pluto[21823]: | pfkey_get: SADB_DELETE message 17
Feb  9 02:42:15 rook Pluto[21823]: | delete [email protected]
Feb  9 02:42:15 rook Pluto[21823]: | finish_pfkey_msg: SADB_DELETE message 18 
for Delete SA [email protected]
*snip*
Feb  9 02:42:15 rook Pluto[21823]: | pfkey_get: SADB_DELETE message 18

... but you see the ISAKMP Delete SA request issued here:

Feb  9 02:42:15 rook Pluto[21823]: "ibisrook" #1: deleting state 
(STATE_MAIN_I4)
Feb  9 02:42:15 rook Pluto[21823]: | **emit ISAKMP Message:
Feb  9 02:42:15 rook Pluto[21823]: |    initiator cookie:
Feb  9 02:42:15 rook Pluto[21823]: |   d7 52 c1 a3  48 dc 8d f4
Feb  9 02:42:15 rook Pluto[21823]: |    responder cookie:
Feb  9 02:42:15 rook Pluto[21823]: |   5d ad 90 20  4d 74 06 02
Feb  9 02:42:15 rook Pluto[21823]: |    next payload type: ISAKMP_NEXT_HASH
Feb  9 02:42:15 rook Pluto[21823]: |    ISAKMP version: ISAKMP Version 1.0
Feb  9 02:42:15 rook Pluto[21823]: |    exchange type: ISAKMP_XCHG_INFO
Feb  9 02:42:15 rook Pluto[21823]: |    flags: ISAKMP_FLAG_ENCRYPTION
Feb  9 02:42:15 rook Pluto[21823]: |    message ID:  64 34 b8 16
Feb  9 02:42:16 rook Pluto[21823]: | ***emit ISAKMP Hash Payload:
Feb  9 02:42:16 rook Pluto[21823]: |    next payload type: ISAKMP_NEXT_D
Feb  9 02:42:16 rook Pluto[21823]: | emitting 16 zero bytes of HASH(1) into 
ISAKMP Hash Payload
Feb  9 02:42:16 rook Pluto[21823]: | emitting length of ISAKMP Hash Payload: 
20
Feb  9 02:42:16 rook Pluto[21823]: | ***emit ISAKMP Delete Payload:
Feb  9 02:42:16 rook Pluto[21823]: |    next payload type: ISAKMP_NEXT_NONE
Feb  9 02:42:16 rook Pluto[21823]: |    DOI: ISAKMP_DOI_IPSEC
Feb  9 02:42:16 rook Pluto[21823]: |    protocol ID: 1
Feb  9 02:42:16 rook Pluto[21823]: |    SPI size: 16
Feb  9 02:42:16 rook Pluto[21823]: |    number of SPIs: 1
Feb  9 02:42:16 rook Pluto[21823]: | emitting 16 raw bytes of delete payload 
into ISAKMP Delete Payload

Browsing through the code, it appears that code in ipsec_doi.c decides when 
Delete Payloads will be issued. I believe the error may lie in the send_delete 
function, specifically this chunk of code:

    if (IS_IPSEC_SA_ESTABLISHED(st->st_state)) {
       p1st = find_phase1_state(st->st_connection, TRUE);
       if (p1st == NULL)
       {
           DBG(DBG_CONTROL, DBG_log("no Phase 1 state for Delete"));
           return;
       }
    
       if (st->st_ah.present)
       {
           ns->spi = st->st_ah.our_spi;
           ns->dst = st->st_connection->this.host_addr;
           ns->proto = PROTO_IPSEC_AH;
           ns++;
       }
       if (st->st_esp.present)
       {
           ns->spi = st->st_esp.our_spi;
           ns->dst = st->st_connection->this.host_addr;
           ns->proto = PROTO_IPSEC_ESP;
           ns++;
       }
        
       passert(ns != said);    /* there must be some SAs to delete */
    }

Since I see the "no Phase 1 state for Delete" message, it must get that far. 
Perhaps the if (st->st_esp.present) doesn't accomplish in 2.00 what it did in 
1.99? Mostly just a guess, though.


- -- 
Sam Sgro
[email protected]

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

iQCVAwUBPkY5GkOSC4btEQUtAQHjSgP/S3aoW247qubyF1BtF3tMOgzttDSPz53p
CCifzlhhLLUERjvZmD3V+OHAEAQMxHuh2XqzeOfMYZzy7YTXYjd26KBzQjqYKBNY
qP9VtwqKDSPqRLAM9avd9dhOsg1ed2Noe55la0uaT26htEFyzs8ZAwAWqjZJ62OQ
RlbzIenQIVM=
=Yw9j
-----END PGP SIGNATURE-----