Re: [Captive-portals] Thinking of something related to captive portals for the ietf98 hackathon

[Erik Kline <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> wrote:
>
>> Agreed. Hence the discussion about using a difficult-to-guess token in
>> the message.
>>
>> ------------------------------
>> *From:* Lorenzo Colitti [[e-mail]]
>> *Sent:* Wednesday, February 22, 2017 12:05 PM
>>
>> *To:* Dave Dolson
>> *Cc:* David Bird; [e-mail]; Kyle Larose;
>> [e-mail]
>> *Subject:* Re: [Captive-portals] Thinking of something related to
>> captive portals for the ietf98 hackathon
>>
>> 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 <[e-mail]>
>> 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.
>>>
>>> An ICMP message can give an "instant" response.
>>>
>>> It's worth considering that the ICMP message may trigger the
>>> "sacrificial" HTTP request by the operating system.
>>>
>>>
>>>
>>> ------------------------------
>>> *From:* Lorenzo Colitti [[e-mail]]
>>> *Sent:* Wednesday, February 22, 2017 10:24 AM
>>> *To:* Dave Dolson
>>> *Cc:* David Bird; [e-mail]; Kyle Larose;
>>> [e-mail]
>>>
>>> *Subject:* Re: [Captive-portals] Thinking of something related to
>>> captive portals for the ietf98 hackathon
>>>
>>> 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 <[e-mail]>
>>> wrote:
>>>
>>>> Lorenzo,
>>>> My interest in ICMP is that it could work with any protocol, not just
>>>> HTTP, and doesn't require any MITM for HTTPS.
>>>> I recall a discussion about adding a difficult-to-guess token to the
>>>> ICMP message, making it hard to spoof.
>>>>
>>>> -Dave
>>>>
>>>>
>>>>
>>>> ------------------------------
>>>> *From:* Captive-portals [[e-mail]] on behalf
>>>> of Lorenzo Colitti [[e-mail]]
>>>> *Sent:* Wednesday, February 22, 2017 9:42 AM
>>>> *To:* David Bird
>>>> *Cc:* [e-mail]; Kyle Larose; [e-mail]
>>>> *Subject:* Re: [Captive-portals] Thinking of something related to
>>>> captive portals for the ietf98 hackathon
>>>>
>>>> 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:
>>>>
>>>>    - A header in the initial redirect that captive portals almost
>>>>    always generate.
>>>>    - A well-known URL where the state of the captive portal can be
>>>>    revalidated, either periodically or when some other indication of loss of
>>>>    connectivity is observed.
>>>>
>>>> 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 <[e-mail]> 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
>>>>> <https://github.com/snaewe/books-code/tree/master/unpv13e/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 <[e-mail]>
>>>>> wrote:
>>>>>
>>>>>> Hey everyone,
>>>>>>
>>>>>> I was thinking of doing something (anything) related to captive
>>>>>> portals for the ietf 98 hackathon. In particular,
>>>>>> https://tools.ietf.org/html/draft-wkumari-capport-icmp-unreach-01
>>>>>> caught my eye. I was wondering if anyone had thoughts on that, and whether
>>>>>> there is anything else they'd like to see me champion.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Kyle
>>>>>>
>>>>>> _______________________________________________
>>>>>> Captive-portals mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/captive-portals
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Captive-portals mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/captive-portals
>>>>>
>>>>>
>>>>
>>>
>>
>
> _______________________________________________
> Captive-portals mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/captive-portals
>
>