2.4.10 Operational Security Capabilities for IP Network Infrastructure (opsec)

NOTE: This charter is a snapshot of the 64th IETF Meeting in Vancouver, British Columbia Canada. It may now be out-of-date.

Last Modified: 2005-09-27


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 2004  First draft of Event Logging Capabilities
Done  First draft of Network Operator Current Security Practices
Jan 2005  First draft of In-Band management capabilities
Jan 2005  First draft of Out-of-Band management capabilities
Jan 2005  First draft of Configuration and Management Interface Capabilities
Feb 2005  First draft of Authentication, Authorization, and Accounting (AAA) Capabilities
Feb 2005  First draft of Documentation and Assurance capabilities
Feb 2005  First draft of Miscellaneous capabilities
Mar 2005  First draft of Deliberations Summary document
Mar 2005  Submit Framework to IESG
Mar 2005  Submit Standards Survey to IESG
May 2005  Submit Network Operator Current Security Practices to IESG
May 2005  First draft of ISP Operational Security Capabilities Profile
May 2005  First draft of Enterprise Operational Security Capabilities Profile
Jun 2005  Submit Packet Filtering capabilities to IESG
Jun 2005  Submit Event Logging Capabilities document to IESG
Jul 2005  Submit In-Band management capabilities to IESG
Jul 2005  Submit Out-of-Band management capabilities to IESG
Aug 2005  Submit Configuration and Management Interface Capabilities to IESG
Aug 2005  Submit Authentication, Authorization and Accounting (AAA) capabilities document to IESG
Sep 2005  Submit Documentation and Assurance capabilities to IESG
Sep 2005  Submit Miscellaneous capabilities document to IESG
Dec 2005  Submit ISP Operational Security Capabilities Profile to IESG
Dec 2005  Submit Large Enterprise Operational Security Capabilities Profile to IESG
Dec 2005  Submit OPSEC Deliberation Summary document to IESG


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

    No Request For Comments

    Current Meeting Report

    OPSEC Working Group
    November 8, 2005 18:50-19:50
    Thanks to Bill Fenner for taking minutes. 
    Pat Cain was unable to be in Vancouver, and thus Ross Callon 
    chaired the meeting solo. 
    (Ross Callon)
    1852-1900: document status (R.Callon)
    1900-1910: draft-ietf-opsec-filter-caps-00 (Morrow/Callon)
    1910-1920: draft-bonica-opsec-nmasc-00 (R.Bonica)
    1920-1930: draft-callon-misc-cap-00.txt (R.Callon)
    1930-1940: draft-ietf-bmwg-bench-meth-ebgp-00 and
               draft-ietf-bmwg-bench-meth-opsec-00 (S.Poretsky)
    1940-1950: draft-zhao-opsec-routing-capabilities-00 (M.Fuyou)
    Document Status 
    (Ross Callon)
      - was updated to avoid timeout
      - a minor update will be submitted soon after the IETF
    Survey of Security Efforts 
      - is stable, in good shape
      - no update since last IETF
    Packet Filtering Capabilities 
      - Has been updated
      - presentation to follow
    Current Practices 
      - Has been updated 
          - Modified threat model section
          - Added filtering section
          - Added some IPv6 information
      - Question for working group
          - Should Appendix B (protocol specific attacks) have 
            more details on individual attacks listed?
          - Is more detail on IPv6 required?
          - Is anything missing
    New Documents
      - Three new documents have been brought to the working group
      - Presentations on each are to follow
    Packet Filtering Capabilities 
    (Chris Morrow's slides were presented by Ross since Chris was 
    unable to attend) 
    The Packet Filtering Capabilities document was an individual 
    document for two versions (-00 & -01), is now a working group 
    document -00.
    We still need to link the capabilities in this document with 
    Merike's document on current service provider practices.
    Question (from Chris Morrow, in the slides): Do we want more 
    relating to packet filtering with MPLS? Ron: We don't want to 
    filter on labels, since they change so dynamically would be 
    hard to configure the filter might want to not accept filters 
    that you haven't advertised. Ross: In principle you might 
    want to look past the MPLS header; but if you assume that 
    there is an IP header and it's not IP after MPLS then you 
    might filter incorrectly.
    Network Management Access Security Capabilities
    (Ron Bonica)
    This document covers in-band management capabilities, 
    out-of-band management capabilities, and virtual-out-of-band 
    management capabilities. 
    In-band: Securing management against paths shared with users. 
    Out of Band: NM functions never shares paths with users, so 
    can protect via interfaces. More secure. More expensive. 
    Virtual oob: l3vpn with router interfaces and NMSes inside 
    the VPN
    Ron compared and contrasted the approaches (see slides)
       - Virtual oob has some aspects of In-band and some of oob.  
         Isolates but also shares fate.
    This document is intended as a starting point. We hope to 
    move it forward as WG document.
    Ross: Group: how many people have read it?
      - only a handful
    (Ross, speaking as an individual): I read it, good start, not 
    done, I have some comments to send. 
    Ross (speaking as a chair): Looks like there aren't enough 
    people here who read it
    Darryl Lewis: concept very reasonable for this doc (haven't 
    read it)
      - Have you considered other standards documents that talk 
        about this, ITU 3016? doing access control for mgt plane? 
        Some parallel efforts.
      - Another level of oob beyond building another network, 
        such as console access
    Ross: Other than that there aren't enough people here who 
    have read the document to say what the *wg* thinks, are there 
    any objections to making it a WG document?  No.
    Peter Thermos(?): I read it 3 weeks ago; good start; should 
    be synergy with some of the existing standards stuff 
    including ITU; should be distinction from management plane 
    as telcom defines it and maangement for day-to-day tasks.
    Miscellaneous Capabilities
    (Ross Callon)
    Mostly this document contains material from RFC3871 that 
    don't belong in other documents which are explicitly called 
    out in the WG charter.
    Issue: MUST, versus SHOULD, versus MAY. As an example, the 
    NRIC best practices include preparing for ocean storm surges 
    - this not particularly relevant in Alberta, Canada. A 
    particular practice may not necessarily be applicable in 
    every case.  In the same sense, these capabilities might have 
    their own importance depending on the environment. Thus I put 
    text in to say that MUST/SHOULD/MAY are to be interpreted 
    within the context of the capability. 
    Darryl Lewis: I really like this paragraph; in reading the 
    control plane document I found that the benefit of a given 
    capability is under debate; don't want to say you SHOULD use 
    encryption ignoring its downsides, so something like this is 
    The document discusses Route Filtering (as distinct from 
    Packet Filtering, which is covered in another document). 
    This was largely taken from 3871. 
    The document also contains some discussion of prioritizing 
    control plane tasks (this is extended from the brief text in 
    3871). There might be some conflicting views on performance 
    and prioritization - a/ you can suffer from not doing this, 
    but b/ we don't know for sure what the state of the art is, 
    which aspect of control plane operation do we prioritize 
    above another one, etc. Therefore I put most of this in as 
    SHOULDs rather than MUSTs. 
    There is also a section saying "Security Features must not 
    cause operational problems". This is taken directly from 
    3871. Should we leave this in or take it out?  Seems self-
    evident, although also correct.
    We also need to tie this stuff in with Merike's current 
    practices document. 
    Propose WG doc. Are there additional comments? (no)  How 
    many people have read it?  Not enough to decide to take 
    it as WG document. As before, other than that there aren't 
    enough people here who have read the document to say what 
    the working group thinks, are there any objections to 
    making it a WG document?  No.  
    Accelerated Stress Benchmarking
    (Scott Poretsky)
    Although these documents are in the BenchMarking Working 
    Group (bmwg), you'll see how these are directly related 
    with what's going on in opsec.
    These documents describe methodologies to ensure that 
    devices are meeting conditions in opsec docs. 
      - deployed environment:
         Instead of testing one feature at once, test under 
         real conditions
      - failure conditions:
         Do bad things to the router, see how it works.
      - routing:
         Do bad things to routing
      - manageability under stress:
         Stress it, does management still work?
      - sw bugs:
         memory leaks, etc - this kind of testing finds bugs.
      - ability to survive DoS attacks:
         this testing *is* a DoS attack
    The terminology and general methodology documents are close 
    to WG last call in bmwg, so it's time to look at them from 
    here. (and please send comments)
    See slide 5, Stress Test Methodology
    Ross: Q: (refering to slide 5): Is there normal operation 
    phase between 1 & 2, and then after 3?  A: kind of, except 
    startup conditions are typically more than normal operation 
    would provide.
    See slide 6, Example Stress Test benchmarks
    Ted Seely: I assume this is only for informational purposes 
    - is it wise to say that a box is RFCxxxx-compliant where 
    the requirements are constantly changing?
    A: We don't say RFCxxxx-compliant
    Ted: But it'll be an RFC!  The environment will always be 
    Ross: The document creates guidelines, not a set of tests
    Scott: We shouldn't discuss here whether bmwg should be 
    doing RFCs.
    Ted: We're saying what the benchmarks are, then people will 
    claim that they conform to them, and that's a slippery slope.
    Ross: That's a topic for bmwg
    David: I think you guys agree more than you think.  bmwg is 
    somewhat of a slippery slope.  It has a carefully worded 
    charter; read it and you'll see the limits to prevent 
    getting too close to the slippery slope.
    Peter Thermos: good baseline for survivability - but 1. when 
    we compare 2 devices, why do we need to compare them?  
    2. looking at amplification and flooding attacks, there's 
    another class of attacks like single-packet attacks - one 
    malformed SIP packet and the service or device blows up - 
    should we add capabilities for this?  Perhaps there's a 
    mechanism to identify that addresses this type of thing in 
    the future.
    Scott: Malformed packets are an important topic.  
    Methodology is an open question for this but it should 
    be considered.
    Ron Bonica: You have a set of interesting parameters; they 
    indicate how vulnerable a system is - are you asking us for 
    more parameters, or saying that more is coming?
    Scott: asking you for more! great!
    (name not recorded): The methodologies are interesting; Too 
    often we're thinking about steady state and it's nice to see 
    worst case being thought about.
    Control Plane Security Capabilies
    (Miao Fuyou)
      - see slides
    Ron Bonica: 1. on Authentication - at NANOG, I learned 
    that many operators don't authenticate BGP because of CPU 
    utilization.  Someplace under authentication, mention CPU 
    meltdown attack.  2. on filtering capabilities - some of 
    these items are for routes, but TTL / Hop Limit looks like 
    for packets / forwarding plane issue.
    (name not recorded): responding to Ron: might make use of 
    the TTL hack e.g. GTSM
    (missed one comment)
    (name not recorded): There are lots of items in this 
    document that say "you SHOULD do this", where an operator 
    might have its own priorities - maybe these should be 
    capabilities and the imperatives should be relative to 
    Ross: Wearing my document author hat: This document covers 
    a wide area - perhaps include some things that are missing 
    from the miscellaneous capabilities draft - some of this 
    may apply to the packet filtering document - so should we 
    use this document to see if we missed anything from the 
    wg-chartered documents?  First we should figure out where 
    all the text goes, and then acknowlege you or make you a 
    contributor or co-author in each document (depending upon 
    how much text we end up using). 
    Miao: That makes sense.
    End of Working Group Meeting 


    Agenda and Document Status
    Filter Capabilities
    NetMan Access Security Capabilities
    Miscellaneous Capabilities
    Accelerated Stress Testing Methodologies
    Control Plane Capabilities