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

[Eliot Lear <[e-mail]>]

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 <[e-mail]> wrote:
> 
> 
> 
> On Mon, Apr 15, 2019 at 9:59 PM Michael Richardson <[e-mail] <mailto:[e-mail]>> wrote:
> 
> M. Ranganathan <[e-mail] <mailto:[e-mail]>> 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 <[e-mail] <mailto:[e-mail]>>, 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 [e-mail] <mailto:[e-mail]>.
> To post to this group, send email to [e-mail] <mailto:[e-mail]>.
> 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 [e-mail] <mailto:[e-mail]>.
> To post to this group, send email to [e-mail] <mailto:[e-mail]>.
> 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>.