Skip to main content

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