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

[Alexander Szlezak <[e-mail]>]

Hi David,

Nice to read you again. I could imagine the problems with consistency 
are related to complexity and poor documentation of wispr (especially of 
client side implementations) and could be mitigated by a simple and well 
documented RESTful API. I'm interested in more discussion related to 
this issue though.

best,

Alex


Am 22.02.17 um 16:26 schrieb David Bird:
> Agreed, we can take measures to thwart spoofing and other attack 
> vectors that are already present with ICMP signaling.
>
> I think a RESTful API is a good idea, one could argue it was already 
> tried with WISPr. Like WISPr, I think there would be problems with 
> consistency. I could imagine many web developers implementing the 
> RESTful API with varying degrees of features, compliance, bugs, etc.
>
>
>
> On Wed, Feb 22, 2017 at 6:53 AM, Dave Dolson <[e-mail] 
> <mailto:[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]
>     <mailto:[e-mail]>] on behalf of Lorenzo
>     Colitti [[e-mail] <mailto:[e-mail]>]
>     *Sent:* Wednesday, February 22, 2017 9:42 AM
>     *To:* David Bird
>     *Cc:* [e-mail] <mailto:[e-mail]>; Kyle Larose;
>     [e-mail] <mailto:[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]
>     <mailto:[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
>         <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] <mailto:[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
>             <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] <mailto:[e-mail]>
>             https://www.ietf.org/mailman/listinfo/captive-portals
>             <https://www.ietf.org/mailman/listinfo/captive-portals>
>
>
>
>         _______________________________________________
>         Captive-portals mailing list
>         [e-mail] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/captive-portals
>         <https://www.ietf.org/mailman/listinfo/captive-portals>
>
>
>
>
>
> _______________________________________________
> Captive-portals mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/captive-portals

-- 
Follow us on Twitter @
http://twitter.com/unwirednetworks

Mag. Alexander Szlezak
Unwired Networks GmbH
Founder & CEO

[phone]
[e-mail]
www.unwired.at

Gonzagagasse 11/25
1010 Vienna
Austria

Support: [e-mail]