Re: Peer liveliness

[Ravi <ravivsn@roc.co.in>]

Hi Gregory,
             I agree that Initial-Contact solves the problem most part, 
but not always.It works fine when there are site-to-site tunnels where 
both SGs have static IP addresses. But, this is not the case always
atleast in my part of world. Let me take an example:

Branch office network           Head office network
     |                                       |
     |                                       |
Security Gateway1-----Internet-------Security Gateway2


SG2 has static IP address and that can be configured as
Peer SG IP address in Security Gateway1.
But SG1 does not have static IP address and
it gets the public IP address
via DHCP client OR PPP from ISP.

In the above configuration, SG2 is always
responder and SG1 is always intiator. The way it
works is that, whenever SG1 gets the IP address, it
makes the tunnel with SG2.

Considering above scenario: When SG2 restarts,
since it does not know the SG1's IP address,
it can't send the INITIAL-CONTACT message.

2. There is no way to guarantee that Initial contact
    message is sent/received reliably.
I feel it is always better to find out liveness of tunnel pro-actively, 
rather than entirely depending on peer to inform that it is dead and 
cameback.

Regards
Ravi



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: 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. 
> 


-- 


The views presented in this mail are completely mine. The company is not
responsible for whatsoever.
------------------------------------------------------------------------
Ravi Kumar CH
Rendezvous On Chip (i) Pvt Ltd
Hyderabad, India
Ph: +91-40-2335 1214 / 1175 / 1184

ROC home page <http://www.roc.co.in>