Secure and Reliable Multicast Video Distribution Team 4

Secure and Reliable Multicast Video Distribution Team 4 Active Networks Demonstrations 8 December 2000

Team Four Composition UMass/TASC AER Reliable Multicast Maude SRI/Stanford CANEs EE GT/UKy Security Guardian UIUC Barman Bowman Node. OS NISTNet WAN Emulator Wash U code server

Team Objectives • Demonstrate composition of active network services – including components developed independently • Demonstrate benefits of choosing/combining functional elements in many dimensions: – – placement of functions at strategic points in topology real multicast data transport services trust management for multicast routing verification of correctness, compositionality

Demo Overview • Application: MPEG 2 video multicast • To be demonstrated: – Benefits of active processing in a real application: (almost) side-by-side comparison of video quality with and without active error recovery – Protocol Correctness: Formal methods have found errors in key protocols and algorithms – Performance: Active processing of MPEG frames at 2. 74 Mbps – Security: Modification and enforcement of security policy; resistance to denial-of-service attacks – Integration: independently-developed functionalities incorporated into CANEs EE and Bowman Node. OS

Team 4 Demonstration Configuration AER/NCA Send Applications (Sun Ultra 5 s/Solaris) NIST Net WAN Emulators (200 MHz Pentium Pros/LINUX) CANEs Active Node (Dual Processor Sun Ultra 2/Solaris) NIST Net WAN Emulator (733 MHz Pentium III/LINUX) CANEs Active Node (Dual Processor Sun Ultra 2/Solaris) AER/NCA Receive Apps (Windows NT with HW MPEG 2 Decoders)

Presentation Outline • Overview (Ken Calvert) – Team introduction, application, demo topology • Highlight 1: Active Error Recovery (Steve Zabele) – Protocol overview, error recovery modes • Highlight 2: Formal Analysis (Jose Meseguer) – Errors identified using Maude • Highlight 3: Composition using CANEs (Ellen Zegura) – CANEs/Bowman operation • Highlight 4: Security (Roy Campbell) – Enforcement scenarios, Anti-DOS check • Wrapup (Ken Calvert)

Highlight 1: Active Reliable Multicast UMass/TASC AER Reliable Multicast CANEs EE Security Guardian Barman Bowman Node. OS Maude

Active Multicast Repair Services Traditional Error Recovery (TCP) Conventional Sender Routers Retransmitted message Active Error Recovery (AER) Active Packet Active Routers Active Node Link causing loss of original message Lost message retransmission request Active Packet ‘ Loss detected by nearest router downstream from loss Receiver Repair latency is a complete round trip time Message retransmitted by nearest router upstream from loss Repair latency much less than one round trip Base premise: Active Networking can significantly improve latency, efficiency, and scalability of transport protocols

AER/NCA AER Repair Servers (RSs) • Co-located with routers AER loss handling: • • • Sender Rcvrs and RSs unicast NAKs RSs subcast NAKs one level downstream subcast repairs, NAK supression Repair Servers NCA • • • Routers Estimating worst receiver TCP friendliness Decoupled from AER Receivers

Demo Performance Indicators Total AER Packets Received Short-term average “goodput” in packets/sec Short-term average of error recovery ratio -> dropped packets recovered / dropped packets detected Short-term average delay in packet recovery

AER Demo: Semi-reliable Multicast MPEG-2 Video Client Video Server (Multicast) Multicast MPEG-2 Video Client Emulated bottleneck link With repair servers inactive, dropped packets not repaired before playout time: quality suffers With repair servers active, dropped packet repaired before playout time: quality improved

Highlight 2: Maude Analysis of AER/NCA Reliable Multicast SRI/Stanford CANEs EE Security Guardian Barman Bowman Node. OS Maude

Problem Description • Have: – Suite of sophisticated AN-based protocol components collectively implementing a reliable multicast capability – Existing design document in UML-like use cases • Wanted: – Formal executable model for validation and analysis • Modeling challenges: – – Time-sensitive behavior Resource-sensitive behavior Both correctness and performance as critical metrics Composability adds a new dimension

Early Observations • Extant PANAMA protocol components specified as Use Cases • Maude input specification (much!) closer to statetransition methodology • State-transition methodology far clearer, much closer to what is needed for protocol specification, implementation, debugging • Maude input specification a strong, interesting candidate for a protocol specification language

Technical Breakthroughs Using Maude • Incorporation of explicit time modeling and analysis support within formal framework • Incorporation of explicit resource modeling and analysis support within formal framework • Incorporation of performance as well as correctness assessment capabilities complementing time and resource mechanisms • Support for explicit modeling and assessment of both individual protocol components and aggregate protocol compositions

The Real-Time Maude Tool • Supports distributed object-oriented formal of network protocols by rewrite rules of the form S S S’ if cond S’ in time t if cond • Type 1 rules indicate instantaneous transitions from state S to state S’ • Type 2 rules indicate transitions in time t

The Real-Time Maude Tool - II • Real-Time Maude specifications are executable, and can be used to find errors in specifications by: – symbolic simulation – model checking • Formal specifications in Real-Time Maude provide a mathematical model for which important properties can be subjected to theorem proving.

