During IETF 101 hackathon I played around with a modification to the architecture where a device adjacent to the user equipment ensures that it is not spoofing the implicit identity used by the captive portal deployment. This worked out pretty well.
So, the proposal is to create a second "enforcement" device whose responsibility is to ensure that traffic allowed into the captive network carries the identity expected by the network. This allows the deployment to vary in its topology -- the enforcement device need not be adjacent to the user equipment. This removes some concerns from the implicit identity, but it raises a new question: what should this new enforcement device do if the traffic is denied? Does it silently drop it, or should it signal back with the signalling protocol? I'm inclined at this point to not take this suggestion; I'm worried about the extra complexity of adding yet another component, and I think we can get by without it. What does everyone else think? I can provide more concrete examples/text if you'd like. Thanks. Kyle
_______________________________________________ Captive-portals mailing list [email protected] https://www.ietf.org/mailman/listinfo/captive-portals
