Ballot for draft-ietf-opsec-current-practices-07

Operational Security Current Practices in Internet Service Provider Environments
RFC 4778

Note: This ballot was opened for revision 07 and is now closed.

Summary: Needs a YES.

[Cullen Jennings]

Comment (2006-09-27)

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.

[David Kessens]

Comment (2006-09-26)

Please check the rfc editor note, it corrects some editorial errors

[Lars Eggert]

Comment (2006-09-26)

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.

[Mark Townsley]

Comment (2006-09-28)

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.

[Ross Callon]

Comment (2006-09-23)

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.

[Russ Housley]