[Swan-dev] ikev2: when no host connection matches, always respond with INVALID_SYNTAX

[Andrew Cagney]

On Thu, 20 Jun 2019 at 09:53, Paul Wouters <paul at nohats.ca> wrote:
>
> On Thu, 20 Jun 2019, Andrew Cagney wrote:
>
> >
> > 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.
>
> I understand that, but it does feel wrong to me. The implied text has
> nothing to do with the message we want to convey. I've asked at the
> IPsec WG to see what other implementations are doing.
>
> So for now, I'll leave your changes in since they are formally more
> correctly following the RFC (but are intuitively more wrong)

I agree INVALID_SYNTAX is pretty bizarre name for the fallback error
response.  But as the RFC also says:

   The number of different error statuses was
   greatly reduced from IKEv1 both for simplification and to avoid
   giving configuration information to probers.

it seems that this was a somewhat conscious decision.

My personal preference here is to apply the firewall mindset and when
the host-pair lookup matches just drop the packet.

Just note that, with the code as it stands, and when cookies are enabled:
- a missing cookie triggers a give-me-a-cookie response, but then
- when there is a cookie we'd drop the packet
if host-pair lookups were efficient we could fix this.