On Jul 14, 2016, at 2:30 PM, Douglas Gash (dcmgash) <dcmg...@cisco.com> wrote: > > Hello > For information: > > Version 3 loaded last week has many revisions from the last round of > comments. > Version 4 loaded this week has some minor mods/clarifications on US-ASCII > vs UTF-8. > > Would appreciate any further reviews.
Many of my review comments have been addressed, which is good. There still remains a number of issues. The Security Considerations section is in the middle of the document, where it's typically at the end. That's a minor nit. The larger one is that the Security Considerations section is pretty minimal. It should describe operational issues with the protocol, and comments as to what the security implications are for network management traffic to be sent in the clear. The issue with the field names remains. I *suspect* the "user len" field contains the length of the "user" field... but there is nothing in the document which says so. The text still seems philosophical to me, instead of prescriptive. For example in Section 3.6: After a packet body is decrypted, the lengths of the component values in the packet should be summed and checked against the cleartext datalength value from the header. Any packets which fail this check should be discarded and an error signalled. The values "should" be summed? Is that an RFC 2119 statement? Or just a suggestion? What happens if an implementation chooses to ignore this suggestion? And bad packets "should" be discarded? Why not MUST? How does an error get signalled? What kind of error packet gets sent back? Perhaps something like this would be better: After a packet body is decrypted, the lengths of the component values in the packet are summed. If the sum is not identical to the cleartext datalength value from the header, the packet MUST be discarded, and an error signalled. The underlying TCP connection SHOULD also be closed. Which (for me) clarifies the operation, makes the checks normative, and adds a suggestion to close the TCP connection. After all, if they key is wrong and packets can't be decrypted, there's no reason to keep the TCP connection open. You can't decrypt any data in the connection, so it will all be garbage. Alan DeKok. _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
