On Thu, 20 Jun 2019 at 09:53, Paul Wouters <[email protected]> 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. _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
