Re: [IPsec] NO_PROPOSAL_CHOSEN vs INVALID_SYNTAX

[Tommy Pauly <[e-mail]>]

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 <[e-mail]> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ipsec
> 
> _______________________________________________
> IPsec mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/ipsec <https://www.ietf.org/mailman/listinfo/ipsec>