[Swan-dev] ikev2: when no host connection matches, always respond with INVALID_SYNTAX
andrew.cagney at gmail.com
Fri Jun 21 17:19:21 UTC 2019
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.
More information about the Swan-dev