1

I am puzzled about two paragraphs regarding a notification payload in section 3.10 of RFC7296. There you can find the following:

   o  Protocol ID (1 octet) - If this notification concerns an existing
      SA whose SPI is given in the SPI field, this field indicates the
      type of that SA.  For notifications concerning Child SAs, this
      field MUST contain either (2) to indicate AH or (3) to indicate
      ESP.  Of the notifications defined in this document, the SPI is
      included only with INVALID_SELECTORS, REKEY_SA, and
      CHILD_SA_NOT_FOUND.  If the SPI field is empty, this field MUST be
      sent as zero and MUST be ignored on receipt.

   o  SPI Size (1 octet) - Length in octets of the SPI as defined by the
      IPsec protocol ID or zero if no SPI is applicable.  For a
      notification concerning the IKE SA, the SPI Size MUST be zero and
      the field must be empty.

My question is: what is the proper form for a notification payload regarding an IKE SA?

The second paragraph says for an IKE SA the SPI size must be zero and the SPI field empty while the first paragraph says the protocol ID must be zero when the SPI field is empty.

In an SA payload the protocol ID for IKE is 1 but as I understand the above paragraphs, in an Notification payload I would have to set it to 0.

1

I found the answer further above in page 16 of RFC7296

There is no need to send a notification payload regarding a different IKE SA. The current IKE SA is already in the IKE header.

The first of these paragraphs in section 3.10 says "the SPI is included only with INVALID_SELECTORS, REKEY_SA, and CHILD_SA_NOT_FOUND". Section 1.3.2 on page 16 makes clear that for the rekeying of an IKE SA there is no notification involved while the rekeying of a child SA does indeed use a notification payload.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.