RE: Peer liveliness

[Gregory Lebovitz <Gregory@netscreen.com>]

w/in...
-----Original Message-----
From: Ravi  [mailto:ravivsn@roc.co.in]
Sent: Sunday, May 04, 2003 9:21  PM
To: Gregory Lebovitz
Cc: Michael Choung Shieh; = 'ddukes@cisco.com'; ipsec@lists.tislabs.com
Subject: Re: = Peer  liveliness




Hi,

In the text below, I also try to use the same terminology used by you.

     Rebooted Peer and Persistent Peer.


     In your email, under 'Recommendations to solve the solution', 
regarding

     second point:

     In my view, whether Peer is alive or not does not solve the 
problem completely.

     Persistent node should know aliveness of Tunnel on the other side. 
It is possible that

     peer reboots and responds to DPD requests, but tunnels are not 
there. We should

     have a mechanism to detect the Tunnel aliveness.

[GML] I think Charlie addressed this by saying that once 
the IKE-SA is revived, one or the other would have sent the 
INITIAL-CONTACT. When this happens, the other peer will delete old SAs, 
including CHILD-SAs. So, once IKE establishes, traffic will cause 
creation of new CHILD-SA (IPsec), so tunnel will come alive. Does this 
address your concern?


     With respect to DoS attack:

     You addressed the issue of DoS attack on the persistent side. I am 
also concerned

     about DoS attack on rebooting machine. If MITM keeps sending the 
packets with

     some dummy SPI and valid source IP, then the IPSEC SG keeps 
sending the

     INVALID_SPI and for this,it keeps creating IKE SAs. That is one of 
the reason, 

     some implementations do not support generationof INVALID_SPI 
notifications.

[GML] I'm not proposing use of 
INVALID_SPI; I specifically said I thought INVALID_SPI was bad. Im 
proposing rebooted-peer initates IKE to sender of invalid SPI if -- and 
ONLY IF-- two conditions are met:


(1) no current valid SAs with 
sender,


(2) sender is valid peer in SPD


These two checks mitigate the DoS issue almost 
completely. (see my other email for discussion of threat analysis on 
this one).


The more I hash this through with various people, the more I'm 
becoming convinced that INITIAL-CONTACT + rebooted-peer initiating IKE 
(with above two conditions) + aliveness detection is the only way to 
catch all the failure cases.


Gregory.