A new version of I-D, draft-richardson-opsawg-mud-acceptable-urls-03.txt has been successfully submitted by Michael Richardson and posted to the IETF repository.
Name: draft-richardson-opsawg-mud-acceptable-urls Revision: 03 Title: Authorized update to MUD URLs Document date: 2020-11-02 Group: Individual Submission Pages: 11 URL: https://www.ietf.org/archive/id/draft-richardson-opsawg-mud-acceptable-urls-03.txt Status: https://datatracker.ietf.org/doc/draft-richardson-opsawg-mud-acceptable-urls/ Html: https://www.ietf.org/archive/id/draft-richardson-opsawg-mud-acceptable-urls-03.html Htmlized: https://tools.ietf.org/html/draft-richardson-opsawg-mud-acceptable-urls-03 Diff: https://www.ietf.org/rfcdiff?url2=draft-richardson-opsawg-mud-acceptable-urls-03 Based upon unicast comments I received, I have posted a -03 version that has the following changes: > Suggest to add a paragraph to summarize MUD URL updating and MULD file > updating are two options, also explain why MUD URL or files need to be > updated? How about? # Updating MUD URLs vs Updating MUD files +There are two ways in which a manufacturer can change what the is processed by the MUD controller: they can change what is in the MUD file (update-in-place), and or they change which file is processed by the MUD controller by changing the URL (updated-url). + > 2. Section 2.1 > How does the end device know the capabilities need to be added or > removed? Is there signaling exchange between end device and firmware > server? If yes, please add reference or clarification text. No, the end device has no knowledge in the device of its capabilities. This is knowledge in the device. The knowledge resides in the manufacturer who creates the MUD file by human action. > If the device detected the firmware update, does it use the same MUD > URL to retrieve the MUD file? When? The MUD controller (which is not the device, but some role in the network orchestration), is the thing that retrieves the MUD file. Whether or not it uses the same MUD URL or not, is the topic of this section. > 3. Section 2.1.3 > I see section 2.1.3 are special example of adding capabilities and > removing capabilities? Consolidated into section 2.1.1, 2.1.2? I split out section 2.1.3 so that it could be referred to. In this case, it is unclear if it is adding or removing capabilities. It seems a special, and interesting case. > Is there any software or firmware update in the firewall device or > middlebox when TLS profile is retrieved? This is definitely an issue. There could be, and there has much discussion during the adoption process for I-D.reddy-opsawg-mud-tls about this. Not in scope for this document. > 4. Section 3 said: > " > It should be noted that [RFC8520<https://tools.ietf.org/html/rfc8520>] > has not established a trust model for MUD controllers to determine whether a signature from a specific > entity is legitimate as a signature for a particular device. > " > Don't understand this sentence, can you give an example to explain > this? I've rewritten like this: -It should be noted that {{RFC8520}} has not established a trust model for MUD controllers to -determine whether a signature from a specific entity is legitimate as a -signature for a particular device. {{RFC8520}} leaves this to the industry to work out through supply chain arrangements or other heuristics. +While {{RFC8520}} has established a mechanism for signing of MUD files, the document does not define a way for a MUD controller to determine who should sign the MUD file for a particular device. + +{{RFC8520}} leaves this for a local policy. +There are any number of processes that could be used, but they require coordination of many players. +It is expected that each industrial vertical will work out supply chain arrangements or other heuristics. I think that a lot could be said, but I don't want to go down a rathole here. Maybe I should? > 5. Section 7 > Is MUD File updating more related to RFC8520 while MUD URL update is > something proposed by this document? > What's your recommendation to the implementers or developer when they > face the choice of MUD URL updating or MUD file updating? Assuming that this document is adopted and MUD controllers implement it, then I would set a new MUD URL whenever there was a firmware update that created any change to the behaviour. I would reserve MUD file changes (which also involves signature updates) to fixing bugs in the MUD file only. I have updated: ## Updating files vs Updating MUD URLs + +Device developers need to consider whether to make a change by updating a MUD file, or updating the MUD URL. + +MUD URLs can only be updated by shipping a new firmware. +It is reasonable to update the MUD URL whenever a new firmware release causes new connectivity to be required. +The updated mechanism defined in this document makes this a secure operation, and there is no practical limitation on the number of files that a web server can hold. + +In place updates to a MUD file should be restricted to cases where it turns out that the description was inaccurate: a missing connection, an inadvertent one authorized, or just incorrect information. + +Developers should be aware that many enterprise web sites use outsourced content distribution networks, and MUD controllers are likely to cache files for some time. +Changes to MUD files will take some time to propogate through the various caches. +An updated MUD URL will however, not experience any cache issues, but can not be deployed with a firmware update. + + -- Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
