2.4.13 Operational Security Capabilities for IP Network Infrastructure (opsec)

NOTE: This charter is a snapshot of the 61st IETF Meeting in Washington, DC USA. It may now be out-of-date.

Last Modified: 2004-10-14


Ross Callon <rcallon@juniper.net>
Patrick Cain <pcain@acmehacking.com>

Operations and Management Area Director(s):

Bert Wijnen <bwijnen@lucent.com>
David Kessens <david.kessens@nokia.com>

Operations and Management Area Advisor:

David Kessens <david.kessens@nokia.com>

Technical Advisor(s):

George Jones <gmj@pobox.com>

Mailing Lists:

General Discussion: opsec@ops.ietf.org
To Subscribe: opsec-request@ops.ietf.org
In Body: In Body: subscribe
Archive: http://ops.ietf.org/lists/opsec/

Description of Working Group:


The goal of the Operational Security Working Group is to codify
knowledge gained through operational experience about feature sets
that are needed to securely deploy and operate managed network
elements providing transit services at the data link and IP

It is anticipated that the codification of this knowledge will be
an aid to vendors in producing more securable network elements,
and an aid to operators in increasing security by deploying and
configuring more secure network elements.


The working group will list capabilities appropriate for
devices use in:

* Internet Service Provider (ISP) Networks
* Enterprise Networks

The following areas are excluded from the charter at this time:

* Wireless devices
* Small-Office-Home-Office (SOHO) devices
* Security devices (firewalls, Intrusion Detection Systems,
Authentication Servers)
* Hosts


Framework Document

A framework document will be produced describing the scope,
format, intended use and documents to be produced.

Current Practices Document

A single document will be produced that attempts to capture
current practices related to secure operation. This will be
primarily based on operational experience. Each entry will

* threats addressed,

* current practices for addressing the threat,

* protocols, tools and technologies extant at the time of writing
that are used to address the threat.

Individual Capability Documents

A series of documents will be produced covering various groupings
of security management capabilities needed to operate network elements
in a secure fashion. The capabilities will be described in terms that
allow implementations to change over time and will attempt to avoid
requiring any particular implementation.

The capabilities documents will cite the Current Practices document
where possible for justification.

Profile Documents

Profiles documents will be produced, which cite the capabilities
relevant to different operating environments.

Operator Outreach

Much of the operational security knowledge that needs to be
codified resides with operators. In order to access their
knowledge and reach the working group goal, informal BoFs will be
held at relevant operator fora.

RFC3871 will be used as a jumping off point.

Goals and Milestones:

Sep 04  Complete Charter
Sep 04  First draft of Framework Document as Internet Draft
Sep 04  First draft of Standards Survey Document as Internet Draft
Oct 04  First draft of Packet Filtering Capabilities
Oct 04  First draft of Event Logging Capabilities
Nov 04  First draft of Network Operator Current Security Practices
Jan 05  First draft of In-Band management capabilities
Jan 05  First draft of Out-of-Band management capabilities
Jan 05  First draft of Configuration and Management Interface Capabilities
Feb 05  First draft of Authentication, Authorization, and Accounting (AAA) Capabilities
Feb 05  First draft of Documentation and Assurance capabilities
Feb 05  First draft of Miscellaneous capabilities
Mar 05  First draft of Deliberations Summary document
Mar 05  Submit Framework to IESG
Mar 05  Submit Standards Survey to IESG
May 05  Submit Network Operator Current Security Practices to IESG
May 05  First draft of ISP Operational Security Capabilities Profile
May 05  First draft of Enterprise Operational Security Capabilities Profile
Jun 05  Submit Packet Filtering capabilities to IESG
Jun 05  Submit Event Logging Capabilities document to IESG
Jul 05  Submit In-Band management capabilities to IESG
Jul 05  Submit Out-of-Band management capabilities to IESG
Aug 05  Submit Configuration and Management Interface Capabilities to IESG
Aug 05  Submit Authentication, Authorization and Accounting (AAA) capabilities document to IESG
Sep 05  Submit Documentation and Assurance capabilities to IESG
Sep 05  Submit Miscellaneous capabilities document to IESG
Dec 05  Submit ISP Operational Security Capabilities Profile to IESG
Dec 05  Submit Large Enterprise Operational Security Capabilities Profile to IESG
Dec 05  Submit OPSEC Deliberation Summary document to IESG

No Current Internet-Drafts

No Request For Comments

Current Meeting Report

OPSEC Working Group minutes

Minutes from

OPSEC Working Group meeting
November 9, 2004
Washington, DC

Minutes by Shashi Kiran and Ross Callon.


  • Agenda Bashing and Administrivia
  • Working Group Charter
  • Framework Document
  • Standards Survey
  • Survey of service provider Security Practices
  • Adjourn

1. Charter / Scope of Working Group (Pat Cain)

The charter that was approved by the IESG had earlier been discussed for a while on the mailing list and at previous OPsec BOFs. It has ruled out (at least for the initial charter) wireless devices, SOHO, security devices, and end user stuff. We will come up with list of capabilities that big network operators will be interested in for their networks (including ISPs and enterprises).

