Re: [OPSAWG] Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06
> iff i can select which community's or communities' values form the sampling > bucket(s), this seems reasonable. if i am community transparent, i probably > don't want a bucket for each community on my inbound set. Yes, this sounds better. It can be achieved by configuring the intermediate process as in RFC6183. This could be a more reasonable use case for the new IE. Tianran ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Eric Rescorla's Discuss on draft-ietf-opsawg-mud-20: (with DISCUSS and COMMENT)
Hi Eliot, Thanks for continuing the conversation. My question is how this fits into the system as a whole. ISTM that there are two ways in which a MUD policy can affect the network's behavior: - Additive -- it lets the device do things it otherwise might not be permitted to do (e.g., accept incoming TCP connections) - Restrictive -- it stops the device from doing things that it otherwise would be permitted to do (e.g., make connections to IP addresses on non-443 ports) In the former case, it's very important not to be able to forge acceptable MUD policies, but in the latter case, an attacker can just not serve *any* MUD policy and be in a stronger position than they would be if they had a valid policy, Thus, it's only in the former (additive) case where forging a policy is useful to the attacker, and, in fact, it seems like accepting an unsigned MUD policy would be better than no policy. Given the ubiquity of non-MUD devices and the relatively limited capabilities that MUD seems to want to convey, it seems like the additive case isn't very useful. I should mention one use case that I did think of, where additive would be immediately useful: "This device is made by the same manufacturer as another device (and hence they can talk to each other). However, I note that MUD is actually not capable of securely conveying that, because there's no proof that the device in hand actually is made by the manufacturer, only that it possesses a public credential for some device made by that manufacturer. So, I'm actually left wondering how that feature is intended to work. I regret not catching this earlier, but perhaps you could explain? Thanks, -Ekr On Sun, Apr 15, 2018 at 11:27 PM, Eliot Lear wrote: > Hi Eric, > > Trimming. > > On 15.04.18 21:22, Eric Rescorla wrote: > > > > > >> IMPORTANT >> >> The certificate extension is described below. >> >> The information returned by the MUD file server (a web server) is >> valid for the duration of the Thing's connection, or as specified in >> the description. Thus if the Thing is disconnected, any associated >> configuration in the switch can be removed. Similarly, from time to >> >> IMPORTANT: What does "disconnected" mean in this context? Does a >> reboot count? What if I am wireless? This is a critical question if >> MUD is intended as a post-compromise mechanism. Say that an attacker >> compromises the firmware for a device and then forces a reboot >> followed by a 2 hour pause before the wireless NIC is activated. Will >> this result in configuration removal? If so, MUD seems of limited use, >> because it can then make itself appear to be a new device with a new >> MUD configuration. (This is of course true in general in a wireless >> context if the firmware can change the client's L2 address). >> >> >> Yes, configuration is intended to be removed when a device disconnects or >> a session terminates. This would be considered normal garbage collection. >> But whether or not you can simply replace the firmware and gain the same >> access will depend on how the MUD-URL is learned. If it is in a >> manufacturer certificate, for instance, that's not something an attacker >> will easily replace. If the assertion is coming via LLDP, or DHCP, then >> one has to apply the mitigations discussed in the security considerations >> section (and they are numerous). >> > > I'm not following you here. Say it's in a manufacturer certificate, what > stops me from getting my own certificate for Attacker LLC and then serving > a wide open policy? The mitigations don't really seem to do much to > counteract this. > > > I believe this point and one down below, where you write: > > This doesn't seem to address my concern, which is that there's no > realistic way of knowing > what trust anchors apply. If it's not WebPKI, then what? > > are related, and so I propose to address them together, and this text > could go into security considerations. The *intent* is that mud managers > or their providers will keep a list of known trusted signers. Examples are > likely to include certification bodies (we are aware of at least one that > is very interested), the MUD manager vendor themselves, and perhaps > others. Because these are early days, I don't want to be too declarative, > but we can say this: > > NEW: > > --- > MUD managers and their administrators MUST NOT automatically trust a > manufacturer's certificate simply because it validates. Rather, the > certificate MUST be signed by an entity that has previously established > trust for this explicit purpose. In particular, the WebPKI alone is not > appropriate. > --- > > > That means that just because Joe Evil signed the darn thing doesn't mean > that we should believe it. On the other hand, I might trust a security > company to vet this stuff. Would this address your concern? Also, I'll > correct the previous factual error. > > And again, I view this as early days. The architecture is going to need >
Re: [OPSAWG] Eric Rescorla's Discuss on draft-ietf-opsawg-mud-20: (with DISCUSS and COMMENT)
I haven't balloted yet, and this is EKR's ballot thread, but one point is worth bringing up here ... On Mon, Apr 16, 2018 at 7:25 AM, Eric Rescorla wrote: > Hi Eliot, > > Thanks for continuing the conversation. My question is how this fits into > the system as a whole. > > ISTM that there are two ways in which a MUD policy can affect the > network's behavior: > > - Additive -- it lets the device do things it otherwise might not be > permitted to do (e.g., accept incoming TCP connections) > - Restrictive -- it stops the device from doing things that it otherwise > would be permitted to do (e.g., make connections to IP addresses on non-443 > ports) > I've read previous versions of this draft and some of the mailing list discussion, but not a lot. Having said that, I hadn't heard anyone express the possibility of the additive case described here. The context I always heard about, was roughly "we've gotta keep all the coke machines on campus from doing anything except reporting that they need to be refilled", or whatever variation of cameras, printers, or *mumble* have access to your network for a specific reason, are running some arbitrary version of some OS stack that included TCP or UDP capabilities, aren't being maintained enough to be current on security patches, and aren't being managed, so are ripe for attacks to create botnets. Perhaps I need to get out more. Almost certainly. But ... the possibility of additive policies is interesting, and new to me. I'll be interested to watch this discussion. Eric, thanks for asking the question. Spencer In the former case, it's very important not to be able to forge acceptable > MUD policies, but in the latter case, an attacker can just not serve *any* > MUD policy and be in a stronger position than they would be if they had a > valid policy, Thus, it's only in the former (additive) case where forging a > policy is useful to the attacker, and, in fact, it seems like accepting an > unsigned MUD policy would be better than no policy. Given the ubiquity of > non-MUD devices and the relatively limited capabilities that MUD seems to > want to convey, it seems like the additive case isn't very useful. > > I should mention one use case that I did think of, where additive would be > immediately useful: "This device is made by the same manufacturer as > another device (and hence they can talk to each other). However, I note > that MUD is actually not capable of securely conveying that, because > there's no proof that the device in hand actually is made by the > manufacturer, only that it possesses a public credential for some device > made by that manufacturer. So, I'm actually left wondering how that feature > is intended to work. I regret not catching this earlier, but perhaps you > could explain? > > Thanks, > -Ekr > > > On Sun, Apr 15, 2018 at 11:27 PM, Eliot Lear wrote: > >> Hi Eric, >> >> Trimming. >> >> On 15.04.18 21:22, Eric Rescorla wrote: >> >> >> >> >> >>> IMPORTANT >>> >>> The certificate extension is described below. >>> >>> The information returned by the MUD file server (a web server) is >>> valid for the duration of the Thing's connection, or as specified in >>> the description. Thus if the Thing is disconnected, any associated >>> configuration in the switch can be removed. Similarly, from time to >>> >>> IMPORTANT: What does "disconnected" mean in this context? Does a >>> reboot count? What if I am wireless? This is a critical question if >>> MUD is intended as a post-compromise mechanism. Say that an attacker >>> compromises the firmware for a device and then forces a reboot >>> followed by a 2 hour pause before the wireless NIC is activated. Will >>> this result in configuration removal? If so, MUD seems of limited use, >>> because it can then make itself appear to be a new device with a new >>> MUD configuration. (This is of course true in general in a wireless >>> context if the firmware can change the client's L2 address). >>> >>> >>> Yes, configuration is intended to be removed when a device disconnects >>> or a session terminates. This would be considered normal garbage >>> collection. But whether or not you can simply replace the firmware and >>> gain the same access will depend on how the MUD-URL is learned. If it is >>> in a manufacturer certificate, for instance, that's not something an >>> attacker will easily replace. If the assertion is coming via LLDP, or >>> DHCP, then one has to apply the mitigations discussed in the security >>> considerations section (and they are numerous). >>> >> >> I'm not following you here. Say it's in a manufacturer certificate, what >> stops me from getting my own certificate for Attacker LLC and then serving >> a wide open policy? The mitigations don't really seem to do much to >> counteract this. >> >> >> I believe this point and one down below, where you write: >> >> This doesn't seem to address my concern, which is that there's no >> realistic way of knowing >> what tru
Re: [OPSAWG] Eric Rescorla's Discuss on draft-ietf-opsawg-mud-20: (with DISCUSS and COMMENT)
Hi Eric, On 16.04.18 14:25, Eric Rescorla wrote: > Hi Eliot, > > Thanks for continuing the conversation. My question is how this fits > into the system as a whole. > > ISTM that there are two ways in which a MUD policy can affect the > network's behavior: > > - Additive -- it lets the device do things it otherwise might not be > permitted to do (e.g., accept incoming TCP connections) > - Restrictive -- it stops the device from doing things that it > otherwise would be permitted to do (e.g., make connections to IP > addresses on non-443 ports) What you describe is the choice of the network administrator, and not the standard nor the manufacturer. You are essentially asking, “what is the default policy?” and that will vary based on deployment. It could be "additive", "restrictive", or something else. It could be a walled-off IoT network. Consider the cases: * This device has a MUD file and will be segmented accordingly. * This device has no MUD file and we may, o 1: give it no access, o 2: give it all access, o 3: give it some limited access, o 4: ask, or o 5: other. All of these are perfectly valid approaches, depending on the deployment. > > In the former case, it's very important not to be able to forge > acceptable MUD policies, but in the latter case, an attacker can just > not serve *any* MUD policy and be in a stronger position than they > would be if they had a valid policy,[...] And so that will depend on the deployment. And many of the attacks would be detectable. All? I would never be so bold. But also, MUD is not an acronym for "magic bullet". I really did try to spell that out in the draft. > I should mention one use case that I did think of, where additive > would be immediately useful: "This device is made by the same > manufacturer as another device (and hence they can talk to each > other). However, I note that MUD is actually not capable of securely > conveying that, because there's no proof that the device in hand > actually is made by the manufacturer, only that it possesses a public > credential for some device made by that manufacturer. That is the point of building out a PKI, and as I wrote, there are some interested in providing what amounts to a certification for this purpose. This is also something the MUD manager can take on: as time goes on it can white list signers, and it can flag devices that are not recognized as being risky. In addition, if you have someone willing to take accountability for that device to lay a claim, it may not be "proof", but that is good enough in an enterprise environment, where someone can be called to account for having added the device. And we have to start somewhere. The goal here it to establish a “walk before we run” approach in several dimensions. I just ask that we be allowed to walk ;-) With that, how would you like to proceed? I've proposed text but could go further if you like. Eliot signature.asc Description: OpenPGP digital signature ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Eric Rescorla's Discuss on draft-ietf-opsawg-mud-20: (with DISCUSS and COMMENT)
On Mon, Apr 16, 2018 at 6:55 AM, Eliot Lear wrote: > Hi Eric, > On 16.04.18 14:25, Eric Rescorla wrote: > > Hi Eliot, > > Thanks for continuing the conversation. My question is how this fits into > the system as a whole. > > ISTM that there are two ways in which a MUD policy can affect the > network's behavior: > > - Additive -- it lets the device do things it otherwise might not be > permitted to do (e.g., accept incoming TCP connections) > - Restrictive -- it stops the device from doing things that it otherwise > would be permitted to do (e.g., make connections to IP addresses on non-443 > ports) > > > What you describe is the choice of the network administrator, and not the > standard nor the manufacturer. You are essentially asking, “what is the > default policy? > No, I'm not asking that. What I'm looking for is the document to describe the various use cases and ensure that the mechanisms it provides actually be able to effect those use cases. In the former case, it's very important not to be able to forge acceptable > MUD policies, but in the latter case, an attacker can just not serve *any* > MUD policy and be in a stronger position than they would be if they had a > valid policy,[...] > > > And so that will depend on the deployment. And many of the attacks would > be detectable. > How would those attacks be detectable? I should mention one use case that I did think of, where additive would be > immediately useful: "This device is made by the same manufacturer as > another device (and hence they can talk to each other). However, I note > that MUD is actually not capable of securely conveying that, because > there's no proof that the device in hand actually is made by the > manufacturer, only that it possesses a public credential for some device > made by that manufacturer. > > > That is the point of building out a PKI, and as I wrote, there are some > interested in providing what amounts to a certification for this purpose. > This is also something the MUD manager can take on: as time goes on it can > white list signers, and it can flag devices that are not recognized as > being risky. In addition, if you have someone willing to take > accountability for that device to lay a claim, it may not be "proof", but > that is good enough in an enterprise environment, where someone can be > called to account for having added the device. > Well, there are two types of PKI here: 1. The one associated with the device certificate 2. The one associated with the MUD signature. My point is that only the former provides any assurance that the actual device has anything to do with the manufacturer. In the latter case, I can just stuff the URL of any manufacturer's MUD policy in my device that I please. -Ekr ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Alexey Melnikov's No Record on draft-ietf-opsawg-mud-20: (with COMMENT)
Alexey Melnikov has entered the following ballot position for draft-ietf-opsawg-mud-20: No Record When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/ -- COMMENT: -- I've only reviewed a part of the document, so sending you my current comments: 16.4. MIME Media-type Registration for MUD files The following media-type is defined for transfer of MUD file: o Type name: application o Subtype name: mud+json o Required parameters: n/a o Optional parameters: n/a o Encoding considerations: 8bit; application/mud+json values are represented as a JSON object; UTF-8 encoding SHOULD be employed. I am tempted to say "MUST be UTF-8 encoded". o Security considerations: See Security Considerations of this document. o Interoperability considerations: n/a o Published specification: this document Nit: IANA Media Type registration templates need to have fully qualified references. Use "[RFC]" instead of "this document" here, so that when the RFC is published, the registration template can be posted to IANA website and will have correct reference. o Applications that use this media type: MUD controllers as specified by this document. As above. o Fragment identifier considerations: n/a o Additional information: Magic number(s): n/a File extension(s): n/a Macintosh file type code(s): n/a o Person & email address to contact for further information: Eliot Lear , Ralph Droms I think Ralph's address is wrong in 2 places. o Intended usage: COMMON o Restrictions on usage: none o Author: Eliot Lear Ralph Droms o Change controller: IESG o Provisional registration? (standards tree only): No. UTF-8 needs to be a Normative reference (RFC 3629). ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Spencer Dawkins' Yes on draft-ietf-opsawg-mud-20: (with COMMENT)
Spencer Dawkins has entered the following ballot position for draft-ietf-opsawg-mud-20: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/ -- COMMENT: -- I'm a Yes who's watching Discussions with other ADs, but that's still a Yes. Thanks for doing this work. I do have some questions and comments. I don't think this requires any changes to the current document, but I note that 3.15. direction-initiated When applied this matches packets when the flow was initiated in the corresponding direction. [RFC6092] specifies IPv6 guidance best practices. While that document is scoped specifically to IPv6, its contents are applicable for IPv4 as well. When this flag is set, and the system has no reason to believe a flow has been initiated it MUST drop the packet. This node may be implemented in its simplest form by looking at naked SYN bits, but may also be implemented through more stateful mechanisms. it's not clear that "looking at naked SYN bits" will have an analogy in HTTP/2 over QUIC, and I'm a bit suspicious of "may also be implemented through more stateful mechanisms" in 2018. Do the right thing, of course. Does 3.5. is-supported This boolean is an indication from the manufacturer to the network administrator as to whether or not the Thing is supported. In this context a Thing is said to not be supported if the manufacturer intends never to issue an update to the Thing or never update the MUD file. A MUD controller MAY still periodically check for updates. ever mean anything except "is-updated"? "Supported" covers a lot of ground … If a manufacturer sells off one product line (so, flobbidy.example.com covered multiple product lines, but now flobbidy.example.com/mark1/lightbulb will be maintained by a manufacturer that isn't flobbidy.example.com), is there a good plan for what comes next? I'm not sure what happens to is-supported, for instance. I'm sensitive to Eliot's "walk before trying to run" comment on another ballot thread, but I'm thinking that 3.11. model This string matches the entire MUD URL, thus covering the model that is unique within the context of the authority. It may contain not only model information, but versioning information as well, and any other information that the manufacturer wishes to add. The intended use is for devices of this precise class to match, to permit or deny communication between one another. might usefully result in a BCP about naming models, after the community has some experience with MUD. So, that's not intended to affect the current draft text, only the working group that produced it ;-) And, double ;-) ;-) but I wrote that before I saw this text in Section 14: A caution about some of the classes: admission of a Thing into the "manufacturer" and "same-manufacturer" class may have impact on access of other Things. Put another way, the admission may grow the access-list on switches connected to other Things, depending on how access is managed. Some care should be given on managing that access-list growth. Alternative methods such as additional network segmentation can be used to keep that growth within reason. So, when people know enough to describe best practices, I hope they do. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] I-D Action: draft-ietf-opsawg-tacacs-10.txt
I have some concerns with the document, and with the process by which we've gotten here. Let me recap some history. There's a lot to take in, so I'll present concerns in point form. First, the document. * my "Security Considerations" text was first plagarised in draft-06, * when I pointed this out (May 9, 2017), there was no reply to my message by the authors, and no change was made to the document. * the ADs did respond, and indicated that they had talked to the authors about the issue, and that it was a simple misunderstand and would be fixed. * A year later, I raised the issue again (March 2018). There as no reply to my concerns by the authors, and no change was made to the document. * in all, 4 separate revisions of the document plagarized my text, for over a year, sometimes with minor edits, despite repeated requests to address the issue. Those issues alone are surprising. * The text which was good enough to plagarize was then claimed to have deficiencies * no one in the WG had noted any technical issues with the text * the only issues were with attribution, not with the text in the Security Considerations section * there is now a -10, which has essentially the same points as the previous text, just reworded I should point out that the RFC process is supposed to be about content, not authorship. There are many RFCs issued with text written by multiple people. Where the authors cannot all be acknowledged on the first page, the primary editor can be listed with the (Ed.) suffix, to indicate editorship. Other authors can be named as authors on the first page, or in the Acknowledgements section. Second, concerns with engagement with the WG. It continues. * multiple people in the WG have requested the authors engage with the Working Group. Most notably, many messages in May 2017. * multiple people in the WG have requested the authors explain what's changed in each new revision, or perhaps to acknowlege comments and reviews (May 2017 again, among other times). * This engagement has been minimal, despite multiple revisions of the document being published after these WG requests. * new revisions have most often been "thrown over the wall" with minimal (or no) explanation as to what changed, and why. * this new draft is no different, i.e. it "revised the security section". Why? How? What changed? What were any alleged "deficiencies"? * the author have stated again that they "will endeavor to be much more reactive to comments". * this statement or similar ones have been repeatdly, with little change in observable behavior. * The authors request (again) that the WG review this new document wholesale. Speaking of reviews, let's continue with third, responses to reviews. * I have given multiple line-by-line reviews of the entire document, for multiple revisions of the document. * as noted above, these reviews have generally been ignored. * as noted above, new versions of the document have appeared which may or may not have addressed these reviews. * Given the lack of feedback on the reviews before a new draft is issued, it is unclear whether the review comments have been addressed. * due to these issues, I have stopped reviewing the document, as it is not productive. There are other issues with the larger community. I'll continue. * there was broad support for publication of early revisions of the document, despite it clearly not describing the protocol in a way that permits inter-operable implementations * the people who supported adopting the document as a WG document have generally not reviewed or commented on it * existing implementors of TACACS+ have not reviewed or commented on the document (Alex Clouter's review was done as part of a brand-new implementation) * we have therefore no idea whether or not this document describes anything that anyone has implemented In order for the document to be published, we should have (at the minimum) statements from multiple implementors that the draft matches their implementations. Fourth, there are process issues, too. I'll continue. * the IETF has traditionally started a new WG to standardize new management protocols (i.e. a protocol new to the IETF) * examples include the protocols described in RFC 6632. These protocols have had their own working groups, going back to at least 1996, and continuing to the present * working on a new (and eventually standards track) document in the OPS area is therefore a new step for the IETF * I have raised all of the concerns mentioned herein with the chairs and ADs in private email, public email on the list, and in person at multiple meetings * There does not appear to be any action taken as a result. * Messages to the list raising these issues have largely been unaddressed It is general IETF practice for document authors to interact with the WG. And, to respond to WG reviews and co
Re: [OPSAWG] Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06
Sun, Apr 15, 2018 at 12:32:49PM -0400, Joel M. Halpern: > (the authors would not have written it if no one wanted it.) eh, that might not be a valid argument :) > Also, one of the arguments for doing this in the router is that you can > get more timely and precise correlation. Except that for geolocation of > address blocks, upstream correlation seems to be quite sufficiently > stable and precise. NLRI may come and go. I fone has geo-information, > it is unlikely to change. This may have been answered, but in case not or un-clear; what I and I believe others refer to here as geo location, is different from what you and randy are talking about in the sense of the IETF's prefixes. I do not always care about that location. I am placing my own marks on routes - where I hear them; region, country, metro, relationship with the neighbor, etc. Though it is not the whole story, this is typically of more interest to me. If a neighbor AS does similarly and sends them to me, I could make use of them. However, as you observed, these are all choices local to the AS - the values, whether to send them, etc. There is definitely a maintenance cost associate with using this data and a question of accuracy. Other's comments about accuracy and burden of external enrichment are valid. Whether this particular additional resolution is much of a burden on routers, I suspect not, but I am not an implementer. Authors: please use a spell checker. Also seems a few of the reference links are broken. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] (Also Ben Campbell's and Alexey's) Re: Spencer Dawkins' Yes on draft-ietf-opsawg-mud-20: (with COMMENT)
Responding to Spencer, Ben, and Alexy (in order). On 16.04.18 21:09, Spencer Dawkins wrote: > Spencer Dawkins has entered the following ballot position for > draft-ietf-opsawg-mud-20: Yes > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/ > > > > -- > COMMENT: > -- > > I'm a Yes who's watching Discussions with other ADs, but that's still a Yes. > Thanks for doing this work. > > I do have some questions and comments. > > I don't think this requires any changes to the current document, but I note > that > > 3.15. direction-initiated > >When applied this matches packets when the flow was initiated in the >corresponding direction. [RFC6092] specifies IPv6 guidance best >practices. While that document is scoped specifically to IPv6, its >contents are applicable for IPv4 as well. When this flag is set, and >the system has no reason to believe a flow has been initiated it MUST >drop the packet. This node may be implemented in its simplest form >by looking at naked SYN bits, but may also be implemented through >more stateful mechanisms. > > it's not clear that "looking at naked SYN bits" will have an analogy in HTTP/2 > over QUIC, and I'm a bit suspicious of "may also be implemented through more > stateful mechanisms" in 2018. Do the right thing, of course. I proposed a clarification: direction initiated is a TCP element. > > Does > > 3.5. is-supported > >This boolean is an indication from the manufacturer to the network >administrator as to whether or not the Thing is supported. In this >context a Thing is said to not be supported if the manufacturer >intends never to issue an update to the Thing or never update the MUD >file. A MUD controller MAY still periodically check for updates. > > ever mean anything except "is-updated"? Mostly that what it means, but the implication is that there's no support, and enterprise administrators in particular might want to know that (usually they do- because those devices represent a particular risk). > "Supported" covers a lot of ground … > > If a manufacturer sells off one product line (so, flobbidy.example.com covered > multiple product lines, but now flobbidy.example.com/mark1/lightbulb will be > maintained by a manufacturer that isn't flobbidy.example.com), is there a good > plan for what comes next? I'm not sure what happens to is-supported, for > instance. The intent is that the entity providing the MUD file (probably the manufacturer) will not be issuing software/firmware updates or MUD file updates. But your point is more about device lifecycle, and that's a more interesting question than just "is-supported". Steve Rich and Thorsten Dahm have begun to delve in that direction. There are at least a few possibilities, such as the use of redirects, or even domain names that are used for particular classes of devices, or even common repos. More work needed. > > I'm sensitive to Eliot's "walk before trying to run" comment on another ballot > thread, but I'm thinking that > > 3.11. model > >This string matches the entire MUD URL, thus covering the model that >is unique within the context of the authority. It may contain not >only model information, but versioning information as well, and any >other information that the manufacturer wishes to add. The intended >use is for devices of this precise class to match, to permit or deny >communication between one another. > > might usefully result in a BCP about naming models, after the community has > some experience with MUD. So, that's not intended to affect the current draft > text, only the working group that produced it ;-) > > And, double ;-) ;-) but I wrote that before I saw this text in Section 14: > > A caution about some of the classes: admission of a Thing into the >"manufacturer" and "same-manufacturer" class may have impact on >access of other Things. Put another way, the admission may grow the >access-list on switches connected to other Things, depending on how >access is managed. Some care should be given on managing that >access-list growth. Alternative methods such as additional network >segmentation can be used to keep that growth within reason. > > So, when people know enough to describe best practices, I hope they do. > Thanks, Spencer. We're just getting going. Now to Ben: > §1.6, 2nd paragraph: Why is the SHOULD not a MUST? Because at this stage