Configuration for analysis sender a c b rcvr d e rcvr f rcvr g rcvr

Analysis of the Repair Service Component -- Setup • A sender application and receiver applications were added to the basic configuration. • The sender has 21 packets to multicast • The system should reach a state in which each receiver has seen all 21 packets.

Analysis of the Repair Service Component -- Result 1 • Using symbolic simulation a deadlock is uncovered Maude> ( rew- [3000] Rstate. ) result Clocked. System: {ERROR} in time 17841

Analysis of the Error State • Inspection of the rules allowed determination of: – the rule introducing the error state -- bound on NAK count exceeded • Examining intermediate states allowed determination of: – the use cases causing the faulty behavior -- repair server has dropped the repair packet and lost ability to recover it

Analysis of the NOM Component: Setup • The desired property is that if there is a nominee, then some receiver has its nominee flag set to True. • This is important because only a receiver with nominee flag True acknowledges data packets. Unacknowledged data packets may lead to rate control problems

Analysis of the NOM Component: Result • Using model-checking we find a state in which the sender has assigned a nominee but no receiver has a True nominee flag. Maude>. . . result Clocked. System: { <‘e: NOMreceiver. Alone|is. Nomiee: false, . . . > <‘a: NOMreceiver. Alone|csm. Nomiee: ’e, . . . >. . . } in time 19504

Value Added • Found mistakes and omissions in original use cases, while developing the Maude specification • Found significant design problems/errors through execution and analysis of the Maude specification* • Ability to validate subprotocols in isolation as well as in combination: • Approach easily extensible to new designs * Maude was able to identify all protocol errors uncovered a priori through more extensive simulation and testing (ns, ABONE, CANEs) (and more). Errors were not revealed to Maude team until after the analysis was completed.

Highlight 3: CANEs/Bowman Reliable Multicast CANEs EE GT/UKy Security Guardian Barman Bowman Node. OS Maude

Bowman Node. OS admin flows signaling Bowman channels virtual code fetch topos state-store a-flows security timers Host OS

CANEs EE model predefined slots generic processing function customizing code incoming channels outgoing channels

Walkthrough receiver 0 source 0 R 0 S 0 activenode 0 WAN emulators S 1 source 1 A 0 activenode 1 A 1 R 1 receiver 1