A comment that was received related to the first OPsec document (RFC3781): It is too big. However, if we continued to flesh out more details, it would be even bigger. Therefore the plan is to make multiple little documents. If some of the documents turn out to be too small without enough content we can merge them, but goal is NOT to come up with a single 400 page RFC.

Proposed working group outputs include: Framework; Current Practices document; a series of focussed capability documents, and a small number of profile documents. The first two of these (framework and current practices) will help to drive the series of capability documents.

It is possible that there could be lots of documents, because the initial list of capabilities is a long list. There is a lot of work to do. If anyone notices anything that we have missed please let us know. Since there are a lot of proposed documents, this implies that we need a lot of authors. Please volunteer for any topics that you are particularly interested in and have subject matter expertise in. Volunteer by talking to one of us (Pat, Ross, George).

2. Framework Document (George Jones)


There have been only small changes to the framework since the BOF that was held at the last IETF. The framework document defines the set of documents which will be produced. It also talks about scope of the effort, and the threats to be covered.

Changes to the framework: A bit more work by Merike on the attacks / threat model (this is a relatively short discussion plus a reference to her "in progress" longer document); We also changed the word "requirements" to "capabilities". "Requirements" may vary from operator to operator.

Merike Kaeo: We are not interested in reinventing the wheel wrt the threat model. The idea is to develop a framework to "plug in" operator's requirements, and to provide a guide to the threats operators perceive. This is a bottom up approach.

George: We still need to double-check that the list of documents to be produced in the framework document corresponds to the charter (unless we decide to drop the list from the framework). We need to clarify the intended status of the documents. If we find that some documents can be combined, we may reduce the number of documents listed.

Pat: The hope is to get the framework document completed relatively quickly.

George: Unless there is feedback to the contrary, we are close to being done.

3. Survey of Security-Related Efforts (Chris Lonvick)


Many Standards Developing Organizations (SDOs) are developing standards and/or best practices for security. We would like each of the SDOs to be aware of the other efforts which are in progress.

Contents include:

  • Glossary;
  • Listing of SDOs that appear to be working on security standards (note that "security" may mean slightly different things to different groups);
  • A list of documents which have been produced (by the various SDOs)

There is a bit of work still needed: in particular addition of ITU-T SG4 Q18 work. This is an expansion of other ITU work. We also would like review by interested parties (please send comments to authors and/or OPSEC mailing list).

The chairs asked: Should this be a working group document?

Barbara Fraser: This will be a useful document as we are doing our work. Problem is that the content is volatile (ie, will be obsoleted quickly).

Dave Kessens: We need to make sure that this document is within the scope of the charter.

Ross: This is a useful document. It will however get out of date. Whenever it is finally published, the introduction needs to be clear that this is a snapshot.

Richard Graveman: This should be a working group document. As an example it would be useful to have this referenced on the working group web site. People doing the capabilities documents should look at this document. It would be useful to have a table which showed other documents versus capabilities and showed which other documents discuss which capabilities.

Chris Lonvick agreed that it will get out of date.

Straw poll requested by chairs/AD.

Ross: There are really two questions: (1) Whether the document should eventually become an RFC or eventually time out after our effort is complete; (2) Whether the document should become a working group document, or remain as an individual contribution.

Show of hands:

            Should the document eventually be published as an RFC: 18

            Should the document eventually time out and go away: 12

This is not a clear consensus, and we can discuss this issue further on the list.

            Should the document be accepted as a working group document: 28

            Should the document stay as an individual document: 0

This is clear consensus that the document should be a working group document.

4. Outline of Survey of Current ISP practices (Merike Kaeo)

Merike collected "brain dumps" (rough notes on what security practices are deployed) from service providers at NANOG. Unfortunately this was after the -00 cutoff date for internet drafts and therefore she didn't get a draft submitted. She did however get input from several service provider / network operator sources. She is intending to get more input this week at the IETF.

Howard Berkowicz: You have a number of things in there which seem to be perfectly valid threat characteristics. Under them you have mitigation techniques. Is this intentional?

Merike: Yes. She has been asking SPs "what do you do about <problem>, and is writing down the answers (both threats and counter-measures).

George Jones: This might get to be a big document.

Merike: In principle yes. But at the current time it doesn't look like it will be unacceptably large.

Ross Callon: Will you keep the sources of various inputs private?

Merike: Yes. This is why I have done most of my discussions with providers privately one-on-one.

Dave Nelson: As a follow-up: Some might have counter-measures which they feel are clever, and don't want them published due to the possibility of counter-counter-measures being developed by miscreants.

Merike: Yes, and this is not very useful since for the purposes of this document it doesn't help to know things that I can't right down.

Ross: Are there cases where they could at least say "We use this capabilities, but can't say how because we want to keep our practices quiet".

Merike: Not really. Also, a major purpose of this document is to educate operators, and they need to know how to use the capabilities.

George Jones: Vendors sometimes complain that they have implemented features that no one uses, this document can also be useful for them.

5. No new issues/topics were received from the floor.

Meeting was ajourned.


Security Best Practices Efforts and Documents