[Nut-upsdev] Addition to draft-rprice-ups-management-protocol-05 - IP addressing lockdown and encryption
tedm at mittelstaedt.us
Tue Dec 28 19:17:49 GMT 2021
Section 6.4 needs some work. I think you need to renumber it as follows:
6.4.1 to 184.108.40.206
220.127.116.11 to 18.104.22.168.1
22.214.171.124 to 126.96.36.199.2
6.4.2 to 188.8.131.52
6.4.3 to 184.108.40.206
6.4.4 to 220.127.116.11
6.4.5 to 6.4.2
The reason this needs to be done is you are saying in 6.4 that UPS
management "needs to move to a more secure practice in which all traffic
In an RFC standards document this wishy hand-waving wording isn't
allowed, what you are hinting at here is a "MUST" directive but not
coming out and using the MUST keyword. That is, what this section is
proposing is that the final RFC requires encryption - so that programs
that do NOT implement encryption are NOT fully compliant.
Setting aside for the moment the discussion of whether you agree the RFC
should require this (I do not BTW) the existing sections are of 2
flavors - the first flavor is "ways to implement encryption" and the
second flavor is basically a laundry list of ways to protect traffic in
a non-encrypted manner.
Section 6.4 is conflating the encryption and non-encryption flavors
together under a paragraph that says management data MUST be encrypted.
This makes no logical sense
Renumbering is a way of separating the encryption/non encryption flavors.
I also propose adding 18.104.22.168 saying the following:
A fifth option would be to incorporate a configuration directive in the
ups daemon program that would allow the admin to set a list of IP
addresses that are permitted to send commands to the UPS daemon.
Addresses would allow for read-only or read-send configuration
directives. This could also be accomplished with less granularity via
the use of firewall entries on the hosts.
Now as for the 6.4 section, I disagree with making encryption a
requirement. Just like SMTP traffic encryption should ALWAYS be an
option. The draft RFC swings back and forth on this, and this kind of
requirement absolutely needs discussion in any case.
I don't believe you are going to get an RFC that mandates encryption for
interhost communication no matter how much you want it, people have been
holding their breath turning blue in the face and jumping up and down
trying to force SMTP to have mandated encryption for years and have not
gotten their way on it. So don't even open the door to that. You can
satisfy the large corps who want encryption by standardizing encryption
in the RFC and making it optional and the small orgs and individuals who
don't need encryption and don't want the bother of it by making it optional.
Rewrite paragraph 6.4 to say:
UPS management needs to make available optional mechanisms for securing
host to host communication such as encrypting traffic, blah blah blah.
and rewrite the entire section on security to make it clear that
encryption of the commands was a SHOULD not a MUST in the RFC. Separate
all the encryption approaches into their own group, and all the
non-encryption approaches into their group for clarity.
And DON'T cave into the "encryption everywhere" cult-hood. I don't know
if any of them are listening but if so this post is going to be like
throwing red meat down in front of them so I'll step back and let the
On 12/28/2021 9:27 AM, Roger Price wrote:
> The IETF have confirmed that they now have version 05 of the NUT RFC
> in their repository. This includes changes made following comments by
> Bart Smit and David Zomaya. The full list of changes can be found in
> Appendix D.
> ---------- Forwarded message ----------
> A new version of I-D, draft-rprice-ups-management-protocol-05
> has been successfully submitted by Roger Price and posted to the
> IETF repository.
> Name: draft-rprice-ups-management-protocol
> Revision: 05
> Title: Uninterruptible Power Supply (UPS) Management Protocol
> -- Commands and Responses
> Document date: 2021-12-28
> Group: Individual Submission
> Pages: 61
> This document describes the command/response protocol currently used
> in the management of Uninterruptible Power Supply (UPS) units and
> other power devices often deployed in small offices, and in IT
> installations subject to an erratic public power supply. The UPS
> units typically interface to an Attachment Daemon in the system they
> protect. This daemon is in turn polled by a Management Daemon which
> notifies users and system administrators of power supply incidents,
> and automates system shutdown decisions. The commands and responses
> described by this document are exchanged between the UPS Attachment
> Daemon and the Management Daemon. Current practice when this text
> was written risks weak security and this is addressed in the Security
> Considerations sections of this document.
> The IETF Secretariat
> Nut-upsdev mailing list
> Nut-upsdev at alioth-lists.debian.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Nut-upsdev