Subject: Re: Peer liveliness

From: Ravi <[email-masked]>
Date: Mon, 05 May 2003 09:50:31 +0530

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.

     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.

     I feel that having a standard and interoperable mechanism to detect the dead
     tunnels will solve the problem.
regards,
Ravi

Gregory Lebovitz wrote:

> [WE] won't achieve interoperability unless it's mandated that 
>[IMPLEMENTORS] must
>  
>
>>reply INVALID_SPI (in clear or initiate IKE back to the 
>>sender) whenever it
>>receives bad spi packets.  Current IKEv2 draft doesn't 
>>address this issue
>>(only states you MAY reply a clear notify message).
>>
>>IKEv1 vendors has implemented many ways to solve it which leave poor
>>interoperability.  We should just pick a method and clarify 
>>it in IKEv2. 
>>===============
>>Michael Shieh
>>
>>    
>>
>
>We have been having quite a debate in the ICSA IPsec consortium mail list
>recently trying to figure out how to handle this in IKEv1 (YES, STILL!!!)
>
>Here is what we know for sure of this problem statement:
>(a) detecting liveness/deadness of peer is a good thing, but does not solve
>all the failure cases in and of itself
> (b) the behavior of a recently rebooted device when it receives an
>encrypted packet for an SPI or IKE-SA not in its SADB MUST be mandated, or
>else implementations will not interoperate (as is the case in IKEv1, 5 years
>later).
> (c) the behavior of a peer that receives a new IKE from a peer that it has
>an existing IKE-SA with (i.e. the rebooted peer that is trying to initiate a
>new connection) MUST be mandated, or else implementations will not
>interoperate (as is the case in IKEv1, 5 years later).
>
>Darren Dukes wrote:
>  
>
>>I believe INVALID_SPI does what you are looking for.  If I receive an
>>INVALID_SPI notify via an IKE SA I know to delete the SA and 
>>traffic will
>>bring up a new one.  
>>    
>>
>
>I don't believe this will work, since it assumes that an IKE SA is
>established. In the scenario, the IKE-SA would have been lost along with the
>SPI of the CHILD-SA by the rebooted peer. 
>
>Recommendations to solve the solution:
>- the empty notify as an aliveness check is a good idea. It accomplishes
>what the DPD draft did. Keep using this.
>
>- do what you can to use empty notify to detect dead peer ASAP. The faster
>the persisting peer can delete the old SPI and IKE-SA, the better. The best
>case is for Persisting Peer to detect death and initiate new IKE to rebooted
>peer before rebooted peer gets packets with old SPI, IKE-SA.
>
>- On the Rebooted peer side: If an implementation receives a protected
>packet from an unkown SPI,  
> - simply relying on sending back an unprotected INVALID_SPI is not a good
>idea. It is too easy to DoS the persisting peer by simply spoofing the
>rebooted peer's address.
> - initiate IKE to the persisting peer.
>
>- On the Persisting Peer:
> - If you get a new IKE request from a peer already in your SADB, respond
>with the under-attack, 6 message method. This will mitigate the DoS attack.
>If you get all the way through SA and TS negotiation successfully, you are
>assured (unless I'm missing something) that this really is your peer, and
>that he re-initiated because he lost the original IKE-SA. Start using the
>new IKE-SA and the new CHILD-SA and delete the previous ones after some wait
>period.
>
>Would this proposal explicitly solve things?
>
>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>

---

From: [email-masked]
Date: Sat, 10 May 2003 22:36:47 -0400

I believe that the current IKEv2 spec addresses this issue in a way that
puts minimal requirements on implementations, guarantees interoperability
(though with less than ideal convergence time), and allows implementations
to do better.

But it's quite possible that I don't understand all of the things that
could go wrong, or have inadequately expressed what implementations MUST
do, or just plain screwed up.

The implementation requirements for robust interoperability are:

(1) An IKE SA and all of its associated child SAs fail together. You aren't
allowed a "partial crash" where some of the state is lost but some is kept.
This will fall out naturally in most implementations, but may require some
modular designs to have different modules poll one another for liveness.

(2) A node may not send on a set of SAs associated with a single IKE SA
indefinitely without hearing something back. If it hears nothing for long
enough, it should send an IKE message requiring a reply, and if no reply
comes it must declare all of the SAs dead.

(3) A node that has packets to send according to its SPD and no SA to send
them on must periodically attempt to open an SA for them.

I believe these three requirements along guarantee that the right thing
will happen eventually. But it doesn't prescribe what the timers should be.
So it's possible it will take unacceptably long for things to converge. (If
network delays are long enough and timeouts short enough, the system could
fail to work at all, but I believe that problem is unavoidable).

