Subject: Re: [Mud] Convening MUD calls, + next steps

From: Eliot Lear <[email-masked]>
Date: Tue, 14 May 2019 13:37:54 +0200

Hi Ranga,

Following up on this message below, the ACL model has actions available.  One of the things we have spoken about was a means by which manufacturers could collect intelligence about how the MUD file is being interpreted.  That is- if the implementation is dropping packets or would drop packets based on the MUD file, provide some sort of aggregate feedback.  We need a draft on that alongside an implementation.

We talked a bit about this at one point, and the key is just making sure to match the drop against a particular MUD rule.  From an implementation standpoint that means logging drops, for a specific device, matching that device to a MUD URL, and then having some sort of contact information available for this purpose.

That’s a draft right there.

What I want to avoid is advising complex behaviors or behaviors that might require substantial resources on the part of the MUD manager.  An example of that is logging, because it can be resource-intensive.  If that is something that an administrator wants, do it in your MUD manager implementation.

At least that’s my thinking.  Am I wrong?

Eliot

> On 16 Apr 2019, at 18:43, M. Ranganathan <[email-masked]> wrote:
> 
> 
> 
> On Mon, Apr 15, 2019 at 9:59 PM Michael Richardson <[email-masked] <mailto:[email-masked]>> wrote:
> 
> M. Ranganathan <[email-masked] <mailto:[email-masked]>> wrote:
>     > One could presumably add action hints in the ACE on what to do with access
>     > violations (right now it is just "accept" or "deny" but one could be kinder
>     > and gentler - e.g. add a "log" action - which is to be interpreted as "log
>     > violations but allow"). For example:
> 
>     > "volations": {
>     > "forwarding" : "accept-log"
>     > }
> 
> As another example, let's say that there is access needed to a large number
> of content servers.  Simple examples would include firmware updates which are
> stored in non-deterministic CDNs, but also just consider a netflix model.
> 
> Consider a rule that basically says, "device X" -> "all of AWS space".
> One the one hand, that's pretty drastic!  The device could attack all sorts
> of things that live in AWS "Elastic IP" space.  On the other hand, that space
> does not include root name servers, core ISP routers, university dorm
> computers, and a lot of other critical infrastructure.
> (Can we find out what is "all of AWS space"?  I'm sure the list is long in
> v4, but in v6, it's probably not more than a few dozen prefixes)
> 
> However, if we would mitigate such a "all of AWS space" rule to include
> the bandwidth limits often discussed, or better yet, number of simulatenous
> connections (or more precisely, number of unique SYN packets/hour), then that
> would seriously limit things, and would work very well for firmware updates,
> and yes, maybe even netflix.
> 
> --
> Michael Richardson <[email-masked] <mailto:[email-masked]>>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
> 
> After some thought, I realized I mis-stated my suggested enhancement (possibly confusing) so let me try again but I'll keep it at a conceptual level.
> 
> A MUD file is essentially an if-then-else construct
> 
> 
> if (ACE[0] is OK) then forward
> else if (ACE[1] is OK) then forward
> ...
> else
>      DROP
> 
> I think what we're agreed on is that the DROP is too harsh as a blanket policy to apply. I am saying that we should be able to specify what to do if no forward action is possible.
> 
> That is, we could specify WHEN to drop, or WHEN we want to log and forward using matches on various conditions:
> 
> e.g.
> 
> DROP if packet is from a local network from / to Thing (assuming we don't want to tolerate East-west violations)
> FORWARD and log if packet is from Thing to DNS named host (and inform the Manufacturer).
> 
> This is at the conceptual level. I am not sure how to work this neatly into the MUD YANG model etc. Here is a very rough example
>  "ietf-mud:mud": {
>     "mud-version": 1,
>     "mud-url": "https://controllerclass-test.nist.local/super1 <https://controllerclass-test.nist.local/super1>",
>     "last-update": "2018-03-11T19:44:23+01:00",
>     "cache-validity": 48,
>     "is-supported": true,
>     "systeminfo": "https://mud.nist.local/toaster <https://mud.nist.local/toaster>",
>     "from-device-policy": {
>       "access-lists": {
>         "access-list": [
>           {
>             "name": "mud-38382-v4fr"
>           }
>         ]
>       }
>     },
>     "to-device-policy": {
>       "access-lists": {
>         "access-list": [
>           {
>             "name": "mud-38382-v4to"
>           }
>         ]
>       }
>     },
>     "violations" : {
>             "local-networks" : "drop",
>             "dns-name" : "forward-log"
>     }
>   }
> 
> (I added the last piece). Is there any way of stating this neatly?
> 
> Thanks for reading.
> 
> Regards,
> 
> Ranga.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> --
> You received this message because you are subscribed to the Google Groups "mud-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to [email-masked] <mailto:[email-masked]>.
> To post to this group, send email to [email-masked] <mailto:[email-masked]>.
> To view this discussion on the web visit https://groups.google.com/d/msgid/mud-discuss/10007.1555379966%40localhost <https://groups.google.com/d/msgid/mud-discuss/10007.1555379966%40localhost>.
> For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.
> 
> 
> --
> M. Ranganathan
> 
> 
> --
> You received this message because you are subscribed to the Google Groups "mud-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to [email-masked] <mailto:[email-masked]>.
> To post to this group, send email to [email-masked] <mailto:[email-masked]>.
> To view this discussion on the web visit https://groups.google.com/d/msgid/mud-discuss/CAHiu4JO-iY1h02pKaJzP%3DeU4WvTn_9HpghnPdynrxEupwh8CPw%40mail.gmail.com <https://groups.google.com/d/msgid/mud-discuss/CAHiu4JO-iY1h02pKaJzP%3DeU4WvTn_9HpghnPdynrxEupwh8CPw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.

---

From: "M. Ranganathan" <[email-masked]>
Date: Tue, 14 May 2019 15:03:14 -0400

Hello Eliot,

On Tue, May 14, 2019 at 7:37 AM Eliot Lear <[email-masked]> wrote:

> Hi Ranga,
>
> Following up on this message below, the ACL model has actions available.
> One of the things we have spoken about was a means by which manufacturers
> could collect intelligence about how the MUD file is being interpreted.
> That is- if the implementation is dropping packets or would drop packets
> based on the MUD file, provide some sort of aggregate feedback.  We need a
> draft on that alongside an implementation.
>

Defining the format of such feedback would be useful I think.

> We talked a bit about this at one point, and the key is just making sure
> to match the drop against a particular MUD rule.  From an implementation
> standpoint that means logging drops, for a specific device, matching that
> device to a MUD URL, and then having some sort of contact information
> available for this purpose.
>

Request some clarifications on the proposed behavior:

MUD is a series of "ACCEPT" rules followed by an implicit DROP rule. So how
can we know that a specific MUD rule caused a packet to be dropped? All we
know when the packet is dropped (or marked for drop) is that NO mud rule
allowed the packet to proceed.

Thanks,

Ranga

> What I want to avoid is advising complex behaviors or behaviors that might
> require substantial resources on the part of the MUD manager.  An example
> of that is logging, because it can be resource-intensive.  If that is
> something that an administrator wants, do it in your MUD manager
> implementation.
>
> On Mon, Apr 15, 2019 at 9:59 PM Michael Richardson <[email-masked]>
> wrote:
>
>>
>> M. Ranganathan <[email-masked]> wrote:
>> Michael Richardson <[email-masked]>, Sandelman Software Works
> After some thought, I realized I mis-stated my suggested enhancement
> (possibly confusing) so let me try again but I'll keep it at a conceptual
> level.
>
> I think what we're agreed on is that the DROP is too harsh as a blanket
> policy to apply. I am saying that we should be able to specify what to do
> if no forward action is possible.
>
> This is at the conceptual level. I am not sure how to work this neatly
> into the MUD YANG model etc. Here is a very rough example
>  "ietf-mud:mud": {
>     "mud-version": 1,
>     "mud-url": "https://controllerclass-test.nist.local/super1",
>     "systeminfo": "https://mud.nist.local/toaster",
>     "from-device-policy": {
>       "access-lists": {
>         "access-list": [
>           {
>             "name": "mud-38382-v4fr"
>           }
>         ]
>       }
>     },
>     "to-device-policy": {
>       "access-lists": {
>         "access-list": [
>           {
>             "name": "mud-38382-v4to"
>           }
>         ]
>       }
>     },
>     "violations" : {
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email-masked].
>> To post to this group, send email to [email-masked].
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/mud-discuss/10007.1555379966%40localhost
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
> M. Ranganathan
>
>
> --
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email-masked].
> To post to this group, send email to [email-masked].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/mud-discuss/CAHiu4JO-iY1h02pKaJzP%3DeU4WvTn_9HpghnPdynrxEupwh8CPw%40mail.gmail.com
> <https://groups.google.com/d/msgid/mud-discuss/CAHiu4JO-iY1h02pKaJzP%3DeU4WvTn_9HpghnPdynrxEupwh8CPw%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
>

-- 
M. Ranganathan

---

From: Eliot Lear <[email-masked]>
Date: Tue, 14 May 2019 22:41:10 +0200

> On 14 May 2019, at 21:03, M. Ranganathan <[email-masked]> wrote:
> 
> Hello Eliot,
> 
> On Tue, May 14, 2019 at 7:37 AM Eliot Lear <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Ranga,
> 
> MUD is a series of "ACCEPT" rules followed by an implicit DROP rule. So how can we know that a specific MUD rule caused a packet to be dropped? All we know when the packet is dropped (or marked for drop) is that NO mud rule allowed the packet to proceed.
> 

On the whole this is generally true.  The fact that the packet was dropped means that NONE of the accept rules were met, and that’s a lot of information right there.  ie, my-controller, same-manufacturer etc didn’t match, or they matched a reject rule.  Do others have thoughts there?

Eliot

---

From: Michael Richardson <[email-masked]>
Date: Tue, 14 May 2019 18:13:42 -0400

Eliot Lear <[email-masked]> wrote:
    mr> MUD is a series of "ACCEPT" rules followed by an implicit DROP rule. So
    mr> how can we know that a specific MUD rule caused a packet to be dropped?
    mr> All we know when the packet is dropped (or marked for drop) is that NO
    mr> mud rule allowed the packet to proceed.

    > On the whole this is generally true. The fact that the packet was dropped
    > means that NONE of the accept rules were met, and that’s a lot of information
    > right there. ie, my-controller, same-manufacturer etc didn’t match, or they
    > matched a reject rule. Do others have thoughts there?

But the rules aren't actually fully specific.
They get instantiated:
  1) source is the device (by... L2? L3? depends upon implementation)
  2) destination is an IP, but rule is by name, so how did DNS resolve?

It would be ideal if one could identify packets that would have matched if
only the source was different, or the destination was resolved differently.
This requires a bit of fuzzy matching against the drop-log.

That probably accounts for 9 out 10 situations where packets were dropped
that were not really malicious.

---

From: "M. Ranganathan" <[email-masked]>
Date: Tue, 14 May 2019 20:22:56 -0400

> that were not really malicious.

If we put a Source MAC/IP classification to activate a notification action
in place of the implied drop, we could notify on the basis of
those classifications.

The implementation mechanism that is used to classify packets is not so
relevant IMHO.

What is important is that the packets, get classified and then get dropped
because they
misbehave. The MUD rules are stated on the basis of these classifications.

So while you cannot state that a specific MUD rule caused a drop, you CAN
state that a particular classification of packets caused a drop.

Why not use the same classification mechanism that MUD uses to notify that
a packet originated by the
MUD-enabled device did something that the MUD rules disallowed?

This would allow the administrator to select the notifications that he
wants to provide to the manufacturer.

-- 
M. Ranganathan

---

From: "M. Ranganathan" <[email-masked]>
Date: Mon, 20 May 2019 10:06:26 -0400

Are there any standard logging formats to report "misbehavior"?  Maybe just
use syslog (RFC 3164)?

What should the tuning parameters be? I was thinking, frequency of sampling
and packet rate estimation.

I came across the following which looked interesting:

https://www.cisco.com/c/en/us/td/docs/security/asa/asa82/configuration/guide/config/monitor_nsel.html#wp1111174%0A

-- 
M. Ranganathan

---

From: Michael Richardson <[email-masked]>
Date: Tue, 21 May 2019 12:09:48 -0400

> Are there any standard logging formats to report "misbehavior"? Maybe just

It's a good question!
From the gateway to... ? what's the place we should report to?
Probably the ISP for aggregation.  It would be nice if the DHCPv6 included
an attribute as to what that was.
   - ROLIE/MILE
   - INCH/IODEF

I've tried to capture some options in the un-quarantine slides at:
  https://github.com/CIRALabs/shg-un-quarantine/blob/master/presentations/RIPE-IoT-Unquarantine-expanded.pdf
slide 34.

To share details of the event, though, the list includes:
    - SCAPv2 (rolie)
    - MISP
    - TAXI (rolie), STIIX

    > and packet rate estimation.

what do you mean here?

    > https://www.cisco.com/c/en/us/td/docs/security/asa/asa82/configuration/guide/config/monitor_nsel.html#wp1111174%0A

So this uses Netflow, or this uses Syslog? (or some combination)
I didn't understand it that well.

---

From: "M. Ranganathan" <[email-masked]>
Date: Tue, 21 May 2019 13:26:25 -0400

> From the gateway to... ? what's the place we should report to?

The reporting URL could be specified as a MUD extension (?). Maybe report
back to manufacturer so he can have additional information to fix the
problem.

> To share details of the event, though, the list includes:

This is interesting but beyond the scope of what I had in mind. I think to
start, a simple event notification mechanism (along with a standardized
format for the events) should be a good starting point. (WDYT?)

>     > and packet rate estimation.

Scenario :

A device misbehaves. It is put into quarantine (can only access quarantine
ACEs).  While it is under quarantine, "Administrator" would like to know
statistics about what the device is actually doing under quarantine. How
often should this state be reported back to the administrator. One could
report back this information periodically. If so, at what frequency.

> I didn't understand it that well.

I don't understand NSEL that well either (have not played with it --
perhaps Eliot has some insights). In particular, it would not directly
apply because there are no DENY ACEs in MUD except for the one if it does
not match any previous rule and the TCP direction (which is an implicity
deny rule). We would have to suitably modify the semantics. I was thinking
we could modify it to carry information about the class of packet based on
the source that was dropped.

Thanks,

-- 
M. Ranganathan