Hey David, Thanks for the feedback. In the current version ( https://www.ietf.org/id/draft-ietf-capport-architecture-02.txt) I haven't actually split anything up yet. That said, I'm open to renaming it to the enforcement function to better capture its logical nature.
Regarding further specifying its behaviour, do you have any suggestions for expanding section 2.4? It lays out what we expect the enforcement device/function to do somewhat informally. Are you thinking something along the lines of "MUST block traffic for disallowed user equipment". "SHOULD signal the UE with an explicit Signalling Protocol..." "SHOULD NOT masquerade as the destination for any blocked traffic"? Any others? On 28 June 2018 at 09:25, David Bird <[email protected]> wrote: > Forgive my typos... s/encoring/enforcing/ :) > > Also, worth noting... because enforcement functions have no way of > signaling captivity specifically, we have vendors today REDIRECTING HTTPS > (with all the security implications that carries) because they simply do > not want to just silently drop (user watching browser timeout) or do TCP > RST / existing ICMP (user sees browser fail). This is something we can and > should SOLVE! > > On Thu, Jun 28, 2018 at 6:08 AM David Bird <[email protected]> wrote: > >> 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