The problem with more sophisticated strategies is that they may be
exploitable for denial of service attacks. Anyone can forge an INVALID_SPI
notification message from an IP address of their choice (since such a
message is not cryptographically protected). If such a message were
sufficient to cause its recipient to shut down and restart the SA, it would
be a very effective attack. So the spec says that such a message may be
used only as a hint to a problem - for example to trigger a
cryptographically protected liveness test. This will cause the failure to
be detected more quickly, but will never cause one to be detected falsely.

Similarly, the INITIAL_CONTACT notification can be used when setting up an
SA to assure the other end that it should abandon any SAs it has open to
the same identity. This is useful in - for example - the firewall case
where an identity is tied to a single box and it would be an error for that
box to bring up two connections at once. It would not be useful in the case
of a user who is allowed to remotely log in from multiple workstations at
the same time. Again, this makes convergence happen faster while never
making the wrong thing happen.

Responding to the individual comments below...

> > interoperability.  We should just pick a method and clarify
I think we did, but if you don't think it works, explain why.

> all the failure cases in and of itself
Which ones does it not solve?

> else implementations will not interoperate (as is the case in IKEv1, 5
years
Can you give an example of how two implementations following IKEv2 could
fail to interoperate?

> interoperate (as is the case in IKEv1, 5 years later).
I believe it is mandated that the new IKE-SA must be accepted, and the old
one either closed immediately or closed after a timeout, though perhaps
that's just what I was thinking and not what I wrote. Is there anything
specific you would recommend?

> SPI of the CHILD-SA by the rebooted peer.
Until a new IKE-SA is established, any INVALID_SPI message would be
cryptographically unprotected and therefore not to be taken as other
than a hint. If a new IKE-SA is established, the INVALID_SPI could
be taken as trustworthy and used to abandon the old SA. Without the
INVALID_SPI message, abandonment would still happen but it would take
longer.

> what the DPD draft did. Keep using this.
Generating them is not mandated, but the ability to respond to them is.

> peer before rebooted peer gets packets with old SPI, IKE-SA.
If the rebooted peer knows that the SA is needed, it can do that. If it
sets them up based on traffic, it has to wait until a packet comes in from
one side or the other.

>  - initiate IKE to the persisting peer.
This is allowed, although sending what looks like protected messages from
randomly chosen IP addresses to cause the node to attempt lots of IKE
connections is also a plausible DOS attack. Sending the INVALID_SPI message
will tell the other end to probe this end for liveness and initiate its own
new IKE connection if that liveness test fails. That's the path guaranteed
to work. Others will speed things up if implementations choose to do them.

> new IKE-SA and the new CHILD-SA and delete the previous ones after some
wait
Only if there is an INITIAL_CONTACT notification message. Otherwise it's
possible that the peer is opening multiple IKE SAs, perhaps because he is
replicated. In some configurations this might be acceptable. In firewall to
firewall tunnels, it would not and an implementation might reasonably treat
any IKE-SA as an INITIAL_CONTACT.

> Would this proposal explicitly solve things?

      --Charlie

---

From: Ravi <[email-masked]>
Date: Thu, 15 May 2003 10:28:49 +0530

Hi,
  In IKEv2, the IKE SA are bound to the IPSEC SA and IPSEC SAs (Child
  SAs) are deleted whenever IKE SA is dead. Due to this, I don't see any
  problem with the approach mentioned in IKEv2 specifications. But, in
  IKEv1, this binding is not mandated and IPSEC SA can exist without
  corresponding IKE SA. This is where I see problem and current DPD
  specification does not seem to be considering this. I was proposing
  before, the need for Dead Tunnel detection on the remote SGs. I plan to
  come out with draft in 1 to 2 weeks on this. It is only applicable
  for IKEv1 implementations.

Regards
Ravi

[email-masked] wrote:
>>(a) detecting liveness/deadness of peer is a good thing, but does not
> 
> solve
> 
>>encrypted packet for an SPI or IKE-SA not in its SADB MUST be mandated,
> 
> or
> 
>>else implementations will not interoperate (as is the case in IKEv1, 5
> 
> years
> 
>>later).
> 
>> (c) the behavior of a peer that receives a new IKE from a peer that it
> 
> has
> 
>>an existing IKE-SA with (i.e. the rebooted peer that is trying to
> 
> initiate a
> 
>>established. In the scenario, the IKE-SA would have been lost along with
> 
> the
> 
>>- do what you can to use empty notify to detect dead peer ASAP. The
> 
> faster
> 
>>the persisting peer can delete the old SPI and IKE-SA, the better. The
> 
> best
> 
>>case is for Persisting Peer to detect death and initiate new IKE to
> 
> rebooted
> 
>> - simply relying on sending back an unprotected INVALID_SPI is not a
> 
> good
> 
>>with the under-attack, 6 message method. This will mitigate the DoS
> 
> attack.
> 
>>If you get all the way through SA and TS negotiation successfully, you
> 
> are
> 
>>new IKE-SA and the new CHILD-SA and delete the previous ones after some
> 
> wait
> 
>>period.
>>
> 

--