[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