On Mar 25, 2022, at 3:18 PM, Oleg Pekar <[email protected]> wrote: > > >When this configuration process fails or does not work, there is typically > >no way to inform the user or administrator as to what went wrong. Which > >makes it essentially impossible to debug configuration and compatibility > >issues. > [Oleg] If the configuration process is conducted by a centralized system > (connected to EAP authentication server) then each step of configuring a > specific supplicant can be tracked on the system, inducing the final result. > So the admin can see it and undertake some recovery action. What are the > example scenarios where such tracking is impossible?
It's not about tracking, it's about debugging. The administrator may see "failed at step 4 out of 5". OK, what can be done with that information? There is no path to the end-user system which allows for manual correction or updates. Since provisioning is part of EAP, there is no path to the user to inform the user as to what went wrong, or how to fix it. If instead configuration is done via a "real" network (even a limited one), things get better. The administrator can still see which steps went wrong, but may also have a "back channel" to the device in order to fix things. The user can run a local tool, perhaps even with a GUI, which presents useful error messages. RFC 3748 Section 5.2 provides for EAP notifications, but most supplicants treat those as failure. And don't display anything to the user. I think we don't want to shoe-horn a general-purpose notification system into EAP. Even if we add something internal to an EAP type, that information still has to be carried (somehow) through to the user interface. > >However, the benefit of this approach is that the provisioning system > >becomes infinitely flexible. It can use any existing internet protocol. It > >can download any amount of data. > [Oleg] There are existing configuration and provisioning methods that require > the supplicant to connect to a quarantine network and get the IP layer this > way, then the provisioning software or manual user actions do the > configuration. But this method is usually proprietary per network access > control system and is pretty complicated. We can standardize this method: > create a configuration and provisioning protocol over IP (not EAP) that will > be supported by supplicants and network access control systems and all they > need to do before is to accept the supplicant on the quarantine network. I support such standardization. Ideally using existing networking protocols. For example, RFC 8572 provides for similar tools (DNS SRV records + YAML / RESTCONF) for provisioning devices. If it works for devices, why not do something similar for end-user devices? Alan DeKok. _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
