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 > 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. I'd rather not return anything in this case. > 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'd return NO_PROPOSAL_CHOSEN. Regards, Valery. > 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