Paul Wouters writes:
>
> We ran into an issue where we received a REKEY_SA notify with a bad
> protocol id, eg not ESP or AH. What do we do?
>
> 1) CHILD_SA_NOT_FOUND, but what should we put in the proto id field?
> 0 ? the bogus value?
> 2) It's bad, so INVALID_SYNTAX
>
> When doing 1, we will see:
>
> Responder uses bad protocol id - Initiator can quietly delete child sa.
> But it forces us to send something violating the RFC.
>
> Or Responder uses ESP or AH protocol id? Initiator will now be upset,
> and possible send a new informational with a notify with INVALID_SYNTAX
> or DELETE. If INVALID_SYNTAX, it will take down everything.
>
> When doing 2, it guarantees everything will be taken down.
>
>
> Ideally, we would like to "ignore" the REKEY_SA, and leave the IKE and
> existing Child SAs up. But that means we need to lie about protocol id,
> and we currently have guards in our code to protect against that.
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.
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.
--
[email protected]
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
