Operational Security Current Practices in Internet Service Provider Environments
draft-ietf-opsec-current-practices-07
Yes
No Objection
Recuse
Note: This ballot was opened for revision 07 and is now closed.
Lars Eggert No Objection
Section 2.4.1.4., paragraph 0: > 2.4.1.4. Message Insertion/Deletion/Modification This section and the text on TCP-MD5 in 2.4.2 below don't consider the reset attacks against BGP sessions that TCP-MD5 mitigates. Since this document apparently is a survey based on interviews with operators, I'm not sure if anything can or should be added here. More editing nits emailed to authors, chairs and shepherds.
(David Kessens; former steering group member) Yes
Please check the rfc editor note, it corrects some editorial errors
(Bill Fenner; former steering group member) No Objection
(Cullen Jennings; former steering group member) No Objection
I asked two non trivial operators if they changed their SNMP strings every 30-90 days and "lol" was the only answer I got. It did make we wonder. Then I read comment about BCP or Informational and it really did make me wonder 1) is the purpose of this document to write down what people do or what they think they should do? Anyways, not my area of expertise so I will put no-obj.
(Dan Romascanu; former steering group member) (was Discuss) No Objection
(Jari Arkko; former steering group member) No Objection
(Magnus Westerlund; former steering group member) No Objection
(Mark Townsley; former steering group member) No Objection
Overall, a well written document with very good information. I enjoyed reading a good bit of it. It did suffer a bit of schizophrenia as to whether it was a document stating what happens to be done in networks today vs. a document stating should be done in networks today. I think it was mostly the former, but there are times when it tips over to the latter. > Message Insertion: This can be a valid message (which could be a > reply attack, which is a scenario where a message is captured and > resent at later time). A message can also be inserted with any of > the fields in the message being OspoofedO, such as IP addresses, port > numbers, header fields or even packet content. Flooding is also part > of this threat instantiation. This describes what a Message Insertion can be, but doesn't come out and define what it is (perhaps because it seems obvious to the authors, but it may not be obvious to some readers). > If SNMP is used for management, it is for read queries only and > restricted to specific hosts. If possible, the view is also > restricted to only send the information that the management station > needs rather than expose the entire configuration file with the read- > only SNMP community. The community strings are carefully chosen to > be difficult to crack and there are procedures in place to change > these community strings between 30-90 days. If systems support two > SNMP community strings, the old string is replaced by first > configuring a second newer community string and then migrating over > from the currently used string to the newer one. Most large ISPs > have multiple SNMP systems accessing their routers so it takes more > then one maintenance period to get all the strings fixed in all the > right systems. SNMP RW is not used and is disabled by configuration. Is this true for SNMPv3 as well? In general, a version reference for the SNMP referred to in this document should be given. There is a reference to SNMP version in a later section (2.2.4 Additional Considerations) but perhaps the reference would be more useful here. > The software images perform CRC-checks and the system binaries use > the MD5 algorithm to validate integrity. Many ISPs expressed > interest in having software image integrity validation based on the > MD5 algorithm for enhanced security. Perhaps at least an idle mention that MD5 is now vulnerable? There are some terms in this document that could use references, For example (and there are perhaps others) "nmap," "nessus," "Rancid," etc.
(Russ Housley; former steering group member) No Objection
I believe that the security considerations should point out that the TCP MD5 Signature Option is fragile. In particular, the points makde in Section 3 of RFC 4278 seem very relevant. Further, the security considerations ought to point out that the IETF is working on a replacement for the TCP MD5 Signature Option. If the author has any insight into transition from the TCP MD5 Signature Option to the new one (once it is ready), they would be helpful. s/noone/no one/
(Ross Callon; former steering group member) (was Yes) Recuse
My only question is whether this should be "informational" or "best current practice". I would be happy either way. I think that this is quite a good document.