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 secure". 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 dozen] Survey of room: about 1/3 vendors, 1/3 operators or service providers 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 contributors] 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 planes 2. requirements that are BCPs versus requirements that push the envelope 3. lack of published specifications for a few areas, including IETF XMLCONF and SYSLOG WGs. 4. overlap, repetition, harmonization with related work, esp. ANSI T1M1. 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 analysis. 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 planes. 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 though. 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 document 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: demurred 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 desirable? 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. Discussion? 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 requirements... 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 though. 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 opsec@ops.ietf.org [[meeting ended, about |