Subject: [OPSAWG] Preventing MUD slides

From: Doug Montgomery <[email-masked]>
Date: Mon, 13 Nov 2017 22:56:21 -0500

https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-mud-13#section-14

The deployment considerations section notes:

"Because MUD consists of a number of architectural building blocks, it
is possible to assemble different deployment scenarios.  One key
aspect is where to place policy enforcement.  In order to protect the
Thing from other Things within a local deployment, policy can be
enforced on the nearest switch or access point.  In order to limit
unwanted traffic within a network, it may also be advisable to
enforce policy as close to the Internet as possible.  In some
circumstances, policy enforcement may not be available at the closest
hop."

Some side conversation came up yesterday in opsec as to how one can
ensure that a MUD ACL is *only* applied to the traffic of the device
that emitted the MUD URL?

In particular in cases where the ACL can't be placed/bound to a
specific device MAC/port on the first hop switch/AP, how do we ensure
that the default "deny any" behavior of flows out of profile does not
affect other systems.

For example the first MUD ACL capable switching / routing device is on
the upstream side of a NAT.

Likewise, is it required that MUD profiles fully specify source/dest
addresses in ACLs so that loosely specified ACLs don't collateral
damage to flows from other systems?

Is it possible for a piece of malware to emit a MUD URL that purposely
gets an ACL applied to systems other than the one that emitted the
URL?

I am not saying I know this is a problem, it is just a question that
came up in side discussions, that I don't know the answer to.

At a minimum, saying something in the deployment consideration section
about how we protect against accidental / malicious misapplication of
MUD-profiles would be useful.

-- 
DougM at NIST

---

From: Eliot Lear <[email-masked]>
Date: Tue, 14 Nov 2017 14:33:11 +0800

Hi Doug,

> gets an ACL applied to systems other than the one that emitted the

I would say, “it depends”.  If you have either a port- or session-based
mechanism at L2 and below, then it is possible to keep one device from
speaking for another.  Similarly, if a device is purported to have
CHANGED its MUD URL, then I would be suspicious, especially if that
device is appearing to be something completely different from what it was.

Eliot

---

From: Doug Montgomery <[email-masked]>
Date: Tue, 14 Nov 2017 02:20:16 -0500

Hi Eliot,

I think there is a subtle/difficult semantic here that each MUD ACL is
designed to be strictly bound to a particular end device.  If the
content of the specific ACL is capable of unambiguously establishing
that binding no matter where it is deployed topologically, then you
are OK.

If you can't establish that unambiguous binding, or if you can make
the binding ambiguous on purpose, there might be an issue.

So, I don't think the issue is one device spoofing another at L2 etc.

Let's say I have a CPE that supports MUD controlled ACLs but I have a
switch behind that, that does not support MUD ACLs.  There are two
things attached to that second switch. Thing2 has some malware on it
that is willing to emit a MUD URL to a purposely malicious MUD profile
that effectively tries to block all outbound traffic (src =
192.168.*.*, dst = any, action = drop).

Is there something in the design that stops malicious thing2 from doing this?

The idea that the network operator will inspect all of these by
non-automated means doesn't seem to scale well with the assumption
that the number and variety of devices will be very large.

If the network operator is the home user, I don't think this will
scale for other reasons.

dougm

-- 
DougM at Work

---

From: Eliot Lear <[email-masked]>
Date: Tue, 14 Nov 2017 15:46:33 +0800

Hi Doug,

> that binding no matter where it is deployed topologically, then you

This is the role of the MUD controller.  The MUD ACL refers, if you
will, to This-> or Me.  The MUD file doesn't get to specify who This->
or Me is.  The controller's job is to fill that in with the device's
information, and to scope the policy to that device.

I think this might be worth making more clear.
> Is there something in the design that stops malicious thing2 from doing this?
Does the above address your point?

Eliot

---

From: Doug Montgomery <[email-masked]>
Date: Tue, 14 Nov 2017 04:52:04 -0500

Eliot,

No actually, it seems to reduce the problem to an unspecified
function.  I get the late/local binding of various components of the
MUD ACL.

We are prototyping a controller, so we need to figure these gory
details.  If we assume every switch is MUD ACL capable, we can bind
MUD ACLs to specific ports/MACs.   If they are not, and if the first
MUD capable switch is upstream of a NAT, it becomes unclear how to
stop erroneous or malicious MUD profiles from potentially having
unintended effects.

Maybe we should link up and talk about it.

dougm

-- 
DougM at Work

---

From: Eliot Lear <[email-masked]>
Date: Tue, 14 Nov 2017 22:56:38 +0800

Hi Doug,

> function.  I get the late/local binding of various components of the
I think you get how to fill in those functions in a great number of
cases, especially for consumer.  So for instance...

> MUD ACLs to specific ports/MACs.

Yes.  Or if you can do session management for wireless you are in
reasonably good shape as well.

>    If they are not, and if the first

I never seriously considered trying to implement MUD across a NAT.[*]

The principle here is that you really must have a means to identify the
packet flow with a particular end point.  This is simplest when all
packets flowing through a given point are for that end point.  It is
harder when you are dealing with a single shared medium.  And it is
imperfect – to say the least – if one is attempting to prevent east-west
infection, although you can still provide some protection north/south. 
To deploy north of a NAT one could consider flowing all traffic in the
home over a softwire, but that has its own attendant headaches with
efficiencies, latency, and jitter if you are also intending to address
east/west.

Another way of looking at it is this:

MUD does not create new in-path mechanism.  However, if you can specify
a static policy somehow on an enforcement point, then it should be
"MUDable" in some form.  MUD just provides a vehicle to specify the
configuration of, say, iptables or IOS/JunOS config or the like.

Eliot

> Maybe we should link up and talk about it.

Would be delighted.

Eliot

[*] Set the WayBack Machine to the 1990s and you would find an earlier
version of Eliot writing RFC 1627 and screaming "NAT is Evil", and so
this is a throwback to that ;-)