Operational Security Current Practices in Internet Service Provider Environments
RFC 4778

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

(David Kessens) Yes

Comment (2006-09-26)
No email
send info
Please check the rfc editor note, it corrects some editorial errors

(Jari Arkko) No Objection

(Lars Eggert) No Objection

Comment (2006-09-26)
No email
send info
Section, paragraph 0:
>  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.

(Bill Fenner) No Objection

(Russ Housley) No Objection

Comment (2006-09-28)
No email
send info
  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/

(Cullen Jennings) No Objection

Comment (2006-09-27)
No email
send info
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) (was Discuss) No Objection

(Mark Townsley) No Objection

Comment (2006-09-28)
No email
send info
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.

Magnus Westerlund No Objection

(Ross Callon) (was Yes) Recuse

Comment (2006-09-23)
No email
send info
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.