On Thu, 27 Dec 2018 at 14:14, David Bird <[email protected]> wrote: > > The section titled "Risk of Nuisance Captive Portal" should really be > talking about networks that USE the API and have NO network integration (e.g. > Captive by API only, not by any network enforcement function). >
I think the nuisance captive portal SIGNALS are a legitimate concern. However, you raise a good point: we can't entirely trust the API -- it may become decoupled from the network for many reasons: an attack, a bug, misconfiguration, etc. So, now we're talking about the risk of a nuisance API as well as nuisance signals. I think we had been calling this a non-issue because UE discovers the API from somewhat trusted sources -- DHCP/RA,PvD. But, let's assume that the API is a bad actor for some reason -- discovery was compromised, the API itself was compromised, or it's just plain broken. Thinking about that case, you could have: 1. The API says that you have access when you don't. 2. The API says that you have access when you do. 3. The API says that you don't have access when you do. 4. The API says that you don't have access when you don't. We don't need to worry about 2, since things should just work. For 4, it could be a problem in that the portal will never really grant access... I discuss that a bit further down. In case 1. the system will try to access the network and fail. Barring probe functionality, this means that the system will simply fail to attach to the network properly. There's no good solution without user intervention. With probes, I think it works out naturally -- the system will work as it does today. But, without probes, I can't think of a nice solution.This is a concern that has been raised in the past (I think by you, David), since it means that we will still need probes for a "nice experience". In case 3. the UE will attempt to visit the portal. I can think of a few sub-cases here: a) The URI of the portal is bad/non-existent b) The URI is present, works and the portal says you have access c) The URI is present, works and the portal refuses to grant access. b) is easy: the UE proceeds with its connection and everything works. We need to consider a) a bit, since it's a fairly likely failure mode. I think it's probably safe to assume that, barring probes, network access is unavailable on this network, and the system should treat it as such. c) I think this should probably behave the same as a), though it's a bit nicer in that the user has actual feedback. It's a little unfortunate that with a) and c), the UE should have network access, but the user thinks they do not. What if they know that they should for some reason? Perhaps the recommendation should be to treat it as though network access is unavailable, barring explicit direction from the user to use the network, or confirmation that network access is available through probes. Case 4 can likely be handled in a similar way to case 3 -- you never get access, so the user either chooses a different network, or overrides the system's default, which then proves to them that the network does not provide access. > Happy Holidays! > > Cheers, > David > > _______________________________________________ Captive-portals mailing list [email protected] https://www.ietf.org/mailman/listinfo/captive-portals
