Subject: [OPSAWG] draft-ietf-opsawg-mud-08: Restricting temporal behavior using MUD.

From: "M. Ranganathan" <[email-masked]>
Date: Fri, 8 Sep 2017 14:54:02 -0400

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

---

From: Thorsten Dahm <[email-masked]>
Date: Mon, 11 Sep 2017 16:28:48 +0100

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-masked]> wrote:

> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> 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

---

From: "Einar Nilsen-Nygaard (einarnn)" <[email-masked]>
Date: Mon, 11 Sep 2017 16:03:36 +0000

While I agree that this is beyond the scope of the initial MUD draft, I’m not sure I agree that this is beyond the scope of MUD in the longer term.

If a manufacturer can define behavior in this way, why wouldn’t it possibly be a new policy type that can be an extension/augmentation to the MUD YANG module?

But I do also agree that things like rate limits are, and should continue to be at the discretion of the network administrator. 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. 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.

Cheers,

Einar

On 11 Sep 2017, at 16:28, Thorsten Dahm <[email-masked]<mailto:[email-masked]>> 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-masked]<mailto:[email-masked]>> 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.

Use case:

Ranga

--
M. Ranganathan

_______________________________________________
OPSAWG mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/opsawg

--
Thorsten Dahm

Network Engineer
Google Ireland Ltd.

[email-masked]<mailto:[email-masked]>

---

From: Thorsten Dahm <[email-masked]>
Date: Tue, 12 Sep 2017 14:48:17 +0100

Hi Einar,

thanks for the reply. Let me clarify my thoughts below. :-)

On 11 September 2017 at 17:03, Einar Nilsen-Nygaard (einarnn) <
[email-masked]> 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)?

> 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 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. ;-)

Another thought, maybe not relevant here, but for completeness: if company
Example, with the website www.example.com, sells 1 million IoT devices that
all connect back to their cloud on 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 it would go
down, I would argue that it is time to scale up www.example.com. :-) And it
would't be possible to DoS any other website than www.example.com if the
MUD file is written and implemented by the network correctly.

> 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? 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 but then a software update is available and the thing would
exchange maybe 100 packets with www.example.com to download the new
firmware, my IDS would fire.

Maybe it is just me, but I wouldn't want to use MUD to configure my IDS.

cheers,
Thorsten

>
> Cheers,
>
> Einar
>
> On 11 Sep 2017, at 16:28, Thorsten Dahm <[email-masked]> wrote:
>
>
> Hi Ranga,
>

-- 
Thorsten Dahm

Network Engineer
Google Ireland Ltd.

---

From: "Einar Nilsen-Nygaard (einarnn)" <[email-masked]>
Date: Tue, 12 Sep 2017 15:34:59 +0000

On 12 Sep 2017, at 14:48, Thorsten Dahm <[email-masked]<mailto:[email-masked]>> wrote:

Hi Einar,

On 11 September 2017 at 17:03, Einar Nilsen-Nygaard (einarnn) <[email-masked]<mailto:[email-masked]>> 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’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

Hi Ranga,

cheers,
Thorsten

Use case:

Ranga

--
M. Ranganathan

--
Thorsten Dahm

Network Engineer
Google Ireland Ltd.

--
Thorsten Dahm

Network Engineer
Google Ireland Ltd.

---

From: Thorsten Dahm <[email-masked]>
Date: Wed, 13 Sep 2017 14:53:01 +0100

On 12 September 2017 at 16:34, Einar Nilsen-Nygaard (einarnn) <
[email-masked]> wrote:

> Maybe it’s just me, but I wouldn’t use MUD to *directly* configure
> anything.
>

I couldn't agree more. Yes, absolutely, full ACK. It's only an advise given
by the manufacturer, not a network confg file.

cheers,
Thorsten

-- 
Thorsten Dahm

Network Engineer
Google Ireland Ltd.