Minutes IETF98: capport
minutes-98-capport-00

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