MUD suggests that devices should always have access to DHCP and DNS.
However, I don't know how to communicate this information to the MUD
controller so that appropriate ACLs can be installed when a device comes
up. A logical place to put this would be in the request sent out by the
DHCP server to t
> On Oct 3, 2017, at 12:40 , M. Ranganathan wrote:
>
> MUD suggests that devices should always have access to DHCP and DNS. However,
> I don't know how to communicate this information to the MUD controller so
> that appropriate ACLs can be installed when a device comes up. A logical
> place t
Hi Ranga,
On 10/3/17 6:40 PM, M. Ranganathan wrote:
> MUD suggests that devices should always have access to DHCP and DNS.
> However, I don't know how to communicate this information to the MUD
> controller so that appropriate ACLs can be installed when a device
> comes up. A logical place to put
Eliot,
The MUD draft says:
Local DNS and NTP are, by default, permitted to and from the Thing.
Looking at the example in Appendix B I see :
"controller": "urn:ietf:params:mud:dns"
Which implies this string has to map to the ip address where DNS is hosted.
I am wondering where/how t
Hello,
Architecturally, there are four functional blocks:
MUD file server : Serves MUD files. This is an optional component. MUD
files could be directly bundled with the device itself if is-supported flag
is False
MUD Controller: Transmits the mud file and auxiliary information (such as
the loca
Hi Ranga,
I apologize- I thought I had answered this note. I'm going to top post
because the theme of your note is pretty consistent: it essentially
asks, what happens if we want to decompose the MUD controller into two?
I don't see anything particularly wrong with the idea, but that's not
where
