[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Peer liveliness



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

Charlie_Kaufman@notesdev.ibm.com wrote:
> 
> 
> 
> 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...
> 
> Gregory Lebovitz <Gregory@netscreen.com> wrote on 04/29/2003:
> 
>> [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
>>>
>>
> I think we did, but if you don't think it works, explain why.
> 
> 
>>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
> 
> Which ones does it not solve?
> 
> 
>> (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).
> 
> Can you give an example of how two implementations following IKEv2 could
> fail to interoperate?
> 
> 
>> (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).
> 
> 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?
> 
> 
>>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.
>>
> 
> 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.
> 
> 
>>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.
>>
> 
> Generating them is not mandated, but the ability to respond to them is.
> 
> 
>>- 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.
>>
> 
> 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.
> 
> 
>>- 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.
> 
> 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.
> 
> 
>>- 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.
>>
> 
> 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?
>>
>>Gregory.
> 
> 
>       --Charlie
> 


-- 


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>