Section 6.4 needs some work. I think you need to renumber it as follows:
6.4.1 to 6.4.1.1
6.4.1.1 to 6.4.1.1.1
6.4.1.2 to 6.4.1.1.2
6.4.2 to 6.4.1.2
6.4.3 to 6.4.1.3
6.4.4 to 6.4.1.4
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
is encrypted"
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 6.4.1.5 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
frenzy start.
Ted
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.
Roger
---------- 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
Html:
https://www.ietf.org/archive/id/draft-rprice-ups-management-protocol-05.html
Abstract:
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
[email protected]
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
_______________________________________________
Nut-upsdev mailing list
[email protected]
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
