3.8.4.1 SA Deletion/Invalidation

  • Article

The higher layer application can cause SAs to be deleted by changing the underlying security policy, or by triggering a local state cleanup (see section 3.8.7). In such cases, the host SHOULD delete the SAs, as specified in [RFC2408] section 5.15.

After a delete has been triggered, a delete notify MUST be sent immediately, but the MM SA MUST NOT be deleted until quick mode delete processing has been completed. Moreover, the QM SAs associated with the MM SA MUST NOT be deleted until deletion is triggered by other protocol events, as specified in [RFC2409] section 5.5. These protocol events are quick mode lifetime expiry as specified in [RFC2409] Section 5.5, policy changes (see section 3.8.7) or the peer sending a quick mode delete (See section 3.8.5). Once all the QM SAs associated with the MM SA have been deleted the MM SA MUST be deleted.

The host MUST then construct message #1 as follows:

  • Message #1 MUST consist only of an ISAKMP header, a Hash payload, a Nonce payload, and a Delete payload, as specified in [RFC2408] section 3.15.<23>

  • The ISAKMP header MUST be constructed as specified in [RFC2409] section 5.7.

  • The Hash payload MUST be constructed in the following manner:

     HASH(1) = prf(SKEYID_a, M-ID | Ni | Delete)

    as specified in [RFC2409] section 5.7.

  • The Ni payload is a Nonce payload and MUST be constructed as specified in [RFC2408] section 3.13.

  • The Delete payload MUST be constructed as specified in [RFC2408] section 3.15.

If the "MS NT5 ISAKMPOAKLEY" vendor ID payload (see section 1.7) has been received from the peer for the corresponding MM SA, the host MUST then start the delete retransmission timer and set it to expire in 1 second. Otherwise, the host MUST NOT start the delete retransmission timer.