[Swan-dev] [Swan-commit] Changes to ref refs/heads/main
Andrew Cagney
andrew.cagney at gmail.com
Thu Jan 18 19:32:06 EET 2024
On Thu, 18 Jan 2024 at 12:14, Paul Wouters <paul at 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.
More information about the Swan-dev
mailing list