Open ranganathanm opened 5 years ago
If port bindings are defined in both directions then I believe Mudmaker does the right thing.
I agree with this logic. The question is whether it is specific to same-manufacturer.
I thought about it but I could not come up with other cases where it is needed.
A device may communicate with another device iff there is a FROM-DEVICE rule AND a TO-DEVICE rule allowing communication.
Based on this assumption (theorem ?) I think MUDMAKER is missing some ACEs. Consider a same manufacturer rule. Device made by Manufacturer A can only talk to other devices made by A on port 80 TCP.
Here is the generated rule in the to-dev section
{ "name": "myman0-todev", "matches": { "ietf-mud:mud": { "same-manufacturer": [ null ] }, "ipv4": { "protocol": 6 }, "tcp": { "source-port": { "operator": "eq", "port": 80 } } }, "actions": { "forwarding": "accept" } } ] }
Here is the FROM-DEV ACE
{ "name": "myman0-frdev", "matches": { "ietf-mud:mud": { "same-manufacturer": [ null ] }, "ipv4": { "protocol": 6 }, "tcp": { "destination-port": { "operator": "eq", "port": 80 } } }, "actions": { "forwarding": "accept" } }
Consider a device made by manufactuer A that wants to talk to another instance of itself. It uses source port 888 and destination port 80 TCP protocol.
The From-dev rule will match but there is no to-dev rule that will match! The packet is therefore dropped.
Solution:
An ACE has to be added in both From-dev and To-dev sections. Here is the revised to-dev
{ "name": "myman0-todev", "matches": { "ietf-mud:mud": { "same-manufacturer": [ null ] }, "ipv4": { "protocol": 6 }, "tcp": { "source-port": { "operator": "eq", "port": 80 } } }, "actions": { "forwarding": "accept" } } ] }, { "name": "myman0-todev1", "matches": { "ietf-mud:mud": { "same-manufacturer": [ null ] }, "ipv4": { "protocol": 6 }, "tcp": { "destination-port": { "operator": "eq", "port": 80 } } }, "actions": { "forwarding": "accept" } } ] }
Thanks