On 12 Sep 2017, at 14:48, Thorsten Dahm <[email protected]<mailto:[email protected]>> wrote:
Hi Einar, thanks for the reply. Let me clarify my thoughts below. :-) On 11 September 2017 at 17:03, Einar Nilsen-Nygaard (einarnn) <[email protected]<mailto:[email protected]>> wrote: But I do also agree that things like rate limits are, and should continue to be at the discretion of the network administrator. What rate limits do we talk about? Something like "maximum 10% of the available network bandwidth" is still significant traffic, I have a bunch of 100G links in my network. Or do we talk about QPS (Queries Per Second)? I agree there are many different “rates” that we can potentially talk about, and that characterisation of this in a way that can be usefully expressed as a “policy” (yeah, overused term, sorry!;-) is a separate task in and of itself. In essence, I wouldn’t seek to define what a network administrator’s “rate limits” are, but, from the MUD perspective, try and give a useful characterisation of its expected behavior. This characterisation could perhaps be used by the network administrator to complement their own policies. For example, if the administrator determines that her policy is “20 connection attempts per second”, a MUD policy saying a device type might be “30 connection attempts per second” would just be taken as an advisory, not something that needs to be embodied in policy. So now I have to keep track of the packets, keep a state, because I need to count packets. That means I now DDoS my own network by having to keep huge connection table somewhere (because with IoT, we may have thousands of different IoT devices in a single building) and can no longer have a simple stateless packet filter that would only allow TCP/443 to www.example.com<http://www.example.com/> as specified in the MUD file. As a network administrator, I would most likely ignore such a policy. Especially if it would require me to buy more expensive hardware, when one of the main arguments used for deploying IoT is actually cost savings. ;-) Fair point! :-) Another thought, maybe not relevant here, but for completeness: if company Example, with the website www.example.com<http://www.example.com/>, sells 1 million IoT devices that all connect back to their cloud on www.example.com<http://www.example.com/> but then have to rely on the rate limit setting in MUD because if all 1 million devices would send more than 1 packet per second to the website www.example.com<http://www.example.com/> it would go down, I would argue that it is time to scale up www.example.com<http://www.example.com/>. :-) And it would't be possible to DoS any other website than www.example.com<http://www.example.com/> if the MUD file is written and implemented by the network correctly. I don’t think any IoT device provider can or should rely on any network administrator actually implementing the policies defined via MUD. These can only ever be advisory in nature, right? However, if a manufacturer defines an expected rate lower than they would normally allow, that can potentially be an input to, for example, IDS configs. Right, but that would depend heavily on the IoT device, no? Yes, it could. Like a temperature sensor, how would I know if I want to report the temperature once a day, once every hour, once every 2 minutes without looking at the config? As an IDS admin, I would worry more about watching if the temperature sensor would try to send packets to anything else than my temperature collection server than how often it reports the temperature during the day. It would also open the door for false positives, like if you say you would not expect more than 5 packets per hour being send to www.example.com<http://www.example.com/> but then a software update is available and the thing would exchange maybe 100 packets with www.example.com<http://www.example.com/> to download the new firmware, my IDS would fire. I completely accept that there will be many scenarios where the operational profile of a device makes it unsuitable for simple, manufacturer-defined policy extension beyond access control via ACLs. If that is the case, a manufacturer should not try to define a policy that may do more harm than good. Maybe it is just me, but I wouldn't want to use MUD to configure my IDS. Maybe it’s just me, but I wouldn’t use MUD to directly configure anything. I would always use a MUD file as an advisory that I could use as part of the inputs to determining my configuration for all the relevant management and security components I use. Taking an IDS as an example of something that might consume policy beyond ACLs, I would use any expression of “rates” from a manufacturer purely as another source of information about certain devices and for my analytics algorithms, not as something I blindly implement. Overall, I was just making the point that it’s not only about ACLs. That’s why I suggested adding an extension point to the proposed model, rather than locking it down to just ACLs. Cheers, Einar cheers, Thorsten Cheers, Einar On 11 Sep 2017, at 16:28, Thorsten Dahm <[email protected]<mailto:[email protected]>> wrote: Hi Ranga, I think this would go beyond the job of MUD and would be at the discretion of the network administrator to enforce rate limits probably at the same network devices that are also responsible for implementing the packet filters and such. cheers, Thorsten On 8 September 2017 at 19:54, M. Ranganathan <[email protected]<mailto:[email protected]>> wrote: Hello! MUD currently does not enforce restrictions on temporal behavior. For example, I cannot specify how many times per second a device is allowed to connect to a remote IP address and port. Would this be worth considering? Use case: DDOS attack mitigation (?) Ranga -- M. Ranganathan _______________________________________________ OPSAWG mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/opsawg -- Thorsten Dahm Network Engineer Google Ireland Ltd. The Gasworks, Barrow Street Dublin 4, Ireland Registered in Dublin, Ireland Registration Number: 368047 _______________________________________________ OPSAWG mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/opsawg -- Thorsten Dahm Network Engineer Google Ireland Ltd. The Gasworks, Barrow Street Dublin 4, Ireland Registered in Dublin, Ireland Registration Number: 368047
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
