Hi Tim, Thanks very much for raising these questions. Although they are not on my slides for tomorrow (already submitted) I propose to address them first in person then if you can make it, or otherwise on list.
Regards, Eliot On 3/29/17 5:09 PM, Tim Polk wrote: > After a hallway conversation with one of the authors, I have reviewed > mud-05 in some depth and skimmed mud-net-lifecycle-00 and > mud-manu-lifecycle-01 for context. > > I think that the MUD protocol fills a very important gap in the supply > chain, in a reasonably elegant manner. Emitting a stable URI for the > MUD file provides a very low overhead mechanism to integrate a new > component into your network along with appropriate access controls. > The goals laid out in the introduction are largely satisfied, and > security controls seem appropriate. I am especially excited about the > application to IoT devices for the home consumer, but believe this has > distinct advantages for the enterprise as well. > > In short, I support advancing the document. > > That said, I have some issues with the draft I would like to raise. > > (1) Why are we excluding legacy devices from the benefits of MUD? If > the device does not emit the MUD URI, which is every legacy device, > then it is excluded from the system. If I obtain a MUD controller, I > would definitely want to apply this functionality to my previously > purchased legacy devices. Yes there are risks in obtaining this > information out-of-band, and the management overhead is much lower if > my devices convey the URI, but once I provision the controller with a > URI and identify the devices I will obtain many of the same benefits > to security. > > Supporting MUD files for legacy devices also allows me to maximize my > near-term ROI, which promote adoption... > > I would suggest adding a brief section 1.7 on legacy devices, simply > stating that manufacturers MAY make MUD files available for legacy > devices to support appropriate network configuration, and MUD > controllers MAY accept URIs for devices through out-of-band means. > > (2a) [Section 3.3] This draft uses a cache-validity period rather than > a next-update time to indicate when to check back. Given that > cache-validity prohibits checking back during the specified period, > are we comfortable with a recommended maximum value of 1440 hours (60 > days!)? > > Okay, that was a rhetorical question - I'm not comfortable with that > at all. Assume a revised MUD file is posted to address a new > vulnerability, and the controller always retrieves a fresh copy at the > first permissible moment, the average network supporting the > corresponding device will experience a post-discovery window of > vulnerability of 30 days on average. Given the expected size of the > file, why prohibit checking for so long? I understand that there are > concerns about MUD controllers hammering servers at high frequency, > but 7 days (168 hours) seems like a reasonable maximum to me. > > In more brevity, I suggest: > OLD > It is RECOMMENDED that this value be no less than 24 and no > more than 1440 for any device that is supported. > NEW > It is RECOMMENDED that this value be no less than 24 and no > more than 168 for any device that is supported. > > (2b) Better yet, should there be a MAXIMUM amount of time before the > checking for a new MUD file? As written, the MUD controller could > choose to never look for updates and be "conformant". We could add a > field to MUD file specifying the MAXIMUM amount of time, but a lighter > weight solution might be a recommendation that the MUD controller > refresh all MUD files whose cache-validity period has been exhausted: > > Append to the end of Section 3.3: > The MUD controller SHOULD refresh any MUD file whose cache-validity > period has been exhausted. > > (3) The introduction (section 1, top of pg 4, bullet 3) states that > MUD is intended to: > o Provide a means to address at least some vulnerabilities in away > that is faster than it might take to update systems. This will be > particularly true for systems that are no longer supported by > their manufacturer. > > In practice, this is probably true since so many devices are never > updated or are used beyond the supported lifetime. For this statement > to be more broadly correct, we would need a way to push a new MUD file > since cache-validity prohibits early checking. That is, once the > vulnerability is known and we post the new MUD file, the average time > to download and implementation of access rules is 50% of the > cache-validity period. > > Is this a reason to support subscription of a MUD-controller to a MUD > file distributor for emergency changes? I do not advocate changing > the MUD draft to incorporate this level of complexity, but if this is > our goals perhaps this should be addressed in a future draft... > > (4) I request a bit of indulgence here; I admit that this one is a bit > of a rant. > > The MUD protocol may have the unexpected consequence of perpetuating > bad developer behavior. There is no reason a baby monitor should > include a web browser, but the lazy developer just leaves the code in > their distribution. Removing the unnecessary code (so messages sent > to the offending port would be rejected) should provide stronger > security than constraints implicitly specified in the MUD file, and > both in concert would be ideal. > > Does this incentivize developers to make weak security choices and > "fix" them in the MUD file? I think that some text in the security > considerations stating that MUD is intended to complement and > strengthen well designed systems and does not relieve vendors of the > obligation to produce decent code is in order. > > (5) This may be a bridge too far for initial deployment, but (based on > my limited understanding of YANG) the architecture assumes that the > access controls are independent of device configuration. (That is, I > don't see any conditionals.) Is that really the case? For example, > if the devices still use the default administrator password I might > want to be more restrictive than after the passwords have been > updated. If I am a large enterprise, I might also want to substitute > infrastructure I own for the vendor supplied cloud that supports > operations. > > How do people envision dealing with this situation? If the network > operator has decided to override certain settings, does this preclude > use of future updates? > > > _______________________________________________ > OPSAWG mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/opsawg
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
