[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Peer liveliness



To both your and Ravi's point, this method *can* be made to work with
remote-dynamically assigned clients (it's not pretty, and I don't
necessarily recommend the method we've come up with, but it can be done).

In light of my earlier proposal, in the dynamically addressed scenario, the
second condition would fail; the rebooted peer would not be able to find a
match in SPD, so no IKE would be initiated. In this case we would be
depending solely on INITIAL-CONTACT and aliveness detection. So I'll edit
what my proposal to:

"INITIAL-CONTACT + rebooted-peer-initiating-IKE + aliveness detection is the
fastest and most sure way to get an SA back up for fixed ip peers, as it
covers the conditions and responses for both the persistent and
rebooted-peers. "

For case where one side is dynamically addressed, INITIAL-CONTACT +
Aliveness is sufficient, and the speed of recover will depend 100% on (a)
aliveness detection being configured "ON", and (b) the timer configuration
on the persistent peer.

Gregory.



> -----Original Message-----
> From: suren [mailto:suren@xxxxxxxxxxxxx]
> Sent: Thursday, May 15, 2003 11:41 AM
> To: Gregory Lebovitz; 'Ravi'
> Cc: Michael Choung Shieh; 'ddukes@xxxxxxxxx'; ipsec@xxxxxxxxxxxxxxxxx
> Subject: RE: Peer liveliness
> 
> 
> 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@xxxxxxxxx] 
> >Sent: Sunday, May 04, 2003 9:21 PM To: Gregory Lebovitz Cc: 
> Michael Choung 
> >Shieh; ddukes@xxxxxxxxx'; ipsec@xxxxxxxxxxxxxxxxx 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.
>