[Swan-dev] Fwd: [IPsec] IKEv2: how to respond to REKEY_SA with bad protoid?

[Paul Wouters]

Sent using a virtual keyboard on a phone

Begin forwarded message:

> From: Tero Kivinen <kivinen at iki.fi>
> Date: June 15, 2023 at 17:50:36 EDT
> To: Paul Wouters <paul at nohats.ca>
> Cc: "ipsec at ietf.org WG" <ipsec at ietf.org>
> Subject: [IPsec] IKEv2: how to respond to REKEY_SA with bad protoid?
> 
> 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.
> -- 
> kivinen at iki.fi
> 
> _______________________________________________
> IPsec mailing list
> IPsec at ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan-dev/attachments/20230615/5e2aff88/attachment.htm>