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 client would match the empty list of proposals.
Thanks, Tommy > On Jun 20, 2019, at 7:39 AM, Valery Smyslov <[email protected]> wrote: > > 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > IPsec mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/ipsec > <https://www.ietf.org/mailman/listinfo/ipsec>
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
