Subject: RE: Peer liveliness

From: Gregory Lebovitz <[email-masked]>
Date: Thu, 15 May 2003 01:15:58 -0700

w/in...

-----Original Message-----
From: Ravi [mailto:[email-masked]]
Sent: Sunday, May 04, 2003 9:21 PM
To: Gregory Lebovitz
Cc: Michael Choung Shieh; [email-masked]'; [email-masked]
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.

---

From: Ravi <[email-masked]>
Date: Fri, 16 May 2003 11:05:25 +0530

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:
>      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
> [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? 
> 
>      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
>      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:
> 
> 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>