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 16:52, Paul Wouters <p...@nohats.ca> wrote: > > > 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 > 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 the proposals > list with transforms. > > INVALID_SYNTAX can be interpreted as "malformed packet" but the RFC text > uses this as the "if all other errors dont match, use this one" so you > can end up returning this even if there is no invalid syntax at all. > > So if your IPsec gateway only has static IP based VPNs and an unknown IP > connects, some feel NO_PROPOSAL_CHOSEN conveys that, while technically, > even though there is no invalid syntax in that proposal, the RFC states > we should return INVALID_SYNTAX. > > Similarly, if during IKE_AUTH you are finding out there is no IPsec > configuration that matches the incoming client, there is no "proposal > list" to compare, so while NO_PROPOSAL_CHOSEN feels a more natural > match, should we really return INVALID_SYNTAX despite there being no > syntax problem? That is what the RFC says. > > I guess in the end, we are really missing a "CONNECTION_REJECTED" > notify that would cover all the things not covered in the more specific > notifies. > > What do other implementations do? Should we clarify this anywhere? > > libreswan was using NO_PROPOSAL_CHOSEN for most of these, but is now > slated to be more strict to the RFC and use INVALID_SYNTAX. (and > clearly, I'm not happy about it but it seems the RFC dictates this) > > Paul > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
