Page History

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.

...

Draft Architecture Principles

Presentations

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).

...

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
  sliver 80% of
  • -silver projects completed passing level and 80% towards silver
  )
  • level
• Level 3: 70% of the projects passing gold (gold 
  • with non
  gold at 80% passing level
  • -gold projects achieving silver level and achieving 80% towards gold
  )
  • level
• Level 4: 100 % passing gold.

...

• Documentation completion/consistency [need metric]

*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).