RE: Peer liveliness

[suren <suren@intotoinc.com>]

Gregory,

The mechanism you suggested (INITIAL-CONTACT + rebooted-peer initiating IKE 
(with those two conditions) + aliveness detection) may not work with in the 
scenario of a roaming client.

Suppose, a Roaming client (with a dynamic IP address) tunnels to a 
Corporate network, and corporate SG is acting as responder only.  Now if 
corporate SG is rebooted, it is not able to send INITIAL_CONTACT to the 
Roaming client (dynamic IP address). Corporate SG can not even initiate the 
IKE, since it does not contain IP address of roaming client, which is dynamic.


Suren.

Intoto Inc.
3160, De La Cruz Blvd #100
Santa Clara, CA
www.intotoinc.com


At 01:15 AM 5/15/2003 -0700, Gregory Lebovitz wrote:
>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: eer 
>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.