isakmpd: phase-1 SA hangs around after DELETE received ... clients on a dial up - line down/up then reconnect fail...

["Tariq Rashid" <tariq@inty.net>]

a common issue is when an iskampd server is on an always on line
(leased?)... but other client isakmpds are on dialups... the dynamic ip
problem was overcome using aggressive mode/UFQD ... but recent isakmpds
(from cvs 03-01-02) ... seem to break the reconnection... i tried to trace
the source of this and i think its the following:

i think the isakmpd (latest from CVS) does not delete SA phase-1 correctly
when the server isakmpd (passive connections) is sent a DELETE from a client
isakmpd (after the client is sigtermed):

before on server:

root@inty.unconfigured:/# killall -USR1 isakmpd; cat /var/run/isakmpd.report
| grep sa_rep
101146.659398 Report> sa_report: 0x8081a00 IPSEC-channel1 phase 2 doi 1
flags 0x1
101146.659453 Report> sa_report: icookie e99a31c96e00e343 rcookie
0d3f3a26f1e8f980
101146.659467 Report> sa_report: msgid 29a5c670 refcnt 3
101146.659481 Report> sa_report: life secs 1200 kb 0
101146.659493 Report> sa_report: suite 1 proto 3
101146.659508 Report> sa_report: spi_sz[0] 4 spi[0] 0x80ae190 spi_sz[1] 4
spi[1] 0x80ae230
101146.659574 Report> sa_report: initiator id: user-cff5022aaf, responder
id: ac10010a: (null), src: 172.16.1.10 dst: 172.16.1.11
101146.659588 Report> sa_report: spi[0]:
101146.659615 Report> sa_report: spi[1]:
101146.659645 Report> sa_report: 0x8081b00 ISAKMP-peer-int_server phase 1
doi 1 flags 0x1
101146.659660 Report> sa_report: icookie e99a31c96e00e343 rcookie
0d3f3a26f1e8f980
101146.659673 Report> sa_report: msgid 00000000 refcnt 3
101146.659686 Report> sa_report: life secs 3600 kb 0
101146.659699 Report> sa_report: suite 1 proto 1
101146.659713 Report> sa_report: spi_sz[0] 0 spi[0] 0x0 spi_sz[1] 0 spi[1]
0x0
101146.659753 Report> sa_report: initiator id: user-cff5022aaf, responder
id: ac10010a: (null), src: 172.16.1.10 dst: 172.16.1.11

after on server:
root@inty.unconfigured:/# killall -USR1 isakmpd; cat /var/run/isakmpd.report
| grep sa_rep
101154.649547 Report> sa_report: 0x8081b00 ISAKMP-peer-int_server phase 1
doi 1 flags 0x1
101154.649609 Report> sa_report: icookie e99a31c96e00e343 rcookie
0d3f3a26f1e8f980
101154.649623 Report> sa_report: msgid 00000000 refcnt 3
101154.649637 Report> sa_report: life secs 3600 kb 0
101154.649650 Report> sa_report: suite 1 proto 1
101154.649664 Report> sa_report: spi_sz[0] 0 spi[0] 0x0 spi_sz[1] 0 spi[1]
0x0
101154.649728 Report> sa_report: initiator id: user-cff5022aaf, responder
id: ac10010a: (null), src: 172.16.1.10 dst: 172.16.1.11

the kernel itself reports that all SAs are cleared (on freebsd this is doen
with setkey -D).

my "circumventing patch" is in message.c and is ugly: it simply does not
drop connections for "existing SAs"... :
  if (setup_isakmp_sa)
    {
      /*
       * This might be a retransmission of a former ISAKMP SA setup message.
       * If so, just drop it.
       * XXX Must we really look in both the SA and exchange pools?
       */
      if (exchange_lookup_from_icookie (buf + ISAKMP_HDR_ICOOKIE_OFF)
	  || sa_lookup_from_icookie (buf + ISAKMP_HDR_ICOOKIE_OFF))
	{
	  /*
	   * XXX Later we should differentiate between retransmissions and
	   * potential replay attacks.
	   */
	  LOG_DBG ((LOG_MESSAGE, 90,
		    "message_recv: dropping setup for existing SA"));
	  // TR ... message_free (msg);             <---- ignore
	  // TR ... return -1;                      <---- ignore
	  fprintf(stderr, "\n ++++++++ TR: ignoring existing SA... \n");
fflush(stderr);
	}
    }

why on earth is the SA phase-1 hanging around.... it does NOT happen with
PGPNet 7.03 (onnecting via aggressive mode, ufqd, acquire virtual id)...

i'd like to fix this as it prevents reconnections: can anyone point me to
the bits of the code that are responsible for the deleting of SAs?

regards

tariq


intY has automatically scanned this email with Sophos Anti-Virus (www.inty.net)