1. Middleware for Building Adaptive Systems Via Configuration An SAIC Company S. Narain R. Vaidyanathan S. Moyer A. Shareef K. Parmeswaran Internet Architecture Laboratory Telcordia Technologies Morristown, NJ narain@research.telcordia.com

2. 2 Building Adaptive Systems Via Configuration  Very large, complex network services are created by integrating COTS components –700 locations in a large company’s WAN –15,000 routers in a single financial services company –Types of services: connectivity, performance and security  Configuration is fundamental integration operation –Components have static configuration parameters settable to definite values –Network administrators are not software developers  Adaptive network services are created by composing adaptivity of constituent protocols, e.g., OSPF, Mobile IP, SONET, MPLS-TE. –No external control system

3. 3 –Specification: How to define end-to-end service requirements? Comprehensive? –Integration: How to configure components to enable end-to-end requirements? –Diagnosis: If end-to-end services are not enabled, what is misconfigured *? –Reconfiguration: If requirements change, how to incrementally reconfigure? –Proof system: How to verify requirements? –Representing & reasoning about adaptation strategies –Distributed reconfiguration: No centralized controller So, What is the Problem?  Service creation/operations costs are high!  Needed: A “science” of configuration:  These problems are hard even if component interfaces are defined.  Solution: Service Grammar

4. 4 Service Grammar Architecture End-To-End Service Requirements (Service Architecture) Devices Configure (Big Leap!) Requirements (“Features”) Library Formalizes “correct configuration” for common protocols Decompose Proof Engine Provisioning Engine Enforce Diagnosis Engine Check Configuration Database (LDAP) Vendor-specific configurations From DEN Service Definition & Creation

5. 5 What Is In Requirements Library?  Useful relationships between configuration parameters of components –  “Features”  Their composition = end-to-end service requirement  Can we identify a comprehensive set of features?  Plan: –Identify features associated with all common standardized protocols. –Mix and match these to create requirements for very large class of services –Design diagnosis and provisioning engines around this “language”  Carried out for complex VPN protocols (routing, security, performance, mobility, multicasting)

6. 6 Migrating from Leased Line VPN To IPSec VPN 9.9.9.1 10.5.5.3 10.5.5.1 172.18.48.4 172.18.48.1 POP3-AR3 E0 RIP 2 POP3-CR4 E0 172.18.48.3 Hub RIP 2 Hub RIP 2 9.9.9.2 LDAP1 POP3-CR3 S0 S1 Service Requirements: – Connectivity – Security – Resilience (Adaptiveness) RIP 2 IPSec Tunnel ISP

7. 7 Restoring Resilience 9.9.9.1 10.5.5.3 10.5.5.1 172.18.48.4 172.18.48.1 POP3-AR3 E0 RIP 2 POP3-CR4 E0 172.18.48.3 s0 RIP 2 Service Architecture: –Subnets s0,..,s6 –GRE tunnels 1, 2, 3 –OSPF routing over s1, s2, s3, s5 –RIP routing over GRE tunnels and s0, s4, s6 –IPSec over GRE physical endpoints s4 s6 RIP 2 9.9.9.2 LDAP1 Tunnel IP 6.6.6.1 172.16.20.21 172.16.24.1 172.16.32.2 172.16.32.1 POP3-CR3 POP3-PR4 S0 S0/0 S0 POP3-PR3 172.16.4.1 E0/0 172.16.4.2 S1 S0 172.16.20.22 E0 S1 172.16.24.2 GRE Tunnel 1 Tunnel IP 6.6.6.2 Tunnel IP 7.7.7.2 Tunnel IP 7.7.7.1 GRE Tunnel 3 s5 s2 s3 s1 GRE Tunnel 2 OSPF Area 0

