(I'm not on this list)
Tero Kivinen writes:
> If you use invalid syntax and tear down the SA, then at least the
> other end will know that they are doing something wrong and hopefully
> they will fix their code at some point.
>
> But I think correct option is to use exactly same protocol id than
> what the initiator used, as that is what SA they are trying to use.
>
> The Child SA is identified by the protocol id and spi tupple, so if
> you do not have matching child sa, returning CHILD_SA_NOT_FOUND is the
> correct, and as in the section 2.25 the RFC7296 says:
>
> A CHILD_SA_NOT_FOUND notification SHOULD be sent when a peer receives
> a request to rekey a Child SA that does not exist. The SA that the
> initiator attempted to rekey is indicated by the SPI field in the
> Notify payload, which is copied from the SPI field in the REKEY_SA
> notification. A peer that receives a CHILD_SA_NOT_FOUND notification
> SHOULD silently delete the Child SA (if it still exists) and send a
> request to create a new Child SA from scratch (if the Child SA does
> not yet exist).
>
> If the protocol id does not match the protocol id you are using, then
> you do NOT HAVE matching Child SA, thus the other end is trying to
> rekey sa that does not exists.
>
> I.e. the SPI field is copied from the REKEY_SA to CHILD_SA_NOT_FOUND
> notify, then you needs to copy the protocol id too...
>
> Also the section 3.10 of RFC7296 says:
>
> 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.
I assume we're not discussing 0 or 1(IKE). Which should be dismissed with
INVALID_SYNTAX 7
Indicates the IKE message that was received was invalid because
some type, length, or value was out of range or because the
request was rejected for policy reasons.
> thus the Protocol ID field indicates the protocol id for the SA
> indicated by the SPI field, thus Protocol ID and SPI are always going
> together, and as REKEY_SA and CHILD_SA_NOT_FOUND are those few ones
> that have Protocol ID and SPI non-zero you need to copy them.
>
> You could submit an errata saying that
>
> The SA that the
> initiator attempted to rekey is indicated by the SPI field in the
> Notify payload, which is copied from the SPI field in the REKEY_SA
> notification.
>
> should say
>
> The SA that the initiator attempted to rekey is
> indicated by the Protocol ID and SPI fields in the Notify payload,
> which are copied from the Protocol ID and SPI fields in the REKEY_SA
> notification.
I like the principal. As things go forward and exchanges for new
protocols are defined they each get to spell out the details of things
like the proposal sub payload
and how to extract the Child's identifying material from the REKEY_SA.
Several things trouble me:
The first is that the RFC only defines how to extract the child's
identifier for ESP and AH vis:
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.
which means that for a completely unknown protocol I'm left assuming
the notify body is ESP/AH like (is SPI length = 8 reasonable? Is SPI
length = 0 with a 32k blob reasonable?).
(I understand one implementation sends back an empty child-not-found
notify, which at least avoids the need to parse the body).
The second is that the peer is trying to rekey a Child SA that can
never exist. Any attempt to establish this new unknown protocol
should have failed as the proposal sub-payload containing the unknown
protocol would be ignored. I view that as pretty broken, or worse.
Hence, when the protocol is completely unknown I se invalid-syntax as
being an equally valid response.
Andrew
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
