https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-mud-13#section-14
The deployment considerations section notes: "Because MUD consists of a number of architectural building blocks, it is possible to assemble different deployment scenarios. One key aspect is where to place policy enforcement. In order to protect the Thing from other Things within a local deployment, policy can be enforced on the nearest switch or access point. In order to limit unwanted traffic within a network, it may also be advisable to enforce policy as close to the Internet as possible. In some circumstances, policy enforcement may not be available at the closest hop." Some side conversation came up yesterday in opsec as to how one can ensure that a MUD ACL is *only* applied to the traffic of the device that emitted the MUD URL? In particular in cases where the ACL can't be placed/bound to a specific device MAC/port on the first hop switch/AP, how do we ensure that the default "deny any" behavior of flows out of profile does not affect other systems. For example the first MUD ACL capable switching / routing device is on the upstream side of a NAT. Likewise, is it required that MUD profiles fully specify source/dest addresses in ACLs so that loosely specified ACLs don't collateral damage to flows from other systems? Is it possible for a piece of malware to emit a MUD URL that purposely gets an ACL applied to systems other than the one that emitted the URL? I am not saying I know this is a problem, it is just a question that came up in side discussions, that I don't know the answer to. At a minimum, saying something in the deployment consideration section about how we protect against accidental / malicious misapplication of MUD-profiles would be useful. -- DougM at NIST _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
