I think this is the relevant text: * 3.10.1. Notify Message Types: * * INVALID_SYNTAX: Indicates the IKE message that was * received was invalid because some type, length, or * value was out of range or because the request was * rejected for policy reasons. To avoid a DoS attack * using forged messages, this status may only be * returned for and in an encrypted packet if the * Message ID and cryptographic checksum were valid.
NOTE THE MUST HERE: * To avoid leaking information to someone probing a * node, this status MUST be sent in response to any * error not covered by one of the other status types. * To aid debugging, more detailed error information * should be written to a console or log. NO_PROPOSAL_CHOSEN is for a very specific error type - where, by changing the proposals, there's a fighting chance that the connection comes up. Here that isn't true. On Wed, 19 Jun 2019 at 15:39, Paul Wouters <[email protected]> wrote: > > > This commit seems to introduce an error. > > It changes ikev2_parent_inI1outR1() to return INVALID_SYNTAX in IKE_INIT > and even quotes the RFC part where it says: It changes things to: - send the message inline - return STF_DROP (I think STF_DROP and STF_FATAL should be merged but that's another story) > + * rejected for policy reasons. To avoid a DoS attack > + * using forged messages, this status may only be > + * returned for and in an encrypted packet if the > + * Message ID and cryptographic checksum were valid. > > The IKE_INIT reply is not an encrypted packet. I think > NO_PROPOSAL_CHOSEN is the right error notify. > > checking the notify section, for INVALID_SYNTAX we see: > > Indicates the IKE message that was received was invalid because > some type, length, or value was out of range or because the > request was rejected for policy reasons. > > I think combining the first parts and the last item within a single > message is probably a mistake in the RFC, or at least "rejected for > policy reason" was meant to reflect the type/length/values and not > "any and all policy reason". IKEv1 apparently had lots of status indications but, for DOS reasons, they all were merged into INVALID_SYNTAX. > For NO_PROPOSAL_CHOSEN though, it really seems focused on the IKE or > IPsec proposal parts. So it is also not the best match. > > However, it seems "connection not found" matches more closely with > NO_PROPOSAL_CHOSEN (what you asked could be valid, but we didnt match > it) than INVALID_SYNTAX (we dont understand what you are asking for). > The other error notifies we can use make even less sense. > commit e85d4bbb8f22cbafb6778b609a1663f3d1d86820 > Author: Andrew Cagney <[email protected]> > Date: Mon Jun 17 17:06:36 2019 -0400 > > ikev2: when no host connection matches, always respond with > INVALID_SYNTAX > > Where INVALID_SYNTAX is IKEv2 speak for any error not otherwise defined. > Was, depending on the connection list order, sometimes responding with > NO_PROPOSAL_CHOSEN. > > _______________________________________________ > Swan-commit mailing list > [email protected] > https://lists.libreswan.org/mailman/listinfo/swan-commit > _______________________________________________ > Swan-dev mailing list > [email protected] > https://lists.libreswan.org/mailman/listinfo/swan-dev _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
