2.4.11 Operational Security Capabilities for IP Network Infrastructure (opsec)

NOTE: This charter is a snapshot of the 63rd IETF Meeting in Paris, France. It may now be out-of-date.

Last Modified: 2005-06-02


Ross Callon <rcallon@juniper.net>
Patrick Cain <pcain@coopercain.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:

Done  Complete Charter
Done  First draft of Framework Document as Internet Draft
Done  First draft of Standards Survey Document as Internet Draft
Done  First draft of Packet Filtering Capabilities
Oct 04  First draft of Event Logging Capabilities
Done  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


  • draft-ietf-opsec-framework-00.txt
  • draft-ietf-opsec-efforts-01.txt
  • draft-ietf-opsec-current-practices-01.txt

    No Request For Comments

    Current Meeting Report

    Operational Security Capabilities for IP Network Infrastructure (opsec)
    August 3rd, 2005 (at Paris IETF)

    Chairs: Pat Cain
    Ross Callon

    • Administrivia / agenda bashing
    • working group and document status (Pat)
    • Current Documents
      • Framework (Ross)
      • Survey of Service Provider Current Practices (Merike Kaeo)
      • Filtering Capabilities for IP Net Infrastructure (Chris Morrow)
    • Proposed New Document
      • A proposed new document on Best Practices (Chris Morrow)

    Administrivia / Agenda Bashing

    Ross and Pat agreed to take minutes (with help from Matthew Zekauskas). (no jabber scribe)

    Current document / working group status (Pat)
    • there are four classes of documents (take from slides)
    • four documents are currently out
      • framework
      • survey of other security efforts
      • current provider practices
      • filtering capabilities
    • The charter calls for quite a few documents. Some may be combined.
    • Some volunteers have gotten their work done. Some have not. Some volunteers have disappeared. We are still looking for people willing to work on documents. If you have volunteered in the past, expect us to bug you. ;-)

    Framework status (Ross Callon)

    - This is a roadmap of the working group effort.
    - update coming
    - not much different. This is primarily just a re-issue to keep the draft from timing out.

    Current Practices document (Merike Kaeo)

    - Documents the security practices currently used in SP networks.
    - document is almost done
    - deleted filtering section, since felt that this would be redundant with the existing filtering capabilities draft.
    - added text for DOS mitigation but this still needs work. Added appendix to detail some common packet mangling attacks.

    Merike intends to submit a -02 version within the next month which will include DoS mitigation section with more detail. She will also solicit input from the mailing list.


    Ross; What about large enterprises? This might for example include things like firewalls and perhaps intrusion detection and/or prevention. Merike: Interested. Chris Morrow: this is a large can of worms. Merike: If it is this large a can of worms, it might be worth putting this into a different document (allowing us to finish this document). This would imply a change in the title of this document to limit it to service providers. Merike volunteered to work on the large enterprise network security practices document.

    Packet Filtering Capabilities (Chris Morrow)

    Chris Morrow briefly discussed the packet filtering capabilities draft.

    This document is cut'n'paste of multiple inputs (including RFC3871)

    Draft -01 is out. The change is mainly structure regarding data plane versus mgt/control plane.

    Filter traffic through the device, but also filter snmp, bgp, telnet to the device
    -Need to filter non-transit traffic
    -Trying to protect the lower speed customer traffic
    -Map functions back to the current practices document
    - in some cases rate limiting is useful (eg, to reduce size of problems)
    - work at line rate

    The capabilities in this document should map back to the current practices document (which implies that it might be useful to have a filtering section in the current practices document).

    Added some layer2 functionality
    -MAC address, ATM, SONET, etc

    (I think that Chris said that he would be adding more text on this based on input)

    Darrel Lewis: Does the mgt plane include control plane?

    A: Yes, it's really a combination, includes BGP, control, login, etc.

    Ross: To me the term "control plane" normally includes both routing and management (which I believe is the intent here, and thus the term "control plane" fits).

    Darrel: Maybe we should use the X.805 definitions for consistency

    Next steps
    - Need to map doc sections to practice document.
    - Validate current structure and subsections are valid

    Barbara Fraser: Is there any new functionality in the document (ie, capabilities which are not currently widely deployed)?

    A (Chris). Not really. Some deployed devices do all the functions, but there are some devices that don't do all of them.

    Merike: Don't forget that the profiles documents will take all the capabilities and map them to specific environments.

    Infrastructure Protection BCP (Darrel Lewis, Chris Morrow, Paul Quinn)

    Chris presented an idea to produce a document which will document some recommended "best practices". This could provide an introduction for newer, smaller providers or customers. Will be a detailed guide of the capabilities.

    Susan Hares: Is the capability document mainly a procurement document

    Merike: This maps well to the other documents

    Darrel: This should be good just like BCP38

    Ross: There may be some confusion between this proposed new document and the existing document on current practices.

    Paul Quinn: This would propose a bare minimum of practices as the survey is really a list of things that providers do.

    Discussion on whether this as a BCP will map to the other documents.

    Pat: Let's wait for some text before we figure out what type of document this is. Ross: It will be easier to know whether this document is best kept on its own (and separate from the current practices and profile documents) after we see the text. Thus it makes sense to see a draft of this document.

    Pat: It may be useful to send a message to the list with a synopsis of the proposed document.

    Randy Preshin: Make sure we're compliant with rfc2026

    Chris: Structure of doc:edge remarking, edge access control, core hiding,
    route filtering. Not covered: Logging evaluation, net mgt, customer security, service protection

    End of working group


    OPSEC WG Agenda
    Packet Filtering Capabilities
    Infrastructure Protection BCP