8. 8 Showing Tunnel Resilience T: 9.9.9.1 10.5.5.1 172.18.48.4 172.18.48.1 172.18.48.3 s0 s6 T: 9.9.9.2 LDAP1 T: 6.6.6.1 172.16.20.21 172.16.24.1 172.16.32.2 172.16.32.1 CR3 172.16.4.1 172.16.4.2 172.16.20.22 172.16.24.2 T: 6.6.6.2 T: 7.7.7.2 T 7.7.7.1 8.8.8.2 All three tunnels operational  CR3> traceroute 8.8.8.2 –1 9.9.9.2 –2 8.8.8.2 Shutdown Tunnel1 (9.9.9.1)  CR3> traceroute 8.8.8.2 –1 7.7.7.2 –2 6.6.6.1 –3 8.8.8.2

9. 9 Sample Router Configuration Parameters

10. 10 Service Grammar Architecture End-To-End Service Requirements (Service Architecture) Devices Configure (Big Leap!) Requirements (“Features”) Library Formalizes “correct configuration” for common distributed algorithms. Decompose Proof Engine Provisioning Engine Enforce Diagnosis Engine Check Configuration Database (LDAP) Vendor-specific configurations From DEN Service Definition & Creation

11. 11 Subnetting & RIP Routing Features Router 3 Router 2 Router 1 PC 1 PC 2 Ethernet 129.96.41.0 255.255.255.0

12. 12 OSPF Routing Features Backbone area Stubby area Regular area Totally stubby area Not so stubby area RIP Domain Route redistribution

13. 13 IPSec & GRE Tunneling Features Router 1 Router 2 Router 1 Router 2 ISP IPSec GRE ISP

14. 14 Expressing Service Architecture As Composition of Features  network_of_resilient_tunnels = –Subnets s0,..,s6 & –GRE tunnels 1, 2, 3 & –OSPF routing over s1, s2, s3, s5 –RIP routing over GRE tunnels and s0, s4, s6 –IPSec over GRE physical end points

15. 15 Service Architecture  LDAP  IOS  interface Ethernet0  ip address 172.18.48.1 255.255.255.0  interface Serial0  ip address 172.16.32.2 255.255.255.0  encapsulation ppp  interface Tunnel0  ip address 7.7.7.1 255.255.255.0  tunnel source 172.16.32.2  tunnel destination 172.16.24.2  crypto map vpn-map-Serial0  interface Tunnel1  ip address 9.9.9.1 255.255.255.0  tunnel source 172.16.32.2  tunnel destination 172.16.20.22  crypto map vpn-map-Serial0  router rip  version 2  network 172.18.48.0  network 7.7.7.0  network 9.9.9.0  router ospf 1  network 172.16.32.0 0.0.0.255 area 0  crypto isakmp key Site1-2 address 172.16.24.2  crypto ipsec transform-set IPSecProposal esp-des esp-sha-hmac  crypto map vpn-map-Serial0 1 ipsec- isakmp  set peer 172.16.24.2  set transform-set IPSecProposal

16. 16 Diagnosis Engine  If devices work but end-to-end services don’t work, determine what is misconfigured.  This problem is not addressed by current fault management systems.  Evaluates whether a features has been set up given existing device configurations.  Service requirement is true if each of the features in it has been set up

17. 17 Open Problems: Building Explicit Adaptation Logic & Distributing It Full MeshClient-Server Multicast # participants > threshold1 Security breach at server Security breach at server # participants > threshold2 Each configuration phase represents a state machine Yet, reason about these using Temporal Logic techniques? Consider distributing OSPF logic Delete server Reelect server

18. 18 Open Problems  Extension to distributed algorithms for design of computer systems (e.g., CORBA infrastructure)  Proof Engine: –To check if total solution (end-to-end service architecture) is correct. –Different from diagnosis engine –Like a checker of program correctness –For example:  Is traffic routed out of interface to which protection is applied?  Does a traffic filter subsume another at an interface?  Does NAT interfere with IPSec?  Efficient Reconfiguration –To network of resilient tunnels, add:  Add QoS  Add/delete sites  Add firewalls

19. 19 Summary  Complex adaptive systems are created by configuring COTS components  Yet there has been no “science” of building such systems via configuration  Service Grammar is an attempt to create this via novel analysis of protocol definitions: –Requirements Library (formalizes “correct” configuration for different protocols) –Diagnosis Engine –Provisioning Engine  Illustrated by designing and provisioning a network of resilient tunnels  Successful experience with a wide range of VPN protocols