Subject: [IPsec] NO_PROPOSAL_CHOSEN vs INVALID_SYNTAX

From: Paul Wouters <[email-masked]>
Date: Thu, 20 Jun 2019 09:52:06 -0400 (EDT)

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.

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 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

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 20 Jun 2019 17:39:30 +0300

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.

> we should return INVALID_SYNTAX.

I'd rather not return anything in this case.

> syntax problem? That is what the RFC says.

I'd return NO_PROPOSAL_CHOSEN.

Regards,
Valery.

> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tommy Pauly <[email-masked]>
Date: Thu, 20 Jun 2019 08:51:45 -0700

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-masked]> wrote:
> 
> Hi Paul,
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/ipsec <https://www.ietf.org/mailman/listinfo/ipsec>

---

From: Michael Richardson <[email-masked]>
Date: Thu, 20 Jun 2019 15:00:52 -0400

Valery Smyslov <[email-masked]> wrote:
    > 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.

I agree that INVALID_SYNTAX should be about things you can't fix by
configuration.

I also agree with Paul:

    paul> I guess in the end, we are really missing a "CONNECTION_REJECTED"
    paul> notify that would cover all the things not covered in the more
    paul> specific notifies.

I would like some more fine-grained replies as well.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Yoav Nir <[email-masked]>
Date: Thu, 20 Jun 2019 23:51:48 +0300

In the days when I had an IKEv2 implementation, NO_PROPOSAL_CHOSEN was the go-to error code for everything the Responder didn’t like; wrong algorithms, wrong transforms (like transport instead of tunnel), unknown peer, 

INVALID_SYNTAX meant something like malformed packet.

> On 20 Jun 2019, at 16:52, Paul Wouters <[email-masked]> wrote:
> 
> 
> Hi,
>

---

From: Tero Kivinen <[email-masked]>
Date: Sat, 22 Jun 2019 13:03:46 +0300

> where proposal refers to the entire IKE proposal, not the proposals

Note, that this includes cases where the list of acceptable proposals
is EMPTY because you do not allow any connections from that host. 

> 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. 

> 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.

> 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. 

> notify that would cover all the things not covered in the more specific

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. 

> clearly, I'm not happy about it but it seems the RFC dictates this)

No, the RFC does not dictate that.
-- 
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Sun, 23 Jun 2019 19:27:21 -0400 (EDT)

> so you do not have any proposal that matches, meaning you return

Thanks to the group for the various explanations. I've changed our
return code back to NO_PROPOSAL_CHOSEN.

Paul