Step 1: Configure virtual topos S 0 virtual topos A 0 S 1 R 0 A 1 cockpit management station R 1 one unicast, bidirectional topology multiple unidirectional multicast topologies (e. g. , (S 1, {R 0, R 1})

Step 2: Send signaling messages S 0 signaling A 0 S 1 R 0 A 1 management station R 1

Step 2 a: Guard signaling calls signaling a-flow (with “undo” capabilities) 1: sg_hwt. Init(certificate, call. Params) Security Guardian 2: hwt. Init(call. Params) Bowman

Step 2 b: Load code signaling flow code fetch flow WU gateway 4: 0 xabcd 3: foo. c 1: wucf: : //foo. c SG code fetch module 2: foo. c 5: foo. c Bowman WU code server

Step 2 c: Instantiate a-flows generic forwarding (mcast) eight a-flows DATA CANEs lookuproute: ip_lookup postprocess cache_put data pkt postproc

Step 3: Transmit data timers set/sec SPM DATA timers cancelled/sec control pkts/sec data pkts/sec

Step 4: Check authorization generic forwarding (mcast) source path msg flow (SPM) CANEs preprocess authorize Security Guardian

Highlight 4: Security Policy Management Reliable Multicast CANEs EE Security Guardian UIUC Barman Bowman Node. OS Maude

Seraphim Security Guardian BOWMAN/CANES: Active Security for Active Networks University of Illinois at Urbana-Champaign

Demo-A 0 knows A 1 Cert Server Wan Em Active Router 0 [, A 1] Wan Em Active Router 1 [, ] Client 0 Client

Demo- Video Flow Starts Server Wan Em Active Router 0 [, A 1] Wan Em Active Router 1 [, ] Client 0 Client

Demo- Policy Installed Server Wan Em Active Router 0 [P 1 s, A 1] Wan Em Active Router 1 [, ] Client 0 Client

Demo- Video Flows Server Wan Em Active Router 0 [P 1 s, A 1] Wan Em Active Router 1 [, ] Client 0 Client

Demo- Add Policy & Client Cert Server Wan Em Active Router 0 [P 1 s, A 1] Wan Em Active Router 1 [P 1 s, C 0] Client 0 Client

Demo- Video to Client Server Wan Em Active Router 0 [P 1 s, A 1] Wan Em Active Router 1 [P 1 s, C 0] Client 0 Client

Demo- Revocation Server Wan Em Active Router 0 [P 1 s, A 1] Wan Em Active Router 1 [P 1 s, C 0] Client 0 Client

Demo- Change Policy ACL Server Wan Em Active Router 0 [P 1 s, A 1] Wan Em Active Router 1 [P 2 s, C 0] Client 0 Client

Demo- Invalid Authorization Server Wan Em Active Router 0 [P 1 s, A 1] Wan Em Active Router 1 [P 2 s, C 0] Client 0 Client

Demo- Stops Video Server Wan Em Active Router 0 [P 1 s, A 1] Wan Em Active Router 1 [P 2 s, C 0] Client 0 Client

Threat and Response Model ü Malicious attacks against active packets, links, nodes, EEs, hosts, security service ü Unauthorized access to Node. OS resources including bandwidth ü Attacks against the confidentiality, privacy and integrity of communication ü Distributed Denial of Service

Seraphim Features ü Access Control Ø Node. OS resources Ø EEs Ø Active Packet Contents using Security Guardian with Dynamic Policy and Active Capability ü ü Security Node. OS API (PAM, GAA, GSS) Qo. S independent Prevention of Do. S Composable/Pluggable Active Security Demonstrable on ANTS, CANES, Flux

Access Control • All accesses to Node. OS resources go through the Security Guardian • Access control policies are written in the context of Policy Framework • Active Capability is used as the carrier of the access control policy

Node. OS Security API EE Authentication Authorization Security Services PAM API GAA API GSS API X. 509, Password-based, Kerberos, SESAME, Etc. Active Capability, Policy. Maker, ACL Etc. JCE, Kerberos, SESAME, Etc. Public Key API X. 509 PKI RFC 2510 Security Guardian Node. OS Dynamic Policy Framework

Demo-CAB (Key Neg) Server Wan Em Active Router 0 Wan Em Attacker Active Router 1 Client 0 Client

Demo-CAB Initialization Server Wan Em Active Router 0 Wan Em Attacker Active Router 1 Client 0 Client

Demo Bandwidth Cert Installed Server Wan Em Active Router 0 CAB{B 1 s} Wan Em Attacker Active Router 1 Client 0 Client

Demo Safe Mode, No Cab Enabled Server Wan Em Active Router 0 CAB{B 1 s} Wan Em Attacker Active Router 1 Client 0 Client

Demo Safe Mode, Video Server Wan Em Active Router 0 CAB{B 1 s} Wan Em Attacker Active Router 1 Client 0 Client

Demo Safe Mode, Attack Server Wan Em Active Router 0 CAB{B 1 s} Wan Em Attacker Active Router 1 Client 0 Video Degrades Client

Demo Enabled CAB Mode, Attack Server Wan Em Active Router 0 CAB{B 1 s} Wan Em Attacker Active Router 1 Client 0 Client

Demo Enabled CAB Mode, Attack Server Wan Em Active Router 0 CAB{B 1 s} Wan Em Active Router 1 Client 0 Client Attack defeated – Video Improves Wan Em Attacker

DDOS Prevention • BARMAN – Bandwidth Authorization and Resource Management in Active Networks • Dynamic protocol solution – triggered by bandwidth flooding – – Threshold value based on processor and link characteristics Bandwidth Certification for Attack Detection Hierarchical traceback with dynamic accounting state Co-operative dynamic recovery using active filtering

Threshold Computation • Static Phase of Protocol • Threshold Value – Computed by trusted entity e. g. , administrator – Packet rate that can be safely processed by receiver (server or active router) without getting DOSed – Accommodate emergency control channel • Secure Session Establishment

Bandwidth Certification • Dynamic Phase of Protocol – Triggered by Threshold violation • Sender certifies hop-to-hop bandwidth – Certificate for Authorization of Bandwidth : Small fixed length certificate, fixed options, cryptographic protection using fast encryption or hardware. – Prevents link spoofing, man-in-the-middle and replay attacks – Layered authentication technique

Demo Contributions • Access control for the CANES signaling mechanism • Dynamic control of AER flows • Prevention of bandwidth clogging DDo. S attacks

Wrapup

Personnel • Georgia Tech – Matt Sanders, Shashidar Merugu, Sridhar Srinivasan, Ellen Zegura • SRI – Peter Olveczky, Jose Meseguer • Stanford – Carolyn Talcott • TASC – Mark Keaton, Diane Kiwior, Steve Zabele • University of Illinois – Zhaoyu Liu, Prasad Naldurg, Roy Campbell, Denny Mickunas • University of Kentucky – Srinivasan Venkatraman, Ken Calvert • University of Massachusetts – Sneha Kasera, Supratik Bhattacharrya, Jim Kurose, Don Towsley,

Lessons • Timer-driven activity is as important as packet-arrival driven activity • Node. OS/EE interface was a natural place to incorporate (some) security • Integration via bilateral interfaces is manageable; anything more complicated is iffy • Java and C don’t play together well • Active networking greatly increases the number of potential trouble spots for the application (vs. end-system-only solutions) • Adding performance monitoring to Bowman/CANEs was straightforward (and in some cases even elegant) • Formal analysis effective at finding errors in protocol specifications • Networking is hard to demonstrate

Bowman/CANEs Demo Benefits • Robustness! • Added capabilities – “Heavyweight” timers – Security checks on Node. OS calls – Performance monitoring capability