On Sat, 22 Jun 2019, Tero Kivinen wrote:
If both implementations work correctly you should NEVER send
INVALID_SYNTAX error. That always means there is programming error in
one of the implementations.
Correct error code is NO_PROPOSAL_CHOSEN as you use unknown IP to do
policy lookup, find empt
Paul Wouters writes:
> NO_PROPOSAL_CHOSEN can be interpreted as "no proposal from the IKE/IPsec
> proposal list matches due to all proposals having at least one mismatching
> transform" versus "no matching ike connection for your IKE proposal"
> where proposal refers to the entire IKE proposal, not
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 clien
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 succeed.
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
p
