Re: [IPsec] NO_PROPOSAL_CHOSEN vs INVALID_SYNTAX

[Yoav Nir]

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  wrote:
> 
> 
> 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
> 
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] NO_PROPOSAL_CHOSEN vs INVALID_SYNTAX

[Michael Richardson]

Valery Smyslov  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 , Sandelman Software Works
 -= IPv6 IoT consulting =-


signature.asc
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] NO_PROPOSAL_CHOSEN vs INVALID_SYNTAX

[Tommy Pauly]

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  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
>> IPsec@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipsec
> 
> ___
> IPsec mailing list
> IPsec@ietf.org 
> https://www.ietf.org/mailman/listinfo/ipsec 
> 
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] NO_PROPOSAL_CHOSEN vs INVALID_SYNTAX

[Valery Smyslov]

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
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] NO_PROPOSAL_CHOSEN vs INVALID_SYNTAX

[Paul Wouters]

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

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec