Subject: [Mud] More disambituating MUD

From: "M. Ranganathan" <[email-masked]>
Date: Wed, 19 Jun 2019 14:24:49 -0400

I have two devices - one by manufacturer A and another by B

Mudfile for A says I can talk to devices made by B on port 80 TCP.

Mudfile for B says I can talk to devices made by A on any protocol / port.

It is reasonable to assume that most restrictive rules  should apply (i.e.
A and B can only interact using TCP port 80). Just checking assumptions....

Ranga

-- 
M. Ranganathan

---

From: Michael Richardson <[email-masked]>
Date: Wed, 19 Jun 2019 16:31:59 -0400

> Mudfile for B says I can talk to devices made by A on any protocol /

I think that we all assume is that all rules are "stateful", or apply to TCP
SYN packets only. Otherwise, A can't get packets back from B.  Maybe RFC8520
spells this out somewhere, I can't recall :-)

    > It is reasonable to assume that most restrictive rules should apply
    > (i.e.  A and B can only interact using TCP port 80). Just checking
    > assumptions....

The ACL has a default block at the bottom.
That means that the set of rules above that block should be an OR'ed together.
If we go with that, then it would not be most restrictive, but rather least
restrictive, but that means that B's mudfile can open up A for attack.

So, B *is* allowed to talk to any device on any port.  If it does so, it is
not in violation of it's MUD file.  So no alert.

Device A, however, did not allow *incoming* connections in it's MUD file
according to the rule you posted.  So, when B tries to talk to it, the
packets are dropped, just as if some script kiddie on the Internet was trying
to connect.  Device A is not violating it's MUD.   So, also no alert.

Where should a record of these denies go?  I'm not sure.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-