Re: [Captive-portals] Requirements for "captive portal closed" notifications

[Tero Kivinen <[e-mail]>]

Michael Richardson writes:
> Lorenzo Colitti <[e-mail]> 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
-- 
[e-mail]