This documents the strawman proposal (presented at ONAP Session September 27, 2017) current draft for how to handle requirements that would be of interest to the ONAP operators as they implement ONAP into production.
...
ATT Review of ONAP Carrier Grade Requirements.pptx
Presentations
ONAP-Carrier Grade for TSC 19October2017.pptx
Software Architecture 11December2017.pdf
Approved Platform Maturity Requirements for Beijing
Platform Maturity Level proposal 13Dec2017v2.pdf
(Approved by the TSC at the Santa Clara meeting)
General Approach
- The goal of this effort is to define requirements to enable ONAP for carrier implementations. It is not to deliver a specified carrier-grade configuration of ONAP, but to build all the software hooks necessary for an operator to deliver a 5-9’s carrier grade environment at their own expense
- Process
- For each category of carrier-grade requirements, multiple levels of requirements will be established and presented to the TSC.
- The Architecture Committee, in cooperation with the project teams, will establish guidelines for requirement levels that must be met by each project for each release. The required level may be influenced by: MVP project status, desired project maturity level, release inclusion, component criticality (run-time vs. design time).
...
- Level 0: no redundancy
- Level 1: support manual failure detection & rerouting or recovery within a single site; tested to complete in 30 minutes
- Level 2: support automated failure detection & rerouting
- within a single geographic site
- stateless components: establish baseline measure of failed requests for a component failure within a site
- stateful components: establish baseline of data loss for a component failure within a site
Level 3: support automated failover detection & rerouting
across multiple sites
stateless components
improve on # of failed requests for component failure within a site
establish baseline for failed requests for site failure
stateful components
improve on data loss metrics for component failure within a site
establish baseline for data loss for site failure
- These levels may drive the need for a common platform for resiliency & approaches to consistently provide resiliency across ONAP. Such a platform might contain:
- a geo-distributed database that supports both within and cross-site state replication
- a failover mechanism that performs failure detection, request rerouting and the actual failover and
- a site/replica selection service that picks among the appropriate replicas during request rerouting.
...
ONAP Platform-level requirements (Security subcommittee to finalize percentages)per release
- Level 1: 70 % of the projects passing the level 1 (1
- with the non-passing projects reaching 80% passing level
- Non-passing projects MUST pass specific cryptography criteria outlined by the Security Subcommittee*
- Level 2: 70 % of the projects passing silver (silver
- with non
- -silver projects completed passing level and 80% towards silver
- level
- Level 3: 70% of the projects passing gold (gold
- with non
- -gold projects achieving silver level and achieving 80% towards gold
- level
- Level 4: 100 % passing gold.
...
- Level 1:
- All ONAP components will use a single logging system.
- Instantiation of a simple ONAP system should be accomplished in <1 hour with a minimal footprint
- Level 2:
- A component can be independently upgraded without impacting operation interacting components
- Transaction tracing across components
- Component configuration to be externalized in a common fashion across ONAP projects
Usability (applies to entire ONAP Project)
- Level 1
- User guide created
- Deployment documentation
- API documentation
- Adherence to coding guidelines
- Level 2
- Consistent UI across ONAP projects
- Usability testing conducted
- Tutorial documented
*Specific cryptopgraphy requirements for security level 1:
- The software produced by the project MUST use, by default, only cryptographic protocols and algorithms that are publicly published and reviewed by experts (if cryptographic protocols and algorithms are used).
- If the software produced by the project is an application or library, and its primary purpose is not to implement cryptography, then it SHOULD only call on software specifically designed to implement cryptographic functions; it SHOULD NOT re-implement its own.
- The security mechanisms within the software produced by the project MUST use default keylengths that at least meet the NIST minimum requirements through the year 2030 (as stated in 2012). It MUST be possible to configure the software so that smaller keylengths are completely disabled.
- The default security mechanisms within the software produced by the project MUST NOT depend on broken cryptographic algorithms (e.g., MD4, MD5, single DES, RC4, Dual_EC_DRBG) or use cipher modes that are inappropriate to the context (e.g., ECB mode is almost never appropriate because it reveals identical blocks within the ciphertext as demonstrated by the ECB penguin, and CTR mode is often inappropriate because it does not perform authentication and causes duplicates if the input state is repeated).
- The default security mechanisms within the software produced by the project SHOULD NOT depend on cryptographic algorithms or modes with known serious weaknesses (e.g., the SHA-1 cryptographic hash algorithm or the CBC mode in SSH).
- If the software produced by the project causes the storing of passwords for authentication of external users, the passwords MUST be stored as iterated hashes with a per-user salt by using a key stretching (iterated) algorithm (e.g., PBKDF2, Bcrypt or Scrypt).Documentation completion/consistency [need metric]