[IPsec] NO_PROPOSAL_CHOSEN vs INVALID_SYNTAX

[Tero Kivinen <[e-mail]>]

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.
-- 
[e-mail]