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

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

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

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

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

6. 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 4.05.  Microsoft implementations through August of 1999. D Balfanz, D Dean, E Felton, D Wallach

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

8. Desired State of Affairs for Safety Properties P S R

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

10. “Good” Traces E F G P S R

11. “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

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

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

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

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

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

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

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

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

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