Captive Portals (capport, captive-portals@ietf.org) IETF 98 Chicago 2017-03-28 1450-1620 CDT Zurich D Administrivia Martin Thomson 10m Japanese Survey Mariko Kobayashi 15m (slide 11) Lorenzo Colitti: We wrote code in 2014 to detect this, which version of Android are you using? Mariko Kobayashi: This is performed on Raspberry Pi imitating Android, not actual Android phone Martin Thomson: The assertion here is that server spoofs the HTTP 204 pretending to be Google server Yoav Nir: The situation is similar in other countries Lorenzo: This is good information. The Android code is changing all the time. Today it makes more than 2 checks and changes the hostname. I will give you an Android device to run this on it, I think it would be more useful. Using SSL ensures that even if the captive portal isn't complying the user can still access the Internet. We can work together on that. The Android link on slide 16 is correct and points to the current code. Tommy Pauly: Thanks for doing this, this is great! Using devices is great but all vendors should be open about what checks they use. There is an NEHotspotHelper API on iOS for captive portal vendors, you can also use it for research. The probing startegy is the same on iOS and macOS. Alex Roscoe: RIPE Atlas probes will soon have Wi-Fi. We should remember what captive portals respond Martin: Can you contribute to the code? Alex Roscoe: Yes Yoav: Portals are actively defeating the probe. Do we have any idea why there are doing this? Martin: There are many reasons, nothing confirmed David Schinazi: They don't necessarily like the UI and interaction experience client devices show by default, so they override it to be able to give their own UI Emily Stark: Chrome also has its own captive portal detection, have you tried testing what Chrome does? Jim Reed: What are your next steps? Mariko: Survey more countries, please let me know what you want to see Christian Saunders (Jabber): At Shaw we are able to use browser cookies to pre-register devices before they connect to our Wi-Fi network. We need the device browser and not the CNA browser in order to recover the browser token. Stephan Emile: Does you survey cover mobile devices and networks? Mariko: no draft-larose-capport-architecture-00 Kyle Larose 15m Lorenzo: We'll never get rid of the redirect. ICMP is messy, gets rate limited. If captive portal is time-based, tell device instead of relying on explicit message. Kyle Larose: Each component can help on their own with this acrhitecture Margaret Cullen: Doc should talk more about DHCP/RA from 7710. I fear these ICMP messages will be used as DOS attack. If we're asking vendors to implement a new spec, it needs to solve the problem better. Kyle: It's worth discussing the draft more, please discuss on list Margaret: We need further implementation, and if there is new code why stop here Pierre Pfister: Previous presentation discussed details of current implementations. This proposal is not backwards compatible, this may be OK but should be argumented strongly. Kyle: CAPPORT API server can support backwards compatibility Pierre: but the device getting the ICMP today will freak out Kyle: Is it worse than today with https? Pierre: good point Yoav: this is less clunky than what we have today. But what we have today works, and when it doesn't people are defeating it. The reasons that exist today will still be there David Bird: The ICMP message gives client more information by sending ICMP instead of blackholing. I don't see any security considerations Martin: you'd be surprised Chris Seal: How do you get the URI to the client? Kyle: Let's wait for next presentation Chris Seal: This is a great solution for prepaid customers that run out of credit Dave Dolson: The security risk exists but the token might solve it. Security properties are better than current. Also, the ICMP message cannot send the user to an arbitrary URL, only the DHCP/RA-provided URL. Receiving a forged ICMP message is not harmful except en masse. Erik Kilne: Perhaps by having ICMP echo something we can require the device to be on path Martin: Not enough entropy there sadly draft-bruneau-intarea-provisioning-domains-00 Tommy Pauly 15m David Bird: The URI you mentioned, what device would that point to? Tommy: It's open to discussion - it can be much further up Erik Kline: The first device would have to let it through Martin: Or you whitelist the IP Erik: I'm a fan of PvDs. They give a lot of information but maybe the PvD provider doesn't have the info. So we should have PvD point to CAPPORT to get further info. Lorenzo: I think this is great because 1) it might work and 2) even if it doesn't the PvD infrastructure will be so much better by solving this problem - e.g. handling the portal close, do we change the PvD? Meta-point: It should not ever be a goal for this group to optimize for the case where the portal wants to defeat client probes - this is an arms race that we can never win. We shouldn't handle conflicts of interest, this could make the API less paranoid. Tommy: Best case scenario we don't think about captive portals anymore they become networks that enforce a policy. David Bird: If the PvD info is on a different device it opens up possibility of misconfiguration Yoav: We can't win the arms race but we should understand what the portals want, and decide what we should let them see. Tommy: We should perform a survey for this. But the policy questions like UI maybe aren't best solved in this group. draft-donnelly-capport-detection-01 Mark Donnelly 15m Martin: this looks a lot like the ACME protocol Alexander Roscoe: To provide backwards compatibility we should use the 301 Redirect Captive portals are easier to upgrade than routers Martin: If there is a redirect this will work Jim Reid: Maybe don't use MD5, it's not important but MD5 looks bad Martin: Let's stick to high-level concepts here, but yes MD5 will raise flags Margaret: There is no way to prove that the user read the text so responding YES is good enough Mark : This allows us to change the terms and know which ones they read Erik Kline: What's the purpose of having multiple networks Mark Donnelly: Guest access vs corporate access for example Erik Kline: Does this need to be presented to the client though? Maybe use a VLAN in the backend instead Margaret: Other example is free access vs paid access Tommy: I also find multiple networks confusing, it should be handled by the backend Pierre Pfister: We're trying to solve multiple networks with PvDs, so we should avoid solving the problem twice If there are multiple networks this should be solved at L3 with RAs. This would be simpler and work better. Hackathon Report Kyle Larose 10m