https://author-tools.ietf.org/iddiff?url1=draft-ietf-opsawg-mud-iot-dns-considerations-11&url2=draft-ietf-opsawg-mud-iot-dns-considerations-12&difftype=--html
Hi!
Mahesh Jethanandani <mjethanand...@gmail.com> wrote:
> This document needs a grammar review, preferably by somebody whose task
> is to edit documents. Also, the abstract refers to use of both IP
> address and DNS, but the Introduction talks DNS, but makes no reference
> to use of IP address till Section 3. Shouldn’t the Introduction section
> expand on the Abstract?
Paragraph two of the introduction speaks about why DNS names are better than
IP addresses. I don't know if I can mention them any earlier.
> It is not clear from the Abstract or from the Introduction, the problem
> that is being solved. Is it devices trying to access a resource in the
> Internet, or external parties trying to (maliciously) access or modify
> the MUD file? Reading RFC 8520 and this document, it appears to be the
> former, but it would help to clarify.
{{RFC8520}} provides a standardized way to describe how a specific purpose
device makes use of Internet resources.
In fact, MUD files can describe incoming connections as well as outgoing
ones, so the answer is "yes"...
The problem is about how IoT devices use names, and how deployment of MUD
puts this problem into clear focus.
I would be happy to expand the Abstract in some way, and it's always good to
have someone else write the abstract after the document is done, rather than
before... :-)
>> At the MUD policy enforcement point -- the firewall -- there is a
>> problem. The firewall has only access to the layer-3 headers of the
>> packet. This includes the source and destination IP address, and if
>> not encrypted by IPsec, the destination UDP or TCP port number present
>> in the transport header. The DNS name is not present!
> There are several assertions in this paragraph that could do with some
> clarity, and the clarity requested above might help. Again, is this in
> the context of traffic originating inside the device private network,
> or traffic originating from outside the device network? My
> understanding of firewalls is that the default policy for a device
> inside a private network is to allow access any resources in the
> network, and drop any traffic originating from the outside world.
That's certainly the policy of home routers, and RFC7084/RFC6092 (_Simple
Security Capabilities in Customer Premises Equipment_) the default minimal
policy. But enterprise firewalls have lots of complex policies, often
blocking all outgoing connections other than port 80/443, or requiring that
internal users/desktops be authenticated before they can use the Internet.
The purpose of RFC8520 is to enable enterprise customers (and pro-sumer
residential ones, and maybe ... retail ones too) to be able to firewall their
IoT devices.
> If
> this is for traffic originating from inside the device network, a
> temporary hole is punched in the firewall to allow the return traffic
> to pass through. Therefore, is the ACL for traffic originating outside
> the device network, or is for traffic originating inside the device
> network?
RFC8520 says:
[RFC7452] discusses design patterns for, and poses questions about,
smart objects. Let us then posit a group of objects that are
specifically not intended to be used for general purpose computing
tasks. These devices, which this memo refers to as Things, have a
specific purpose. By definition, therefore, all other uses are not
intended. If a small number of communication patterns follows from
those small number of uses, the combination of these two statements
can be restated as a Manufacturer Usage Description (MUD) that can be
applied at various points within a network. MUD primarily addresses
threats to the device rather than the device as a threat. In some
circumstances, however, MUD may offer some protection in the latter
case, depending on how the MUD URL is communicated and how devices
and their communications are authenticated.
> Minor:
> Section 3. If we are comparing, should there be a Section titled
> “Strategies to map IP addresses”?
If the MUD file contains IP addresses, there is nothing to do.
The hard part if mapping the names.
>> The second section of this document details how common manufacturer
>> anti-patterns get in the way of this mapping.
> Definition of “anti-patterns” needs to come on first use, not later in
> the document.
Well, it's a common term in software for ever 20 years.
I'll move the reference to be earlier.
>> • it can not be done fast enough,
> What is the definition of fast? How often do these lookups happen to
> make it a significant delay? And how does it compare to getting the
> data that one is fetching from the Internet?
They have to happen at "line rate", or they would slow traffic down.
So whatever line rate is for your connection.
>> • it reveals usage patterns of the devices,
> How is this an issue, as any effort to do a lookup or get data is going
> to show usage? And how is it known what the kind of device is doing the
> lookup.
When your magicwand is in use, and it wants to check if it should update it's
firmware, it might reach out to updates.magicwandoriginal.com, and that would
involve DNS traffic to ns1.mediatemple.net (according to whois).
> Nits:
> - In general lot of small paragraphs, with one of two sentences per
> paragraph. Can they be consolidated?
I'm not fond of paragraphs that fill the entire page.
> - Use of acronyms Do53, DoQ, DoT or DoH. These are not common
> acronyms. The definitions for some of them, e.g., Do53 come much later
> in the document. Please define in a Terminology Section or somewhere
> before first use.
I-D.ietf-dnsop-rfc8499bis details Do53, DoT, DoH, and it's referenced just
before Do53 is used.
>> IoT Devices SHOULD prefer doing DNS to with the DHCP provided DNS
>> servers.
> Grammar?
Fixed to: IoT Devices SHOULD prefer doing DNS with the DHCP provided DNS
servers.
(but, it could be "to" instead of "with", and I'll go with whatever RFC
editor thinks)
>> The ADD WG has written [I-D.ietf-add-dnr] and [I-D.ietf-add-ddr] to
>> provided.
> Same here.
Already fixed in -11 I think.
https://author-tools.ietf.org/iddiff?url1=draft-ietf-opsawg-mud-iot-dns-considerations-11&url2=draft-ietf-opsawg-mud-iot-dns-considerations-12&difftype=--html
--
Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
