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

[David Bird <[e-mail]>]

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
>>>>
>>>>
>>>
>>
>