On Tue, Oct 24, 2017 at 05:23:34PM +0200, Eliot Lear wrote: > > -- There is default behavior associated with those classes. ( For > > example, you talk to DNS on port 53, NTP on port 123.) If a MUD rule > > specifies nothing (no ACEs) then these two classes exist invisibly as > > ALLOW rules. > > Yes. Invisible = default. The key point is that if we don't do this > then most vendors will end up doing their own thing, and this becomes a > management burden, and some are surely going to get them wrong, for that > matter.
[...] > > - The manufacturer can disable his device talking to dns and ntp > > services altogether by specifying DENY rules. Why specify a default > > behavior and multiple ways to override the default when the presumed > > reason is to save a few lines in the ACL file. > > > That's not the sole reason. There are multiple ways to implement these > rules, and it is best to have a single consistent way. So for instance, > one could implement them as permitting communication to ALL devices on > UDP port 53. One could implement them by stating that the name server > be admitted as "my-controller" on port 53. One could create a > vendor-specific controller class such as > "https://vendor.example.com/resolvers"; and permit that class on port > 53. And the challenge is that that class has to then be somehow > resolved. Better to have it as a default to simplify simple cases for > manufacturers and the network manager. Yes, this requires a bit of > extra code in the MUD controller, but as a design decision, we should > place the pain on ourselves. We can argue whether or not it is okay to > override this default– perhaps we shouldn't have that capability. But > certainly the default should be there. What you describe seem to be different policies. Are you saying that these different policies are bad or a huge management problem and hence we hard-code a default policy that is considered "good" in most situations? If you say removing the implied default rules results in a management burden, what is the reasoning? That having different rules for DNS (or NTP) would make debugging things more difficult? Given the vendors likely put creative and interesting rules into MUD files anyway, do two more rules matter? Would it be an option to have Appendix B an template that vendors SHOULD use if they want to allow access to DNS or NTP? Instead, of hardwiring it in the spec, we tell vendors that 'if you want to open up DNS and NTP, here is the suggested way to do this'. I am just trying to understand the reasoning for hardwiring two special cases. /js PS: Is there a logic how the rule names and acl names used in appendix B have been constructed? Does 'ent' mean something or is it a short form of 'entry'? Would v4-dns-in and v4-ntp-in be more descriptive than ent0-todev and ent1-todev and v4-dns-out and v4-ntp-out be more descriptive than ent0-frdev and ent1-frdev. Well, this might be to some extend subjective... -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
