1. HIP resynchronization Tom Henderson IETF-59, March 3, 2004

2. The resynch problem possible causes: –I have recently rebooted (or daemon crashed) and have lost my IPsec state –network mischief IP datagram arrives on unknown SPI

3. HIP resynch solutions What to do? –IPsec does nothing in this case HIP draft -09 proposes to send an I1 or an R1 to restart an exchange –assumes that HIP daemon listening on PF_KEY interface gets notified somehow Let’s assume we rebooted and need to start the exchange again –should we do local “uptime” check first??

4. HIP resynch options i) use “unknown SPI” as surrogate for I1, send R1 (original base spec behavior) –subject to replay attacks (was origin of birthday counter) –what if you don’t know the HIT? ii) allow recipient to become new initiator (more natural), send I1 –opens up attack-- third party can stimulate two other hosts to set up an unnecessary SA iii) send I1, but with “resynch” bit or parameter

5. Resynch solution IP datagram arrives on unknown SPI send I1 with unknown SPI TLV Do I have that SPI? - if so, send R1 - if not, drop (or REJECT??) send R1 with resynch bit did I send I1 recently? - if yes, send I2 - if not, drop I2 with Unknown SPI R2 drop old SAs install new ones more work than usual for responder

6. One more possible attack IP datagram arrives on unknown SPI send I1 with unknown SPI TLV Reject ? replay R1 resynch compute, compute send I2 with unknown SPI TLV Birthday count may be of help in R1 could also rate limit these types of initiations

7. HIP resynch summary seems difficult to defend against attacks when we are responding to: –unauthenticated packets (unknown SPI) –packets that can be replayed (R1) more thought needed if we keep it, move out of base spec –define new “Unknown SPI” TLV –move birthday to separate TLV (out of base spec) –define resynch procedures, new state