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

["M. Ranganathan" <[e-mail]>]

Hello Eliot,

On Tue, May 14, 2019 at 7:37 AM Eliot Lear <[e-mail]> 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




>
> 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]>
> wrote:
>
>>
>> M. Ranganathan <[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]>, 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",
>     "last-update": "2018-03-11T19:44:23+01:00",
>     "cache-validity": 48,
>     "is-supported": true,
>     "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" : {
>             "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].
>> To post to this group, send email to [e-mail].
>> 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
>
>
> --
> 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].
> To post to this group, send email to [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.
>
>
>

-- 
M. Ranganathan