Subject: RE: Peer liveliness

From: suren <[email-masked]>
Date: Thu, 15 May 2003 11:41:10 -0700

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

---

From: Michael Richardson <[email-masked]>
Date: Thu, 15 May 2003 16:49:10 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "suren" == suren  <[email-masked]> writes:
    suren> The mechanism you suggested (INITIAL-CONTACT + rebooted-peer
    suren> initiating IKE (with those two conditions) + aliveness detection)
    suren> may not work with in the scenario of a roaming client.

  I partially agree.
  I think that DPD can be made to work for most remote-access scenarios.

    suren> Suppose, a Roaming client (with a dynamic IP address) tunnels to a 
    suren> Corporate network, and corporate SG is acting as responder only.
    suren> Now if  
    suren> corporate SG is rebooted, it is not able to send INITIAL_CONTACT

  The situation of rebooting the SG is not an isolated case.

  This is a general problem with any system where all the policy is not known
at boot time. In the end game of IPsec on every host, and applications asking
for security, this will be very common.
  The Opportunistic Encryption system that the FreeS/WAN team has developped
has this problem as well.

  I have been working on a system of birth certificates, as first suggested by
Bill Summerfeld. In such a system, when a system receives an ESP (AH) packet
with an unknown SPI, it emits a digitally signed message giving its boot
count. The signature need only been done once per boot.

  If one receives such a message, and it is greater than a boot count sent
in IKE for that connection, then one starts phase 1 again. Sounds simple,
doesn't it?

  There are a number of details that need to be resolved:
  1) what is the form of the message? ICMP? UDP to port 500?
     ICMP may be hard for the IKE daemon to actually get, but is 
     architecturally cleaner.

  2) the signature block should be kept as simple as possible.
     What is the host has multiple identities?
     Is the IP address that one originates included in the signature?

  3) the boot count keeps replays from previous reboots, but
     does not keep the packet from the current reboot from being 
     replayed, causing potential DOS on IKE.

     As such, I'd want to have the IKE do some kind of acclerated
     DPD in IKE when it gets this signal that the host has rebooted.
     
     An attacker could also be generating ICMP port unreachables as well.

    suren> Suren.

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

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [