Relating Artifacts for Networking Software Carl A. Gunter Verinet Project University of Pennsylvania.

Slides:



Advertisements
Similar presentations
1 Verification by Model Checking. 2 Part 1 : Motivation.
Advertisements

Network Troubleshooting: rcc and Beyond Nick Feamster Georgia Tech (joint with Russ Clark, Yiyi Huang, Anukool Lakhina)
1 Copyright © 2005, Oracle. All rights reserved. Introducing the Java and Oracle Platforms.
Abstraction and Modular Reasoning for the Verification of Software Corina Pasareanu NASA Ames Research Center.
Demonstration Of SPIN By Mitra Purandare
Java Security: From HotJava to Netscape & Beyond Drew Dean, Edward W. Felten, Dan S. Wallach Department of Computer Science, Princeton University May,
Formal Verification of AODV Protocol using Cadence SMV Xin Liu and Jun Wang (CPSC513 Course.
CS 490M Software Testing Company Sponsored Projects An Overview [Under Construction] Fall 2006 Instructor: Aditya Mathur August 21, 2006.
L4-1-S1 UML Overview © M.E. Fayad SJSU -- CmpE Software Architectures Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I.
Causality Interface  Declares the dependency that output events have on input events.  D is an ordered set associated with the min ( ) and plus ( ) operators.
Model Checking. Used in studying behaviors of reactive systems Typically involves three steps: Create a finite state model (FSM) of the system design.
The Basics of Software Testing
8/3/011 Formal methods for CARA development Insup Lee (Univ. of Pennsylvania) Rance Cleaveland (SUNY at Stony Brook) Elsa Gunter (NJIT)
Lesson 18: Configuring Application Restriction Policies
AppSec USA 2014 Denver, Colorado Threat Modeling Made Interactive! Eunsuk Kang Software Design Group CSAIL, MIT.
5/24/011 Advanced Tool Integration for Embedded Systems Assurance Insup Lee Department of Computer and Information Science University of Pennsylvania.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 1 Software testing.
Java Introduction 劉登榮 Deng-Rung Liu 87/7/15. Outline 4 History 4 Why Java? 4 Java Concept 4 Java in Real World 4 Language Overview 4 Java Performance!?
Verification technique on SA applications using Incremental Model Checking 컴퓨터학과 신영주.
Cheng/Dillon-Software Engineering: Formal Methods Model Checking.
Software Testing Verification and validation planning Software inspections Software Inspection vs. Testing Automated static analysis Cleanroom software.
Towards a Logic for Wide- Area Internet Routing Nick Feamster Hari Balakrishnan.
Introduction to Java Kumar Harshit. Objectives ( 목적지 ) At the end of the lesson, the student should be able to: ● Describe the features of Java technology.
Software Testing. Definition To test a program is to try to make it fail.
1. Topics to be discussed Introduction Objectives Testing Life Cycle Verification Vs Validation Testing Methodology Testing Levels 2.
SCOTT KURODA ADVISOR: DR. FRANZ KURFESS Encouraging Secure Programming Practice in Academia.
Objectives Understand the basic concepts and definitions relating to testing, like error, fault, failure, test case, test suite, test harness. Explore.
VTT-STUK assessment method for safety evaluation of safety-critical computer based systems - application in BE-SECBS project.
COE4OI5 Engineering Design. Copyright S. Shirani 2 Course Outline Design process, design of digital hardware Programmable logic technology Altera’s UP2.
Testing Workflow In the Unified Process and Agile/Scrum processes.
PRESTO: Improvements of Industrial Real-Time Embedded Systems Development Process
Reusability and Effective Test Automation in Telecommunication System Testing Mikael Mattas Supervisor: Professor Sven-Gustav Häggman Instructor: B.Sc.
Software Engineering Quality What is Quality? Quality software is software that satisfies a user’s requirements, whether that is explicit or implicit.
Basic of Software Testing Presented by The Smartpath Information System An ISO 9001:2008 Certified Organization
Dichotomies: Software Research vs Practice Peter Lee Carnegie Mellon University HCMDSS Workshop, June 2005 Peter Lee Carnegie Mellon University HCMDSS.
Ethan Jackson, Nikolaj Bjørner and Wolfram Schulte Research in Software Engineering (RiSE), Microsoft Research 1. A FORMULA for Abstractions and Automated.
BE-SECBS FISA 2003 November 13th 2003 page 1 DSR/SAMS/BASP IRSN BE SECBS – IRSN assessment Context application of IRSN methodology to the reference case.
Verifying Autonomous Planning Systems Even the best laid plans need to be verified Prepared for the 2005 Software Assurance Symposium (SAS) DS1 MSL EO1.
CS Software Testing Company Sponsored Projects An Overview Fall 2009 Instructor: Aditya Mathur August 24, 2009.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 22 Slide 1 Software Verification, Validation and Testing.
Fault-Tolerant Parallel and Distributed Computing for Software Engineering Undergraduates Ali Ebnenasir and Jean Mayo {aebnenas, Department.
Technology Layer. Technology Layer Metamodel Technology Layer Concepts.
Towards a Compositional SPIN Corina Păsăreanu QSS, NASA Ames Research Center Dimitra Giannakopoulou RIACS/USRA, NASA Ames Research Center.
1 CSEP590 – Model Checking and Automated Verification Lecture outline for August 6, 2003.
Architecture Analysis Techniques
PerfSONAR-PS Functionality February 11 th 2010, APAN 29 – perfSONAR Workshop Jeff Boote, Assistant Director R&D.
Chapter 1: Fundamental of Testing Systems Testing & Evaluation (MNN1063)
HACNet Simulation-based Validation of Security Protocols Vinay Venkataraghavan Advisors: S.Nair, P.-M. Seidel HACNet Lab Computer Science and Engineering.
Software Engineering1  Verification: The software should conform to its specification  Validation: The software should do what the user really requires.
Slide 1 A Reference Model for Requirements and Specifications NOTES.
Object Oriented Analysis and Design 1 Chapter 9 From Design to Implementation  Implementation Model  Forward, Reverse, and Round-Trip Engineering  Mapping.
TESTING FUNDAMENTALS BY K.KARTHIKEYAN.
Formal Methods in Software Engineering1 Today’s Agenda  Mailing list  Syllabus  Introduction.
Software Engineering Lecture 8: Quality Assurance.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 1 Software testing.
T EST T OOLS U NIT VI This unit contains the overview of the test tools. Also prerequisites for applying these tools, tools selection and implementation.
Introduction to Programming 1 1 2Introduction to Java.
What is a software? Computer Software, or just Software, is the collection of computer programs and related data that provide the instructions telling.
Mutation Testing Laraib Zahid & Mariam Arshad. What is Mutation Testing?  Fault-based Testing: directed towards “typical” faults that could occur in.
Copyright 1999 G.v. Bochmann ELG 7186C ch.1 1 Course Notes ELG 7186C Formal Methods for the Development of Real-Time System Applications Gregor v. Bochmann.
Java High level programming language ◦ Sun Microsystems ◦ ORACLE acquired Java Development Kit – JDK Java Runtime Environment – JRE Java Virtual Machine.
Jidoka in Software Development Emanuele Danovaro, Andrea Janes, Giancarlo Succi Center for Applied Software Engineering Free University of Bolzano/Bozen,
Verifying Stability of Network Protocols
Verisim: Formal Analysis of Network Simulations
A Reference Model for Requirements and Specifications
.Net A brief introduction to
System Analysis and Design
System Analysis and Design
CS 240 – Advanced Programming Concepts
Presentation transcript:

Relating Artifacts for Networking Software Carl A. Gunter Verinet Project University of Pennsylvania

Artifact Correspondence Problem l Theory. (Requirements.)  No routing loops. l Standard. (Specification.)  RFC, Internet Draft. l Implementation. (Program.)  Simulation or deployment software.

WRSPM Reference Model WRSPM EnvironmentSystem World knowledge Requirements SpecificationProgram Programming Platform (Machine) 98 CA Gunter, EL Gunter, M Jackson, P Zave

Two Projects l Verisim: support for checking whether network simulations satisfy requirements. l Fault Origin Adjudication: support for determining whether a failure is caused by a flaw in the specification or in the implementation.

Fault Origin Adjudication l A failure of a requirement in an implementation is evidence of a fault. l Where is the fault?  In the implementation: repair the bug.  In the standard specification: inform the standards body and negotiate a new standard. l Both are common. l We demonstrate a strategy for determining which case applies. K Bhargavan, CA Gunter, D Obradovic

Programming Language Example l Requirement R: JVM is “type safe”. l Specification S: JVM specification document from Sun, allowed non-type- safe behaviors in class loaders. l Programs P: Satisfied standard and realized bad behaviors.  Sun JDK in versions 1.1.x.  Netscape implementations up to  Microsoft implementations through August of D Balfanz, D Dean, E Felton, D Wallach

Example Scenario l Requirement R: no loops in AODV. l Specification S: AODV Internet Draft. l Program P: Monarch simulation code for NS. l Experiment shows that P fails to conform to R. l Where is the fault? l We show an automated approach for safety properties.

Desired State of Affairs for Safety Properties P S R

Typical State of Affairs A B C D E F G SP R

“Good” Traces E F G P S R

“Bad” Traces l A: Traces allowed by the standard that break the requirements and are realizable by the program. l B: Traces allowed by the standard that break the requirements and are not realizable by the program. l C: Traces that can be realized by the program and break the requirements, but are disallowed by the standard. l D: Traces that can be realized by the program and satisfy the requirements, but have been disallowed by the standard. A B C D E F G SP R

FOA Framework P W Trace T S R M YES NO T  S ? YES NO T  R ? Trace Generator Property Checker Conformance Checker

FOA Conclusions T  RT  R T  SEA T  SDC Property Check Conformance Check

FOA Recommendations l E: Everything is ok. l A: Fault in standard, refer to standards body for revision and change program accordingly. l C: Incorrect implementation of the standard, remove fault from program. (Does not satisfy requirements.) l D: Incorrect implementation of the standard, remove fault from program. (Possible problems, eg. interoperability.)

FOA Realization Trace Instrumented Protocol: C++ Scenario: OTcl NS SPIN Property Checker SPIN Conformance Checker

SPIN Property Checker Trace R FR: Formula Package: Promela TransREQ: Manual Parse: PERL YES NO T  R ? SPIN Verifier

SPIN Conformance Checker Trace S PS: Promela Package: Promela TransSPEC: Manual Parse: PERL YES NO T  PS ? SPIN Verifier Driver: Promela

Experiment l Used FOA tool to adjudicate failures arising in each of the realizable categories (A, D, C) using:  R = Loop-freedom property.  S = AODV Internet Draft Version 0.  P = Monarch NS implementation. l Note: SPIN is able to search for A- category faults (deviation of S from R), but is not scalable beyond 2 or 3 nodes.

Summary l Introduced the concept of Fault Origin Adjudication and the FOA framework. l Implemented a realization of the FOA framework using SPIN. l Applied this realization to demonstrate fault adjudication for existing router simulation code and Internet Draft standard.

Relevance to Embedded Systems l New technology for embedded systems with programmable interfaces.  Example: MIDP and CLDC for programmable personal information devices. l We will need to carefully model distinctions between environment assumptions, specified behavior, and implemented behavior.  Example: Patriot missile system. l Project idea: a programming interface for microwave ovens (MODP?).