[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Peer liveliness
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
Gregory Lebovitz wrote:
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: Peer liveliness
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
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.
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
Ph: +91-40-2335 1214 / 1175 / 1184
ROC home page <http://www.roc.co.in>