|
Erik, I don’t think it is onerous. But, the device causing captive portal is not always on the local subnet of the end-user device. I think it is better to have a security scheme that doesn’t depend on TTL. -Dave From: Erik Kline [mailto:[email protected]]
How onerous would it be to require that an ICMPv[46] message with a captive portal code also have a hoplimit of 255 (i.e. be link-local / from an on-link source)? I could imagine writing a user-space daemon that listens for ICMP message of one specific type, and validates the hoplimit with traditional cmsg tricks. Furthermore, only having to do so on networks advertising a 7710 option would be good. On 23 February 2017 at 02:10, David Bird <[email protected]> wrote: Further, we could tie this to RFC 7710, so that you can disregard this ICMP from networks not expected to be captive portal and networks who do implement captive portal can easily (as in iptables rules) filter out external ICMP of this
nature. On Wed, Feb 22, 2017 at 9:07 AM, Dave Dolson <[email protected]> wrote: Agreed. Hence the discussion about using a difficult-to-guess token in the message. From: Lorenzo Colitti [[email protected]]
The ability for any host in the Internet to trigger an instant response sounds it could turn into a DOS vector, though. On Thu, Feb 23, 2017 at 2:04 AM, Dave Dolson <[email protected]> wrote: As I understand it, to "think something is wrong" requires an application-layer timeout. Some people think this is about 5s, but I
don't believe TCP specifies an upper bound. From: Lorenzo Colitti [[email protected]]
Ok, but the implementations that are the most likely to implement this sort of feature already send sacrificial plaintext HTTP requests on connect, and are quite capable of generating HTTP requests on demand when
they think something is wrong. On Wed, Feb 22, 2017 at 11:53 PM, Dave Dolson <[email protected]> wrote: Lorenzo, From: Captive-portals [[email protected]]
on behalf of Lorenzo Colitti [[email protected]] I'm not a fan of the ICMP method. I think the security implications need more thought.
As is, it looks like pretty much anyone on the Internet can send you one of these packets, and you have no way of knowing if it's legitimate. Relying on such an easy-to-spoof signal to decide that a network no
longer provides Internet access could be quite harmful, particularly if the receiving device decided to switch to cellular data and incur the associated traffic costs. Even if the signal is only taken as a hint to revalidate the network, that still has battery
implications. It would seem to be much more useful to use:
At the last IETF we talked about possibly having a more structured way of communicating this and other bits of information from captive portal to host (a RESTful API, IIRC). That would also be useful, if we can
all collectively resist the temptation to overengineer such a mechanism. :-) On Wed, Feb 22, 2017 at 11:31 PM, David Bird <[email protected]> wrote: Hi Kyle, I think that is a great idea! I had started to implement here: https://github.com/coova/coova-chilli/tree/capport-icmp What would be nice, in addition to the NAS changes, is to also demonstrate the client side ... either something like
icmpd (to listen for the ICMP and provide applications a way of checking the status of their dest. unreach. connections), or the necessary Linux kernel changes. Also with kernel changes, the I-D could also be implemented using iptables, or other NAS software
too. Cheers, David On Wed, Feb 22, 2017 at 6:12 AM, Kyle Larose <[email protected]> wrote: Hey everyone,
|