Relating Artifacts for Networking Software Carl A Gunter

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

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

WRSPM Reference Model Environment W World knowledge R Requirements System S Specification 98 CA Gunter, EL Gunter, M Jackson, P Zave P Program M Programming Platform (Machine)

Two Projects 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. l

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

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

Example Scenario 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. l

Desired State of Affairs for Safety Properties R S P

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

“Good” Traces R G S P F E

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

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

FOA Conclusions Property Check T R T S E A T S D C Conformance Check

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

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

SPIN Property Checker R Trans. REQ: Manual SPIN Verifier FR: Formula Trace Parse: PERL Package: Promela T R? YES NO

SPIN Conformance Checker S Trans. SPEC: Manual PS: Promela Driver: Promela SPIN Verifier T PS ? Trace Parse: PERL Package: Promela YES NO

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 Acategory faults (deviation of S from R), but is not scalable beyond 2 or 3 nodes.

Summary 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. l

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