[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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 <[email protected]> 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 [captive-portals-bounces@ietf.org] on behalf of Lorenzo Colitti [[email protected]]
Sent: Wednesday, February 22, 2017 9:42 AM
To: David Bird
Cc: [email protected]; Kyle Larose; [email protected]
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 <[email protected]> wrote:
Hi Kyle,

I think that is a great idea! 


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,

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
[email protected]
https://www.ietf.org/mailman/listinfo/captive-portals


_______________________________________________
Captive-portals mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/captive-portals





_______________________________________________
Captive-portals mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/captive-portals


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

Mag. Alexander Szlezak          
Unwired Networks GmbH
Founder & CEO

+43 660 1350410
[email protected]           
www.unwired.at

Gonzagagasse 11/25
1010 Vienna
Austria

Support: [email protected]