> 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.
Hm, I just noticed that we (strongSwan) implement that incorrectly as we send the CHILD_SA_NOT_FOUND notify without SPI (or protocol ID). What's the purpose of repeating that information in the notify? There can only be a single REKEY_SA notify in the request, so how could there be any confusion for the exchange initiator about which SA wasn't found by the responder? Regards, Tobias _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
