2.4.15 Operational Security Requirements (opsec) Bof

Current Meeting Report

OPSEC BOF - Operation Security Requirements for
IP Network Elements Session

17 July 2003, IETF #57, Vienna

BOF Lead: George Jones, MITRE

Base document:
Individual Submission "draft-jones-opsec-00.txt" dated 9 June 2003

Area Directors:
Randy Bush, Operations & Management Area
Steve Bellovin, Security Area

[[Note takers: Chris Lonvick and Neal Ziring]]

[[meeting started about 13:05]]

GJ: welcome, introduced session --emphasis for this work is to write down 
solid req. for "what knobs we need on network devices in order to make them 

GJ: walked through agenda, no changes from audience

GJ: asked:
        - who has downloaded draft?  [most? over 2 dozen]
        - who has read the draft? [fewer, but still quite a few, more than a 
        Survey of room: about 1/3 vendors, 1/3 operators or service 

GJ: listed some resources that were background to this draft: security 
testing work at UUNet and ANSI T1M1 committe were biggest.  Common 
Criteria may also be useful.

GJ: end game is to get device makers/vendors to sell devices that have the 
knobs we need to secure our networks (install, deploy, operate, 
maintain) More goals: aid operator-vendor communication, guide testing of 
products in labs

    Mechanism to use: publish document.  Note that correct IETF 
track/area needs to be chosen carefully

GJ: Review of Goals:
    discuss draft's contents/structure, discuss IETF way forward 
[invited audience to bring forward other related work, or to become 

GJ: review of history and current status of the draft; originally grew out of 
UUNet security lab product testing, some coverage at IETF #55 and #56.  
While at UUNet, GJ and colleagues got tired of hearing "but you're the only 
ones who want feature XYZ" from vendors.  This effort will go toward 
concensus on what features are needed.

GJ: Large-net-scale requirements scale down better than small-net 
requirements scale up -- therefore current draft concentrates on 
requirements of large networks (ISPs, big provides, telcos)

GJ: Scope is still under discussion, but can't let it get too broad or 
we'll never finish.

GJ: Recent changes to the draft (prior to -00) included breaking 
monolithic set of requirements into a set of 'device profiles'.  (idea by 
Merike Kaeo)

GJ: There are major tensions in the requirements
    set (evident from discussion on mailing list).
        1. cryptographic v. physical separation of control and data 
        2. requirements that are BCPs versus requirements that push the 
        3. lack of published specifications for a few areas, including IETF 
        4. overlap, repetition, harmonization with related work, esp. ANSI 
        5. Draft is getting big -- how to reduce? For requirements that are 
"way out there", might be preferable drop them and refer them to IRTF for 

GJ: [long discussion of scoping of document, no particular 
resolution, generally scope toward large-scale deployments]

GJ: Reviewed related work:
        1. IETF work: psamp, Netconf/XMLCONF, Syslog ForCES, CCAMP?
        2. Non-IETF: ANSI T1M1 T1.276.

GJ: introduced Neal Ziring from US DOD, for brief overview of 
International Common Criteria

NZ: (Neal Ziring, US DOD) CC is a standard, ISO 15408, that describes how to 
write security requirements for IT devices, programs, systems, & 
products.  Allows for official certification of equipment that meets 
criteria; administered by nat'l programs of signatory countries.  US 
program is called NIAP.

NZ: Two kinds of requirements in CC: functional requirements (what the 
device has to do) and assurance requirements (how you know that is meets the 
functional requirements) Most of GJ's I-D is functional 
requirements, with a few assurance ones.

NZ: Two kinds of CC documents: Profile and Target. (properly, 
"Protection Profile" or "Security Target") Profile describes desired 
security functionality and assurance (such as a firewall, etc.)  A Target 
describes an actual product or system (such as Product XYZ from Company A).  
The goal is to have the product evaluated by an accredited lab and that 
evaluation [actually, evaluation passed result and Target] published. This 
I-D (draft-jones-opsec-00) is like a profile. 

GJ: introduced Chris Lonvick from Cisco, a member of ANSI T1M1 
committee and IETF Syslog WG chair

CL: (Chris Lonvick, Cisco) T1M1 committee deals with management plane in 
telecomm systems; much concerned with the security of the management 
plane. (T = telecomm, M = management)

CL: discussed background of T1 committee and M1 subcommittee, and their 
goal for the T1.276 standard: "ensure common minimal baseline for 
security features in the management plane for network elements".

CL: reviewed nature of ANSI standards and relation to ITU, with 
comparison to unofficial status of IETF

CL: reviewed ANSI T1 business case for improving security in the 
management plane.  One important motivation was convergence of data and 
management planes in telecomm architectures.

CL: reviewed T1 standard network management reference  model (see 
diagram in CL's slides)

CL: T1.276 should be a US National Standard by later July. Also 
submitted to ITU-T Study Group 4, and to NRIC IV Working Group 1B.

CL: discussed mgmt and composition of T1M1 committee, and general 
concensus and voting on T1.276.  Good consensus from vendors and 
operators in favor of T1.276.
CL: Gave URL where to get a copy of T1.276 draft (see slides)

CL: reviewed basis of T1.276 requirements:
        1. two kinds: Mandatory and Optional
        2. not IP-centric, but broader

CL: T1M1 subcommittee would like to see this OPSEC work go forward and 
harmonized with T1.276.

GJ: Gave comparison table of this draft to related work: T1.276 and NSA 
Router and Switch CC Profile. (see GJ's slides)

NZ: (interrupting) slide says that NSA R&S CC profile was certified, but it 
wasn't.  It was fully completed in 2001, but never put in for 
validation.  [Work on it may be started up again in late 2003]

GJ: began review of meat of the current draft -00
        1. current scope is IP devices, this won't change
        2. current set of req. oriented toward net infrastructure 
(routers, switches, gateways), can use profile mechanism to sub-set the 
reqs for other devices (e.g. cell phone)
        3. structure of requirements in document will be: functional reqs, 
assurance reqs, documentation reqs.
        4. Some reqs in -00 that are too 'future' will probably be 
dropped (e.g. stealthing)

GJ: Motivational example: one requirement in current draft is ability to 
filter traffic TO the device itself.  This ability was critical for 
workaround in recent Cisco IOS vulnerability in Cert Advisory.  It is good 
that Cisco supports such a feature: we want this document to list such 
features so that all relevant devices will support them.

GJ: began discussion of specific management reqs in draft -00, and 
possible changes for -01, especially separation of control and data 

WH: (Wes Hardaker, Mike?) suggested discussion break instead of running 
through all the requirements

WH: current draft lists minimal and conditional security 
requirements, ok.  Need to make sure draft sticks to security reqs and 
doesn't branch off into other arenas.

PS: (Pakka Solva) Separation of mgmt and data planes in the draft is 
confusing; in practice there is always some crossover.  Nice goal 

PS: Regarding requirement to filter all traffic THRU the device: how to 
implement?  Most devices filter into and/or out of interfaces.  
confusion ensued - eventual result: effective interface filtering can 
satisfy this; GJ to fix wording for -01 draft

BF: (Barbara Frasier, Cisco) If this doc goes through IETF, what about 
conflicts with existing RFCs?  Are there any?
GJ: admits yes.  BF: resolution?  GJ: not sure, there are warnings in the 
RB: (Randy Bush) Update that section of the [other] document, or 
obsolete that portion of the document
SB: (Steve Bellovin) This may be good to update old-time RFCs
PX: (Piotr) When this updates the old RFCs, that should be carefully noted in 
the document
PS: would prefer that revisions to other RFCs appear in some other 
document.  GJ: we'll make a list and take to ADs for guidance

WH: What about scope,  Core devices or edge devices?
GJ: answer - needs to be decided [see also below remarks by MK]
WH: worried about intro of current draft; does it describe scope 
accurately?  GJ: needs polishing

GJ: introduced Merike Kaeo to discuss the requirement groupings, 
profiles, in the draft -00 appendix.

MK: (Merike Kaeo) battle between "good enough" and "best" security.  goal of 
profiles is to defines sets of requirements from body of draft that apply to 
various device roles.  Would be surprised if a minimal set of profiles took 
more than 1 year to standardize.  Later, would like to see much bigger set of 
profiles for many other devices not just layer 3 core, such as edge 
devices. send suggestions to mailing list

WH: suggested separating profiles into separate draft or RFC.  GJ: 

WH: regarding edge devices, noted that 90% of network attacks are 
insider attacks

GJ: back to requirements listing from draft...
    [several issues emphasized:
                1. some requirements could usefully reference work that is 
still in draft (not yet RFC) form.  Should we wait?
                2. reqs current specify need for managability by 
standard protocols, prohibit need for proprietary mgmt GUIs.
                3. is a 'display all' feature really needed or even 
                4. need to know what all the services are, and be able to 
disable any|all.

GJ: req 2.3.8 obliges devices to resist all known exploits.  

BS: (Bill Somerfeld, Sun) Vendors will have trouble with 2.3.8.  No 
vendor could comply with 2.3.8, it is too hard as written.  
GJ: admits that 2.3.8 needs work.  
BS: it is also a moving target!

BS: For 2.3.1, need to strengthen some SHOULDs/MAYs into MUSTs, some reqs 
too big as written
GJ: agree we need to split some reqs; also need more emphasis on 
testable reqs.

BS: what about risk analysis, has it been done?  Doc needs a solid basis in 
this, otherwise it could end up unbalanced [GJ and BS discussed whether to do 
risk analysis in current BOF session, decided not to do so, but GJ agreed 
one needed to be done.]

EA: (Emir A. from Cable&Wireless) believes most risks for core and edge 
routers well-understood, but still should be written down. [later, 
volunteered to send grad school research on this topic to group]

GJ: reviewed IP stack and filtering requirements...

PS: regarding requirement for logging filter hits: what happens when link to 
log server fails? discussion ensued...
NZ: in many CC Profiles, inability to log tied to device shutdown -- no 
desirable to core router
PS: suggest queuing logs for later transmission?

GJ: more review of logging requirements...then review of AAA 

UK: (Ulrich Kiermayer) What about requirements on the log recipient host?  
GJ: out of scope

PS: regarding requirement to list all log messages in 
documentation: does ANY vendor do this?  Could be nice, though.  GJ: No 
vendor seems to do this

GL: (Greg Lebowitz) need better definition of "log messages" in the draft  
GJ: okay, will do
PS: definition of 'events' that generate messages might be nice 
(possibly re: 2.11.1 ?)
GL: defining message may be a goal of this work

[several questions and some discussion about req 2.11.6 "Ability to 
configure security of log messages", draft definitely needs clarified 
title and body for that one]

PS: regarding requirement to 'classify' events and log different ones 
differently (2.11.9), does any vendor allow this now?  Might be nice 
GJ: No, don't think any do this yet [Some other audience member 
remarked that a Firewall vendor consortium is considering this: turns out to 
be a hard problem.]
GJ: expressed relation to IETF Syslog WG work
CL: Nope, no such relation; Syslog WG considers what happens to 
messages before logging to be out of scope

GJ: Req 2.14.1, Vendor Responsiveness, possibly spin this off to some 
other effort?

GJ: Work areas for this document:
        1. needs work on assumptions and risk analysis
        2. need to decide about IETF path: BCP RFC, Informational RFC, or 
something else?
        3. need work on the profiles

PS: Regarding conflicts, current draft as written can't be a BCP, if this 
document becomes a BCP RFC it   will not be able to update old RFCs.  (cf. 
Barb Frasier's question earlier)

GJ: Plan for next few months:
        1. take feedback from this discussion, issue draft -01.
        2. get more feedback from groups like NANOG and RIPE.
        3. move forward in IETF

GJ: invites participation on the mailing list 

[[meeting ended, about 


Operational Security Requirements
T1M1: Management Plane Security Standard (T1.276)