In the days when I had an IKEv2 implementation, NO_PROPOSAL_CHOSEN was the
go-to error code for everything the Responder didn’t like; wrong algorithms,
wrong transforms (like transport instead of tunnel), unknown peer,
INVALID_SYNTAX meant something like malformed packet.
> On 20 Jun 2019, at
Valery Smyslov wrote:
> generally the INVALID_SYNTAX must be returned when something fatal
> happened, that cannot be fixed by adjusting configuration etc., only
> re-installing app after bug-fixing would help. In contrast,
> NO_PROPOSAL_CHOSEN means that after some actions from
It does seem to a question open to interpretation by the implementation.
I think you can make a good argument for NO_PROPOSAL_CHOSEN in both cases. If
your implementation interprets things as always getting a list of valid
proposal values based on the remote address or ID, then any unknown
Hi Paul,
generally the INVALID_SYNTAX must be returned when something
fatal happened, that cannot be fixed by adjusting configuration etc.,
only re-installing app after bug-fixing would help.
In contrast, NO_PROPOSAL_CHOSEN means that after some actions from
operator the connection would
Hi,
We are having a discussion about which notify to return in certain
cases. The issue comes down to the names of the notifies and their
actual dictated use in the RFC that does not always intuitively
maps to the name.
NO_PROPOSAL_CHOSEN can be interpreted as "no proposal from the IKE/IPsec
