Michael Richardson writes: > Lorenzo Colitti <[email protected]> wrote: > david> Is there any data that shows ICMP (and its insecurity) being > used > david> for off-path attacks like this today? Networks (as they do today) > may > david> just filter out ICMP they don't support from the edge. > > > Regardless of whether this is happening today, it seems unwise to > > propose something with an obvious security hole like this. The risk is > > that we do a bunch of work and then security review tells us "?REDO > > FROM START". > > We have secdir secretary Tero on the list now... > > Even if offpath attacks are challenging, given typical coffee shop wifi, > on-path attacks are trivial. > > The ICMP is a hint. That's also good for many reasons involving rate > limiting and idempotency.
Yes. This has been also used in the security protocols like IKEv2. For example section 2.4 in RFC7296 (IKEv2 [1]) says following: Since IKE is designed to operate in spite of DoS attacks from the network, an endpoint MUST NOT conclude that the other endpoint has failed based on any routing information (e.g., ICMP messages) or IKE messages that arrive without cryptographic protection (e.g., Notify messages complaining about unknown SPIs). An endpoint MUST conclude that the other endpoint has failed only when repeated attempts to contact it have gone unanswered for a timeout period or when a cryptographically protected INITIAL_CONTACT notification is received on a different IKE SA to the same authenticated identity. An endpoint should suspect that the other endpoint has failed based on routing information and initiate a request to see whether the other endpoint is alive. To check whether the other side is alive, IKE specifies an empty INFORMATIONAL request that (like all IKE requests) requires an acknowledgement (note that within the context of an IKE SA, an "empty" message consists of an IKE header followed by an Encrypted payload that contains no payloads). If a cryptographically protected (fresh, i.e., not retransmitted) message has been received from the other side recently, unprotected Notify messages MAY be ignored. Implementations MUST limit the rate at which they take actions based on unprotected messages. So using ICMP as hint and doing rate limited operatins based on that is acceptable. [1] https://www.rfc-editor.org/rfc/rfc7296.txt -- [email protected] _______________________________________________ Captive-portals mailing list [email protected] https://www.ietf.org/mailman/listinfo/captive-portals
