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

[David Bird <[e-mail]>]

Kyle, I think participating in the hackathon is a great idea...

On Thu, Feb 23, 2017 at 9:01 AM, Kyle Larose <[e-mail]> wrote:

> Alright. Thanks everyone for the great discussion. Please continue. J
>
>
>
> It sounds like there may be some value in making more progress on the ICMP
> message simply so we can play around with exposing any security holes, and
> finding ways to plug them. So, it still seems like a good hackathon
> candidate to me.
>
>
>
> Also, since this is a hackathon, why not try to work on more than I can
> possibly handle? Let’s try to tackle the REST API for RFC 7710 as well.
> I’ll admit that I’m awful at defining REST APIs, and I don’t really have
> much experience with this technology, so I’m probably not right to do it,
> but maybe someone else could help contribute?
>
>
>
> Can someone maybe confirm the intent of the REST API? I vaguely recall a
> discussion at the BoF about allowing less interactive devices, such as
> smart watches, to authenticate without needing a browser. Was that it?
>
>
>
> There were some volunteers for writing a document defining the
> aforementioned REST API at the BoF. Is there a rough draft we could work
> from at the hackathon?
>
>
>
> Anyway, I think I’ll add the following to the hackathon wiki:
>
>
>
> Technology: Captive Portal
>
> Projects
>
> ·         Finish up the icmp I-D in coova-chili
>
> ·         Try out various client solutions for consuming the icmp message.
>
> ·         Try to find security holes in the icmp I-D, and plug them (the
> output being suggestions to improve the I-D)
>
> ·         Work on defining and implementing a REST API for RFC 7710
>
>
>
> How does that sound?
>
>
>
> Thanks,
>
>
>
> Kyle
>
>
>
> *From:* Dave Dolson
> *Sent:* Thursday, February 23, 2017 9:27 AM
> *To:* Erik Kline; David Bird
> *Cc:* [e-mail]; Kyle Larose; [e-mail]; Lorenzo
> Colitti
> *Subject:* RE: [Captive-portals] Thinking of something related to captive
> portals for the ietf98 hackathon
>
>
>
> 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:[e-mail]]
> *Sent:* Wednesday, February 22, 2017 9:52 PM
> *To:* David Bird
> *Cc:* Dave Dolson; [e-mail]; Kyle Larose;
> [e-mail]; Lorenzo Colitti
> *Subject:* Re: [Captive-portals] Thinking of something related to captive
> portals for the ietf98 hackathon
>
>
>
> 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
>
>
>