I have begun shipping virtual appliances for RFC8995(BRSKI) Registrars to Enterprises. I anticipate shipping SBOM information with the virtual appliance, and it would be relatively easy to do that via DHCP/LLDP MUD file.
I have been thinking about how to write up this MUD file. Most of the MUD ACLs are easy: 1) https access to update server 2) inbound ssh access for maintenance/diagnostics from a known place 3) inbound port-8443 access for BRSKI-EST connection 4) outbound GRASP announcements (3) and (4) may well fall below the level of most MUD controllers, since that will be enterprise internal (NOC) traffic. And I'm not sure that multicast destinations will realy fit well into what a MUD Controller might expect ACLs, but ... Then we get to: (5) outbound connections using HTTPS on undetermined ports to undetermined destinations for the BRSKI-MASA connections. The specific port that is connected to is determined by the MASA URL extension in the IDevID certificate. In writing RFC8995, we figured that we were removing a hassle to deployment by not requiring a specific port number. In particular, not using port-443. Eventually, the ACLs could be part of a supply chain integration, but for now, this is a problem for Enterprises that are hesitant to open port numbers. ** Now I think that we should have registered a port number for the BRSKI-MASA ** connection, which would have let us at least write a somewhat restrictive ** ACL. I'm unclear if it's possible to write a MUD ACL that permits connection to any host on a particular port. My reading of RFC8519 is that yes, one can have a l4.tcp ACL without having an l3 ACL. So, to make that workable, we'd at least need a registered port. -- Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
