Hey everyone, At IETF 100 in Singapore the capport working group discussed the ICMP option for captive portals, and how to identify user equipment at the various components of the architecture.
I've gone over the Etherpad notes(https://etherpad.tools.ietf.org/p/notes-ietf-100-capport?useMonospaceFont=true). Below is what I think is the summary, in point form, along with what I think was the consensus. Note that no hums occurred during the discussion; any conclusions are my opinion from reading the notes. Summary: - Discussed different deployment models: - Enforcement/API server on link with UE - Some combination of the above not being on link with the UE *** Consensus seemed to be that we must be flexible here to support carrier use-cases. *** - Discussed different identification methods: - Active/explicit (identity added by UE above lower layers in the request/packet -- e.g. session id) - various options: HMAC of UE information, local port id, etc. - Discussed whether the icmp message should contain a session ID that the UE can use to identify itself to the API server as an example of active identification. - Passive/implicit (identity inferred from normal addressing of device -- e.g. ip address) *** Consensus seemed to be leaning towards passive for security and simplicity reasons. *** - Discussed IPv4 vs IPv6, and how v6 seems to complicate matters with its ability to have many addresses for one UE: - Question was raised about whether we should restrict the number of v6 addresses (one address, one prefix, etc). - Related to the below discussion - Some discussion about what constitutes a new session: - new mac => new session? - new IP => new session? *** Didn't see any consensus about this, but I think we should continue that discussion. *** - I think there was a hint at multiple forms of enforcement: - What we've normally been calling the enforcement device: decide whether traffic can leave the network based on normal access rules - Enforcement of the identity of the source of the traffic: e.g. prevent spoofing so the API can trust passive data from the requests. *** Didn't really go anywhere that I could see, but probably warrants a bit more discussion. *** Other stuff I recall, but didn't see much of in the notes: - Seemed to be agreement that we should try to put together a list of use-cases being deployed now that could benefit from capport so we can understand the impact of any restrictions we place on it. - I recall something about restricting the UE, API server and ED to be on the same link (or provisioning domain?) from the UE's perspective to simplify the passive identification. Didn't see it in the notes, though, so I may be imagining it. - There seemed to be general support for a simple form of the ICMP option (i.e. keep it a simple notification of a problem, rather than communicating further state within it). We need to work on what exactly this entails, and what we lose by taking out the more advanced capabilities (i.e. maybe first round has the simple methods, but we can add more extensions as the base technology is adopted). That's it! Feel free to point out anything I've misinterpreted, or that is just plain wrong. Likewise, please point out anything important I've inadvertently omitted. Thanks! Kyle _______________________________________________ Captive-portals mailing list [email protected] https://www.ietf.org/mailman/listinfo/captive-portals
