elear / mud Goto Github PK

It looks like the parsing in mud_controller.py (from your demo code) for the json files generated by mudmaker no longer work due to updates. Looks like there were also mixed whitespace errors.

It would be good to indicate that the demo code is out of date.

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

In index.html If the pattern match on fails, the error message produced is what the browser says (at least by default).

I entered a null (no value) for the manufacturer when generating a MUD file. I got the following MUD file:

{
  "ietf-mud:mud": {
    "mud-version": 1,
    "mud-url": "https://sensor.nist.local/foo",
    "last-update": "2019-07-18T18:01:06+00:00",
    "cache-validity": 48,
    "is-supported": true,
    "systeminfo": "test device",
    "mfg-name": "NIST",
    "documentation": "https://www.nist.local",
    "model-name": "foo",
    "from-device-policy": {
      "access-lists": {
        "access-list": [
          {
            "name": "mud-63570-v4fr"
          }
        ]
      }
    },
    "to-device-policy": {
      "access-lists": {
        "access-list": [
          {
            "name": "mud-63570-v4to"
          }
        ]
      }
    }
  },
  "ietf-access-control-list:acls": {
    "acl": [
      {
        "name": "mud-63570-v4to",
        "type": "ipv4-acl-type",
        "aces": {
          "ace": [
          ]
        }
      },
      {
        "name": "mud-63570-v4fr",
        "type": "ipv4-acl-type",
        "aces": {
          "ace": [
          ]
        }
      }
    ]
  }
}

If you load up the sample same-manufacturer mud file it will show connectivity to the PCs when there shouldn't be any.