Applying Assurance-Based Design to Detecting Misconfigurations of Network Recovery SEDC 2014 (April 3-5) Joseph Kroculick Cynthia Hood 1
Introduction Describe Dependability Assessment Process (DAP) Dependability, Services, Detecting Correct Configuration Apply Dependability Assessment Process to Detecting a Provisioning Error Define How Each Activity in the Dependability Assessment Process is Performed 2
Current Telecommunications Environment Heterogeneous Distributed Horizontal and vertical divergence of solutions Many alternatives provided to an administrator Technologies Vendors Hardware Software Manual provisioning needs to be supported at the device level Infrastructure decisions made without understanding the end-to-end view of the architecture (the system dynamics) 3
Network Environment Issues Potential for misconfiguration Complex system dynamics and operations Gap between service requirements and device state Fragmented device data models Service requirements are informal Telecommunications service provisioning is performed through device configuration at a command-line interface 4
Network Environment Issues Potential for misconfiguration Complex system dynamics and operations Gap between service requirements and device state Fragmented device data models Service requirements are informal Telecommunications service provisioning is performed through device configuration at a command-line interface 5
Network Environment Issues Potential for misconfiguration Complex system dynamics and operations Gap between service requirements and device state Fragmented device data models Service requirements are informal Telecommunications service provisioning is performed through device configuration at a command-line interface 6
Multilayer Network Infrastructure 7
Examples of a Configuration Conflict Protocol parameter mismatches (e.g. disagreements on directionality between routers A and B) Inconsistent escalation strategies through hold-off timers for each recovery protocol Conflict: HDA, Layer 1? HDA, Layer 0, HDB, Layer 1 = HDB, Layer 0 Example Network Misconfiguration/Conflic t 8
Assurance-Based Design Approach to Detecting Provisioning Conflicts Assurance-based design (ABD) Characterized by a system model accompanied by an assurance case (Hall & Rapanotti, 2008; Graydon, Knight & Strunk, 2008) An assurance case is a set of goals made about the system and arguments are provided to support the claims (Strunk, Knight, 2006) An assurance/dependability case has two parts: Step 1: Goodness properties of a system are established (Jackson, 2009) (e.g. recovery of traffic within an acceptable delay) Step 2: An argument is made that the network system satisfies these critical properties (Jackson, 2009) Apply dependability cases to assess correct configurations in IP networks (Norros, Kuusela, & Savola, 2008) 3/24/14 9
Assurance Case
Assurance Case (Goal Decomposition
Assurance Case Ontology 12
Dependability Dependability can be defined as ``the ability to deliver service that can justifiably be trusted'' Avizienis, Laprie, Randall, & Landwehr (2004) A service is ``a product that is not tangible and not storable'' (CMMI for Services, 2010) Dependability can be defined in terms of confidence or the trustworthiness that a system provides functionality consistent with a user's expectations (i.e. service requirements) 13
Dependability Assessment Process (DAP) Implements Dependability Case Workflow represented in Business Process Modeling Notation (BPMN) Knowledge/Informat ion Models use Activities and Ontologies 14
Example Network Configuration 1+1 Unidirectional Protection Generic RequestResponse Protocol between protection ports Single Shared-Link Risk Group (links w1-w2, w2w1) SRLG1 Fails Provision network components a1, w1, w2, a2, p1, and p2 to restore traffic 15
Define/Update Problem Context Define the Problem Context Define application requirements Define business requirements Define architectural constraints The context is the circumstances that form the setting for the problem Availability of technologies Architectural alternatives Costs of implementation Requirements of the end-user 3/24/14 # 16
Build Domain Model Build Network Ontology in Web Ontology Language (OWL) Domain modeler builds a logical model of network infrastructure Domain ontology represents network infrastructure viewpoint such as a topology, event operations, or network information Essential resource types and relationships between them represented as an OWL ontology Example network infrastructure terms: {layer, link, connection, link connection, network connection, termination points, ports, router labels, cross-connection} Relationship terms: {bridge (split), switch (merge)} 3/24/14 # 17
Connectivity Represented in OWL Example Statement: urn:a1 urn:bridgedto urn:p1 3/24/14 18
Bridge, Switch Terms Defined Bridge action is redirecting traffic from a working transmitter to a protection transmitter Switch action is selection of traffic from a protection receiver 3/24/14 19
Specify Service Requirements Define the user s expectations on network services provided by the network infrastructure Applications today need to identify and formalize their service requirements Service requirements need to be matched to many fine-grained decisions made on configuration settings of network resources Service Level Specification (SLS) (e.g. expected throughput, jitter, endto-end delay, drop probability, latency, multipath bandwidth, security level) Example: Acceptable Outage Duration 10 ms for Fault Detection 50 ms for Recovery SR1: The network infrastructure shall provide a connected network after the SONET 50ms outage duration 3/24/14 20
Identify Dependability Property Spatial Property Strong Connectivity Temporal Property Bounded Temporal Difference 3/24/14 21
Specify Provisioning Provisioning Example RPC Command Sent To Router using NETCONF API Specify provisioning commands in router vendor XML data model Example: Represent Device Technology in Juniper s JUNOS XML <rpc messageid="messageid"> <edit-config> <target> <candidate/> </target> <url> ftp://kroculick:kroculickpwd@ft p.kroculick.com/% %F2var/tmp/configFile </url> </edit-config> </rpc> ]]>]]> Router data elements are enclosed in XML tags Send XML to Device Using NETCONF # 3/24/14
XML-Based Device Data Model XML-device specific model maps into a common domain ontology Verify that systems interoperate Errors in operation that would result from provisioning are detected XML allows syntactic checks Multivendor devices have different data models Common semantic model Behavior and structure are dependent since actions of recovery operate on a network structure 23
JUNOS XML 24
Update Domain Model Converts provisioning commands to changes to a logical model Example Change commands applied to a router data model expressed in XML can be transformed to a common OWL model serialized in RDF/XML 3/24/14 25
Application JUNOS XML to OWL RDF/XML Transformation Rules Transform XML device data model using XSLT script or XML parser script to an OWL RDF/XML data schema to a network ontology Example: Mapping of Port so-1/1/0, Logical Unit 0, IP Address: 10.1.2.3 to a PortID 26
Define Conflict Statement (1) A particular situation needs to be described in terms of local decisions and properties A conflict statement connects an end-to-end dependability property to key relationships between individuals in a domain ontology Determine key relationships that must exist to enable consistency between actions of recovery bridged (a, x, y ) and switched (peer (a ), peer (x ), peer (y )) 3/24/14 # 27
Define Conflict Statement (2) Connect Statements Build Conflict Statement Compose axioms on local properties of routers that need to hold for the model to meet an end-to-end dependability property A conflict statement specifies key relationships between local properties within a switch 3/24/14
Detect Conflict Conflict Detection SPARQL Query Implemented using a SPARQL query on an inferred RDF graph Inference engine infers whether end-to-end desirable properties are true or false Example: return whether ports a1 and a2 are connected AND where they are access ports 3/24/14
Validate Model Allow the previous knowledge to be refined or return to the detect conflict activity Allows the system context to be updated as knowledge is discovered about the problem context Models to be refined based on updated information 3/24/14 30
Conclusion Dependability Assessment requires feedback/lessons learned and: Understanding of system dynamics (situations that can occur) and a suitable domain model/knowledge representation Network-level properties that have been identified in well-engineered networks Semantic interoperability between router provisioning options supports consistent behavior in implementing network infrastructure services Knowledge representation using ontologies allows network infrastructure concepts and requirement concepts to be related Inferred model can be queried to detect end-to-end conflicts31
References Avižienis, A., Laprie, J.-C., Randall, B., & Landwehr, C. (2004, January-March). Basic Concepts and Taxonomy of Dependable and Secure Computing. IEEE Transactions on Dependable and Secure Computing, 1(1), 11 33. Cisco Systems Corporate Iconography. (n.d.). Retrieved from http://www.cisco.com [Some drawings adapt and/or include Cisco corporate symbols to represent networks and devices] CMMI Product Team. (2010). CMMI for Services, Version 1.3. Report Number CMU/SEI-2010-TR-034 Graydon, P., Knight, J., & Strunk, E. (2007). Assurance-Based Development of Critical Systems. In 37th annual ieee/ifip international conference on dependable systems and networks.
References, 2 Jackson, D. (2009, April). A Direct Path to Dependable Software. Communications of the ACM, 52(4). Norros, I., Kuusela, P., & Savola, P. (2008). A Dependability Case Approach to the Assessment of IP Networks. In The second international conference on emerging security information, systems and technologies. IEEE. Strunk, E. A., & Knight, J. C. (2006b). The Essential Synthesis of Problem Frames and Assurance Cases. In Iwaapf 06. ACM.
Questions? Email: krocjoe@acm.org Cell: (215) 429-5635 http://winifredassociates.com 35