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

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

On Tue, May 21, 2019 at 12:09 PM Michael Richardson <[e-mail]>
wrote:

>
> M. Ranganathan <[e-mail]> wrote:
>     > Are there any standard logging formats to report "misbehavior"?
> Maybe just
>     > use syslog (RFC 3164)?
>
> It's a good question!
> 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.


> 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
>

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?)


>     > What should the tuning parameters be? I was thinking, frequency of
> sampling
>     > and packet rate estimation.
>
> what do you mean here?
>

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 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
>
> So this uses Netflow, or this uses Syslog? (or some combination)
> 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,



> --
> Michael Richardson <[e-mail]>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
>
>
>
>

-- 
M. Ranganathan