Hi Kyle, I'm not sure about the term "device" ... conceptually, I think maybe "enforcement function" is more appropriate. This enforcement function could be encoring captive portal, rate limiting, etc., so the "function" might even be split up between multiple pieces of software, potentially running on different devices in the network infrastructure.
I think it is beneficial to define formally what the enforcement function _should_ do. E.g. silently drop vs. send back notifications -- some vendors already send back ICMP / Dest Unreach / Filtered, some might do TCP RST, none of these give the UE any accurate insight into the fate of the packet. Cheers, David See https://www.juniper.net/documentation/en_US/junos/topics/concept/pcrf-pcef-ocs-interactions-understanding.html On Tue, Jun 26, 2018 at 5:40 PM Kyle Larose <[email protected]> wrote: > 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 >
_______________________________________________ Captive-portals mailing list [email protected] https://www.ietf.org/mailman/listinfo/captive-portals
