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 the proposals > list with transforms.
Note, that this includes cases where the list of acceptable proposals is EMPTY because you do not allow any connections from that host. > 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. If both implementations work correctly you should NEVER send INVALID_SYNTAX error. That always means there is programming error in one of the implementations. > 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. Correct error code is NO_PROPOSAL_CHOSEN as you use unknown IP to do policy lookup, find empty list of acceptable proposals to match against what other end sent, and of course empty list does not match, so you do not have any proposal that matches, meaning you return NO_PROPOSAL_CHOSEN. > 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. In that case you do have proposal list, but that list is empty. And empty list does not match and you return NO_PROPOSAL_CHOSEN. > 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. We discussed this, but decided that we want to keep error codes limited, not to leak out information what is wrong in the configuration. So you get same NO_PROPOSAL_CHOSEN error notification regardless whether your algorithm list does not match, or whether the ip is unknown, or whether the identity of the other end is unknown. > What do other implementations do? Should we clarify this anywhere? Use NO_PROPOSAL_CHOSEN every time if there is something that could be fixed by changing configuration in implementations. Use INVALID_SYNTAX if error is something that is against RFC, and even if configuration is changed you can never accept such message ever. For example if whole SA payload is missing you send INVALID_SYNTAX, if some mandatory transform types are missing that is NO_PROPOSAL_CHOSEN. > 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) No, the RFC does not dictate that. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
