Operational Security Current Practices in Internet Service Provider Environments
draft-ietf-opsec-current-practices-07
Revision differences
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
2021-01-04
|
07 | Amy Vezza | Downref to RFC 4778 approved by Last Call for draft-ietf-dhc-dhcpv6-pd-relay-requirements-05 |
|
2020-01-21
|
07 | (System) | Received changes through RFC Editor sync (added Verified Errata tag) |
|
2015-10-14
|
07 | (System) | Notify list changed from opsec-chairs@ietf.org to (None) |
|
2012-08-22
|
07 | (System) | post-migration administrative database adjustment to the No Objection position for Dan Romascanu |
|
2007-02-01
|
07 | Amy Vezza | State Changes to RFC Published from RFC Ed Queue by Amy Vezza |
|
2007-02-01
|
07 | Amy Vezza | [Note]: 'RFC 4778' added by Amy Vezza |
|
2007-01-31
|
07 | (System) | RFC published |
|
2006-11-08
|
07 | (System) | Request for Early review by SECDIR is assigned to Steven Bellovin |
|
2006-11-08
|
07 | (System) | Request for Early review by SECDIR is assigned to Steven Bellovin |
|
2006-10-30
|
07 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
|
2006-10-24
|
07 | Amy Vezza | IESG state changed to Approved-announcement sent |
|
2006-10-24
|
07 | Amy Vezza | IESG has approved the document |
|
2006-10-24
|
07 | Amy Vezza | Closed "Approve" ballot |
|
2006-10-23
|
07 | David Kessens | State Changes to Approved-announcement to be sent from IESG Evaluation::Revised ID Needed by David Kessens |
|
2006-10-21
|
07 | Dan Romascanu | [Ballot Position Update] Position for Dan Romascanu has been changed to No Objection from Discuss by Dan Romascanu |
|
2006-10-04
|
07 | Ross Callon | [Ballot Position Update] Position for Ross Callon has been changed to Recuse from Yes by Ross Callon |
|
2006-09-29
|
07 | (System) | Removed from agenda for telechat - 2006-09-28 |
|
2006-09-28
|
07 | Amy Vezza | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza |
|
2006-09-28
|
07 | Bill Fenner | [Ballot Position Update] New position, No Objection, has been recorded by Bill Fenner |
|
2006-09-28
|
07 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded by Jari Arkko |
|
2006-09-28
|
07 | Mark Townsley | [Ballot comment] Overall, a well written document with very good information. I enjoyed reading a good bit of it. It did suffer a bit of … [Ballot comment] 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. |
|
2006-09-28
|
07 | Mark Townsley | [Ballot Position Update] New position, No Objection, has been recorded by Mark Townsley |
|
2006-09-28
|
07 | Russ Housley | [Ballot comment] I believe that the security considerations should point out that the TCP MD5 Signature Option is fragile. In particular, the points … [Ballot comment] 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/ |
|
2006-09-28
|
07 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley |
|
2006-09-27
|
07 | Cullen Jennings | [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings |
|
2006-09-27
|
07 | Cullen Jennings | [Ballot comment] I asked two non trivial operators if they changed their SNMP strings every 30-90 days and "lol" was the only answer I got. … [Ballot comment] 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. |
|
2006-09-27
|
07 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund |
|
2006-09-27
|
07 | Dan Romascanu | [Ballot discuss] I believe that the document is targeting the Internet Service Provider environments. As the OPSEC WG decided to shut down without pursuing any … [Ballot discuss] I believe that the document is targeting the Internet Service Provider environments. As the OPSEC WG decided to shut down without pursuing any other work excepting the four Internet-Drafts currently in works, including the Enterprise Operational Security Capabilities Profile document, I believe that it is necessary to make crystal clear that the current completed work is limited in scope. I suggest to have the title of this document reflect this: OLD: Operational Security Current Practices NEW: Operational Security Current Practices in Internet Service Provider Environments |
|
2006-09-27
|
07 | Dan Romascanu | [Ballot Position Update] New position, Discuss, has been recorded by Dan Romascanu |
|
2006-09-27
|
07 | Yoshiko Fong | IANA Evaluation Comment: As described in the IANA Considerations section, we understand this document to have NO IANA Actions. |
|
2006-09-26
|
07 | David Kessens | [Ballot comment] Please check the rfc editor note, it corrects some editorial errors |
|
2006-09-26
|
07 | Lars Eggert | [Ballot comment] 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 … [Ballot comment] 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. |
|
2006-09-26
|
07 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert |
|
2006-09-23
|
07 | Ross Callon | [Ballot comment] My only question is whether this should be "informational" or "best current practice". I would be happy either way. I think that this … [Ballot comment] 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. |
|
2006-09-23
|
07 | Ross Callon | [Ballot Position Update] New position, Yes, has been recorded by Ross Callon |
|
2006-09-21
|
07 | David Kessens | [Ballot Position Update] New position, Yes, has been recorded for David Kessens |
|
2006-09-21
|
07 | David Kessens | Ballot has been issued by David Kessens |
|
2006-09-21
|
07 | David Kessens | Created "Approve" ballot |
|
2006-09-21
|
07 | (System) | Ballot writeup text was added |
|
2006-09-21
|
07 | (System) | Last call text was added |
|
2006-09-21
|
07 | (System) | Ballot approval text was added |
|
2006-09-21
|
07 | David Kessens | Placed on agenda for telechat - 2006-09-28 by David Kessens |
|
2006-09-21
|
07 | David Kessens | State Changes to IESG Evaluation from Publication Requested by David Kessens |
|
2006-09-21
|
07 | David Kessens | [Note]: 'Ross Callon is the proto shepherd' added by David Kessens |
|
2006-09-21
|
07 | David Kessens | 1. Have the chairs personally reviewed this version of the Internet Draft (ID), and in particular, do they believe this ID is ready to forward … 1. Have the chairs personally reviewed this version of the Internet Draft (ID), and in particular, do they believe this ID is ready to forward to the IESG for publication? Yes, I have reviewed this draft carefully several times and have provided comments (which Merike responded to well). I do feel that the document is ready to forward to the IESG for publication. 2. Has the document had adequate review from both key WG members and key non-WG members? Do you have any concerns about the depth or breadth of the reviews that have been performed? Yes, this document has had very extensive review. In addition to WG review, we have in addition gone to NANOG, APRICOT, and RIPE to solicit review. The last call was copied to the Nanog mailing list. Merike has gotten comments from multiple service providers and others. Many of the service providers that have contributed to this document or commented are not listed in the acknowledgements, since they wanted to stay anonymous for obvious reasons. 3. Do you have concerns that the document needs more review from a particular (broader) perspective (e.g., security, operational complexity, someone familiar with AAA, etc.)? No concerns. I think that the document has been very well reviewed. 4. Do you have any specific concerns/issues with this document that you believe the ADs and/or IESG should be aware of? For example, perhaps you are uncomfortable with certain parts of the document, or have concerns whether there really is a need for it. In any event, if your issues have been discussed in the WG and the WG has indicated it that it still wishes to advance the document, detail those concerns in the write-up. No concerns. 5. How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? Strong consensus. 6. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email to the Responsible Area Director. No hint of any appeal, nor any other discontent. 7. Have the chairs verified that the document adheres to all of the ID Checklist items ? I have run it against ID nits tools. The tools found only two nits, one of which appears to be wrong and one of which is very minor and could be ignored or fixed as an RFC editors note. The ID nits tool complained that the abbreviation "IRR" was used but not defined. In fact, when IRR is first used it is defined: Some large ISPs require that routes be registered in an Internet Routing Registry [IRR] which can then be part of the RADB - a public registry of routing information for networks in the Internet that can be used to generate filter lists. I think that the issue here is that it should use rounded parenthesis (like this) rather than square ones [like this] so that the tool, and humans, know that it isn't a reference. The ID nits tool also complained that RFC2119 is referenced, but not used. This is in fact correct. Both of these look like RFC editor notes issues. 8. Is the document split into normative and informative references? Are there normative references to IDs, where the IDs are not also ready for advancement or are otherwise in an unclear state? (note here that the RFC editor will not publish an RFC with normative references to IDs, it will delay publication until all such IDs are also ready for publication as RFCs.) Yes, references are split into normative and informational references. All normative references are already RFCs. 9. What is the intended status of the document? (e.g., Proposed Standard, Informational?) Informational. 10. For Standards Track and BCP documents, the IESG approval announcement includes a write-up section with the following sections: Not Applicable. |
|
2006-09-08
|
07 | Dinara Suleymanova | Draft Added by Dinara Suleymanova in state Publication Requested |
|
2006-08-30
|
07 | (System) | New version available: draft-ietf-opsec-current-practices-07.txt |
|
2006-07-21
|
06 | (System) | New version available: draft-ietf-opsec-current-practices-06.txt |
|
2006-07-11
|
05 | (System) | New version available: draft-ietf-opsec-current-practices-05.txt |
|
2006-06-27
|
04 | (System) | New version available: draft-ietf-opsec-current-practices-04.txt |
|
2006-05-25
|
03 | (System) | New version available: draft-ietf-opsec-current-practices-03.txt |
|
2005-10-26
|
02 | (System) | New version available: draft-ietf-opsec-current-practices-02.txt |
|
2005-07-20
|
01 | (System) | New version available: draft-ietf-opsec-current-practices-01.txt |
|
2005-02-15
|
00 | (System) | New version available: draft-ietf-opsec-current-practices-00.txt |