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

Re : Error recovery ?



Hi,
 
>Hans-Joachim Knobloch wrote:

> Consider the case that two hosts communicate via two IPSec security
> gateways
>              A <---> SG1 <-----> SG2 <---> B
>
> and that appropriate ISAKMP and IPSec SAs are established. Let us call
> these SAs SA1, SA2AB and SA2BA respectively.
> Now what happens, when SG2 is reset?
>
> When B sends a packet to A everything should be fine, since SG2 will
> initiate new phase 1 and phase 2 exchanges.
> But what if A sends a packet to B? SG1 will process the packet with the
> old IPsec SA2AB and SG2 will receive a packet with a most probably unknown
> SPI. Is this supposed to happen until SA2AB does "naturally expire"?
> Do we have to set SA lifetime short enough and/or hope that B will also
> send a packet more sooner than later?
 
  Currently, there is no standard way to do this and I guess it is left
  to the implementation.

  For phase1 SA:
    Assume SG1 has phase1 SA where as SG2 does not have corresponding
    phase1 SA.
    If phase2 is initiated by SG2, there is no problem,because it negotiaties
    new phase1 SA with the SG1.

    If phase2 is initiated by SG1, then the SG1 never receives second
    quick mode message, since SG2 does not have phase1 SA.
    SG1 quick mode negotiation fails and then SG1 can take action based
    on implementation. In our implementation, we delete the phase1 SA
    if the initiator(SG1) does not receive second message for all retries.
    ( Note that we have configuration option to do this or not ).

For phase2 SA:
    This is tricky.
    Again here, assume SG1 has phase2 SA whereas SG2 does not have
    corresponding phase2 SA.

    If the packet comes on SG2 destined to SG1, there is no problem as
    SG2 negotiates new phase2 SA.

    If the packet comes on SG1 destined to SG2, SG1 applies security
    and sends it to the SG2 and SG2 drops the packet.  There will be
    no packets transferred between these two SG for that session.

    Here, following can be done:
    Using IKE, you always get two SAs. One for oubound and other for
    inbound.
    Here, I feel we can use some sort of timeouts.
    That is whenever packet is sent, start software timer with some
    preconfigured value ( say 5 minutes )
    Whenever packet is receieved on the corresponding inbound SA,
    then disable the timer on the outbound SA.
    If no packets are received within 5 minutes on inbound SA, then
    delete both SAs.
    Here, basic assumption is that the there will be always some packets
    coming inbound within 5 minutes after sending any outbound packet.
    This mechanism still works otherwise, but at the expense of one
    quick mode negotiation.
>
> Alternatively one could imagine that SG2 sends SG1 some kind of
> (ICMP?) message to tell it to invalidate SA2AB. But then, this might be
> abused by an attacker to cause unnecessary ISAKMP traffic and a service
> disruption until new SAs are installed.
>
> In the above example, when SA2AB expires, SG1 will probably initiate a
> phase 2 exchange with the old SA1. What is the correct way for SG2 to
> respond to this? Initiate a nes phase 1 exchange? Send an error
> notification to SG2 (then necessarily unencrypted due to nonexistant
> ISAKMP SA)? The latter might open up a denial-of-service attack by sending
> spoofed error notifications to make SG1 invalidate its existing SAs and
> thus cause lots of unnecessary ISAKMP traffic and service disruption.
 
See above. The above is a possible means of addressing the problem, though
not explicitly stated in any RFC. There are, obviously other alternative
solutions possible.
 
Regards.
- Kumar
 
Product Manager
Intoto Inc.
3160, de La Cruz Blvd; Ste #100
Santa Clara,
CA 95054
www.intotoinc.com