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

Re: Question about mis-match SA lifetimes

Hi, (me again with agenda? :0) 

This may be a bit off the topic, and concerns only the proper IPSEC
SA's, not ISAKMP key negotiation SAs. I return to my old graphic on
the basic SA negotiation transaction:

                 H1                                H2
    ------------------------               ------------------ 
(0) IP:H1->H2 ->SA0 -> SA1 ==================> SA1
     \                  ^                       ^
      \                 |                       |
       \                |                       |
(1) ACQUIRE SA: H1->H2  |  <-- Key Mgmnt -->    |
         \              |
          -------------------(a)---------> (2) GETSPI: dst=H2
                        |                     UPDATE SA: dst=H2
                        |                          /
                                                  /
          (3) ADD SA: dst=H2 <------(b)-----------


I'm assuming that for a conforming IPSEC implementation, BOTH ends of
SA1's on H1 and H2 must be IDENTICAL. All parameters must be
identical, including the lifetimes.

This means that data (a) contains proposals, and data (b) must contain
the chosen values, including reduced lifetimes, if H2 so
decided.

This way, I don't see any problems (excluding box crashes), other than
a slight uncertainty period for time based life times due to delays
between H1/H2. But, as H1 SA is updated last, even this may be rare
(e.g. the H1 starts counting later than H2).

For byte based lifetimes, the discrepancy may result from lost data,
but in this case the counter on H1 should run faster than H2, and
again it would usually expire first.

When H1 expires first, the negotiation is simply redone for this
single unidirectional SA. If H2 expires first (on what conditions this
happens?), packets will be lost for a while, unless something extra is
done.

>   I've heard several people mention that a solution to the "failover"
> problem-- where the box crashes, reboots, loses all state

A box crash of H1 would just cause normal regotiation of this SA1.

A box crash of H2 is more difficult, would need some refinements or
guidelines how to cope with the situation. I don't have a solution for
this, the ones that come first into mind, may have nasty drawbacks...

 - if a packet with unknown SPI arrives, send a delete for that SA
   (DOS attack problems!)

 - save (KEYSRC, SPI, proto, dst) onto a disk, and on bootup contact each
   key manager SRC, and send delete SA. Only those SA's need to be
   stored for which this host is the receiving end point. (Needs a
   storage that survives crash...)


Agenda? Umm.. well just trying to show that if SA's are negotiated
independently of bundles, many problems reduce to manageable size and
perhaps it is easier to find exact solutions.

-- 
Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland
Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/
References: