1. Operational Security Requirements (opsec) BOF or “Give Us The Knobs We Need” July 17, 2003 George M. Jones opsec@ops.ietf.org (mailing list)

2. Agenda ● Welcome and discussion of agenda (5 min.) ● Goals (5 min.) ● History and Current Status (10 min.) ● Related Work/”Liaison” [Lonvick,Ziring] (20 min) ● Overview of draft (30 min.) ● Profiles [Kaeo] (10 min) ● Discuss Contents of the draft (30 min.) ● Next Steps, Work Areas, Milestones (10 min.) ● Adjourn

3. Goals ● Goals: The End Game – Devices that can be deployed in a secure fashion, or “Give us the knobs we need” – A tool to aid communicating security needs – A guide to testing ● Methods: – Published document – Citeable in RFPs

4. Goals ● Goals: Today – Feedback on resolving tensions – Feedback on the substance of the document – Advice on most useful path to proceed – Identify liaisons with other areas – Identifying people interested in contributing

5. History and Current Status (1) ● Originally a UUNET testing document ● Used as the basis for security qualifications, mostly backbone and edge devices. ● Tired of vendors bringing in boxes that could not be operationally secured ● Tired of hearing “but you're the only one who wants...” ● Decided to get feedback and publish

6. History and Current Status (2) ● It was thought that many of the requirements where general or generalizable. ● Much musing about scope. Heritage and operating assumptions still show. ● Several restructurings (profiles, etc.) and reformatting (xml2rfc) ● Several rounds of internal review, some external comment. ● Some informal review @ IETFs 55+56

7. History and Current Status (3) ● Assembling a team of “section editors” ● -00 draft published, trial balloon ● Collecting comments, will go to -01 and possibly -02, then decide where to go (input please)

8. History and Current Status (4) ● Major Tensions – Scope (core, edge vs. SOHO, Wireless, special purpose/embedded vs. general purpose) – Operational environment(s)/profiles (OoB vs. Inband) – BCP vs. “near term futures” (ex. Syslog, netconf) – BCP vs. “way out there” (stealthing, sampling) – Overlap with other work – Structure (BCP vs. other, functional/assurance/doc, profiles) – Size (65 pages and counting)

9. Resolving Tensions (1) ● Resolving the tensions (pre-BOF thoughts) – Scope: Re-narrow focus to large network infrastructure (routers, switches, other managed infrastructure devices). Allow “profiles” for other devices that are proper subsets of reqs. (e.g. SOHO, firewalls, VPN), but add no specific reqs for them. Out of scope: general purpose hosts (incl name/time/log-servers, IDS, etc.), unmanaged devices, mobile devices, etc.

10. Resolving Tensions (2) ● Resolving the tensions (pre-BOF thoughts) – Split OoB and In-band management reqs, allow choice – “Mostly BCP”....drop “Advanced” (==stealthing).... but what to do about things that are not standards, but “close” that solve problems (syslog, netconf, etc.) ? – Overlap w/other work: discuss in BOF. – Structure: proposed restructuring described later. – Size: No solution in sight.

11. Related Work (1) ● Related Efforts – IETF – Netconf – syslog – Forces ● Related Efforts – Non-IETF – Common Criteria – ANSI/T1M1 (management, etc.) – ANSI/T1S1 (control plane) ● Other ?

12. Related Work (2) – “Liaison” Reports “Liaison” reports from related efforts are included here to provide perspective, point to possible sources of ideas, point to possible areas of collaboration. ● Common Criteria ● ANSI/T1M1

13. Comparison of Requirements Docs

14. Overview: Goal ● Goal [current]: “The goal of this document is to define a list of security requirements for devices that implement Internet Protocol (IP). The intent of the list is to provide consumers of IP devices a clear, concise way of communicating their security requirements to equipment vendors.” ● Goal [proposed]: “The goal of this document is to define a list of operational security requirements for network infrastructure devices that implement Internet Protocol (IP). The intent...”

15. Overview: Scope (1) ● Scope [current]: “These requirements apply to devices that make up the network core infrastructure (such as routers and switches) as well other devices that implement IP (e.g., cable modems, personal firewalls,hosts)”

16. Overview: Scope (2) ● Scope [proposed]: “These requirements apply to devices, such as routers and switches, that make up the IP enabled infrastructure of large networks. It may be possible to define profiles (subsets) of the requirements that apply to broader classes of devices, e.g. security devices, firewalls, mobile devices, or even general purpose hosts, but the list of requirements from which the profiles are drawn will not be extended to cover other unique needs they may have.

17. Overview: Current Structure ● Current Structure – BCP Reqs – Non-Standard Reqs – Advanced Reqs – Profiles

18. Overview: Current Major Sections draft-jones-opsec-00.txt ● Device Management ● User Interface ● IP Stack ● Rate Limiting ● Filtering ● Logging ● AAA ● Layer 2 Reqs ● Vendor Behaviour ● Profiles

19. Overview: Proposed Structure ● Minimum Requirements – Functional ● Device Management... – Documentation – Assurance ● Conditional Requirements – Functional – Documentation – Assurance ● Profiles

20. Overview: Management Reqs (1) Requirement #s (1.2.3) listed from -00 draft. Possible disposition in -01 indicated by “==> action/placement” (discussion, please) ● BCP 2.1.1 Support Out-of-Band Management (OoB) Interfaces 2.1.2 Enforce Separation of Data and Control Channels 2.1.3 Separation Not Achieved by Filtering 2.1.4 No Forwarding Between Management and Data Planes 2.1.1-2.1.4 ==> Conditional, Functional 2.1.5 Device Remains Manageable at All Times ==> drop (too generic) 2.1.6 Support Remote Configuration Backup ==> Minimum, Functional 2.1.7 Support Management Over Slow Links ==> Minimum, Functional

21. Overview: Management Reqs (2) ● Non-Standard 3.1.1 Support Secure Management Channels 3.1.2 Use Non-Proprietary Encryption 3.1.3 Use Strong Encryption 3.1.4 Key Management Must Be Scalable 3.1.1-3.1.4 ==> Minimum, Functional (borrow from T1M1 ?) 3.1.5 Support Scripting of Management Functions ==> Minimum, Functional (netconf ?)

22. Overview: User Interface Reqs (1) 2.2.1 Support Human-Readable Configuration File 2.2.2 Display of 'Sanitized' Configuration 2.2.1-2.2.2 ==> Minimum, Functional ● BCP

23. Overview: User Interface Reqs (2) 3.2.1 Display All Configuration Settings ==> ??? (valid reeasons not to expose all) ● Non-standard

24. Overview: IP Stack Reqs (1) ● BCP 2.3.1 Comply With Relevant IETF RFCs on All Protocols... ==> minimum, functional 2.3.2 Provide a List of All Protocols Implemented 2.3.3 Provide Documentation for All Protocols Implemented 2.3.2-2.3.2 ==> minimum, documentation 2.3.4 Ability to Identify All Listening Services 2.3.5 Ability to Disable Any and All Services 2.3.6 Ability to Control Service Bindings for Listening Services 2.3.7 Ability to Control Service Source Address 2.3.4-2.3.7 2.3.8 Ability to Withstand Well-Known Attacks and Exploits ==> Minimum, Assurance

25. Overview: IP Stack Reqs (2) ● BCP 2.3.9 Maintain Primary Function at All Times ==> drop. Too generic. 2.3.10 Support Automatic Anti-spoofing for Single-Homed Networks 2.3.11 Ability to Disable Processing of Packets Utilizing IP Options 2.3.10-2.3.11 ==> Conditional, Functional 2.3.12 Ability to Disable Directed Broadcasts ==> Minimum, Functional 2.3.13 Identify Origin of IP Stack 2.3.14 Identify Origin of Operating System 2.3.13-2.3.14 ==> Minimum, Assurance

26. Overview: IP Stack Reqs (3) ● Non-standard 3.3.1 Support Denial-Of-Service (DoS) Tracking 3.3.2 Traffic Monitoring 3.3.3 Traffic Sampling ==> ???

27. Overview: IP Stack Reqs (4) ● Advanced 4.1.1 Ability To Stealth Device ==> drop/possible spinoff

28. Overview: Rate Limiting Reqs ● BCP 2.4.1 Support Rate Limiting 2.4.2 Support Rate Limiting Based on State ==> conditional, functional

29. Overview: Filtering Reqs (1) ● BCP 2.6 Packet Filtering Criteria 2.6.1 Ability to Filter on Protocols 2.6.2 Ability to Filter on Addresses 2.6.3 Ability to Filter on Any Protocol Header Fields 2.6.4 Ability to Filter Inbound and Outbound 2.6.5 Ability to Filter on Layer 2 MAC Addresses 2.6.* ==> minimum, functional 2.7 Packet Filtering Application Targets 2.7.1 Ability to Filter Traffic Through the Device ==> conditional, functional 2.7.2 Ability to Filter Traffic to the Device ==> minimum, functional

30. Overview: Filtering Reqs (2) ● BCP 2.7.3 Ability to Filter Updates ==> conditional, functional 2.8 Packet Filtering Actions 2.8.1 Ability to Specify Filter Actions ==> minimum, functional

31. Overview: Filtering Reqs (3) ● BCP 2.9 Packet Filtering Counter Requirements 2.9.1 Ability to Accurately Count Filter Hits 2.9.2 Ability to Display Filter Counters 2.9.3 Ability to Display Filter Counters per Rule 2.9.4 Ability to Display Filter Counters per Filter Application 2.9.5 Ability to Reset Filter Counters 2.9.6 Filter Counters Must Be Accurate 2.9.* ==> minimum, functional

32. Overview: Filtering Reqs (4) ● BCP 2.10 Other Packet Filtering Requirements 2.10.1 Ability to Log Filter Actions 2.10.2 Ability to Specify Filter Log Granularity 2.10.3 Ability to Filter Without Performance Degradation ==> minimum, functional 2.10.4 Filter, Counters, and Filter Log Performance Must Be Usable ==> drop, too general

33. Overview: Logging Reqs (1) ● BCP 2.11.1 Ability to Log All Events That Affect System Integrity ==> minimum, functional... also area for spinoff.

34. Overview: Logging Reqs (2) ● BCP 2.11.2 Logging Facility Conforms to Open Standards 2.11.3 Catalog of Log Messages Available 2.11.4 Ability to Log to Remote Server 2.11.5 Ability to Select Reliable Delivery 2.11.6 Ability to Configure Security of Log Messages 2.11.7 Ability to Log Locally 2.11.8 Ability to Specify Log servers by Event Classification 2.11.9 Ability to Classify Events 2.11.10 Ability to Maintain Accurate System Time 2.11.11 Logs Must Be Timestamped 2.11.12 Logs Contain Untranslated Addresses 2.11.13 Logs Do Not Contain DNS Names by Default 2.11.2 - 2.11.13==> minimum, functional

35. Overview: AAA Reqs (1) ● BCP 2.12.1 Authenticate All User Access 2.12.2 Support Authentication of Individual Users 2.12.3 Support Simultaneous Connections 2.12.4 Ability to Disable All Local Accounts 2.12.5 Support Centralized User Authentication 2.12.6 Support Local User Authentication 2.12.7 Support Configuration of Order of Authentication Methods 2.12.8 Ability to Authenticate Without Reusable Plain-text Passwords 2.12.9 Support Device-to-Device Authentication 2.12.1 – 2.12.9 ==> minimum, functional

36. Overview: AAA Reqs (2) ● BCP 2.12.10 Ability to Define Privilege Levels 2.12.11 Ability to Assign Privilege Levels to Users 2.12.12 Default Privilege Level Must Be Read Only 2.12.13 Change in Privilege Levels Requires Re- Authentication 2.12.14 Accounting Records 2.12.10 – 2.12.14 ==> minimum, functional

37. Overview: Layer 2 Reqs ● BCP 2.13.1 Filtering MPLS LSRs 2.13.2 VLAN Isolation 2.13.3 Layer 2 Denial-of-Service 2.13.4 Layer 3 Dependencies 2.13.1 – 2.13.4 ==> conditional, functional

38. Overview: Vendor Behaviour Reqs ● BCP 2.14.1 Vendor Responsiveness ==> assurance, possible spinoff of metrics group/work.

39. Overview: Profiles A.1 Minimum Requirements Profile A.2 Layer 3 Network Core Profile A.3 Layer 3 Network Edge Profile A.4 Layer 2 Network Core Profile A.5 Layer 2 Edge Profile

40. Overview: Recap of Major Sections ● Device Management ● User Interface ● IP Stack ● Rate Limiting ● Filtering ● Logging ● AAA ● Layer 2 Reqs ● Vendor Behaviour ● Profiles

41. Work Areas ● Resolve tensions (for discussion now) – Scope – Structure – Operational assumptions – BCP vs. non-BCP – Relationship to other efforts (IETF and non-IETF) ● Simplify compound requirements ● Refine profiles

42. Next Steps and Milestones ● Incorporate feedback from BOF, list ● Restructure, adjust scope, goals if needed ● Publish -01 (August, 2003) ● Solicit more feedback from NANOG, other sources (operators). ● Publish -02 (November, 2003) ● Decide on future direction WRT ANSI/T1, CC ● Publish Informational RFC, merge with ANSI/T1, form Working Group(s).

43. Adjourn ● Mailing List: opsec@ops.ietf.org, to subscribe: “echo 'subscribe opsec' | mail \ majordomo@ops.ietf.org” ● Archives @ http://ops.ietf.org/lists/opsec/ ● Continued feedback/comments welcome.