On Thu, 18 Jan 2024 at 12:14, Paul Wouters <p...@nohats.ca> wrote: > The RFC isn’t useless here. If we complied to the RFC, there would never be > an error based on it - one MUST accept tunnel mode.
Actually, yes and no. I was reading: The USE_TRANSPORT_MODE notification MAY be included in a request message that also includes an SA payload requesting a Child SA. It requests that the Child SA use transport mode rather than tunnel mode for the SA created. If the request is accepted, the response MUST also include a notification of type USE_TRANSPORT_MODE. If the responder declines the request, the Child SA will be established in tunnel mode. If this is unacceptable to the initiator, the initiator MUST delete the SA. Note: Except when using this option to negotiate transport mode, all Child SAs will use tunnel mode. which does not contain MUST. Just that if the proposal isn't rejected outright the initiator should assume tunnel mode. But more interesting there is: NO_PROPOSAL_CHOSEN 14 None of the proposed crypto suites was acceptable. This can be sent in any case where the offered proposals (including but not limited to SA payload values, USE_TRANSPORT_MODE notify, IPCOMP_SUPPORTED notify) are not acceptable for the responder. This can also be used as "generic" Child SA error when Child SA cannot be created for some other reason. See also Section 2.7. where it says NO_PROPOSAL_CHOSEN can be returned for USE_TRANSPORT_MODE. _______________________________________________ Swan-dev mailing list Swan-dev@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-dev