Secure and Reliable Multicast Video Distribution Team 4 Active Networks Demonstrations 8 December 2000
Jan 02, 2016
Secure and Reliable MulticastVideo Distribution
Team 4Active Networks Demonstrations
8 December 2000
Team Four Composition
Wash U code
server
AER Reliable MulticastUMass/TASC
SRI/Stanford
Maude
NISTNet WANEmulator
CANEs EEGT/UKy
Bowman NodeOSBarman
Security GuardianUIUC
Barman
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 NodeOS
Team 4 Demonstration Configuration
AER/NCA Send Applications (Sun Ultra 5s/Solaris)
NIST Net WAN Emulators (200 MHz Pentium Pros/LINUX)
CANEs Active Node (Dual Processor Sun Ultra 2/Solaris)
CANEs Active Node (Dual Processor Sun Ultra 2/Solaris)
NIST Net WAN Emulator (733 MHz Pentium III/LINUX)
AER/NCA Receive Apps (Windows NT with HW MPEG2 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
AER Reliable MulticastUMass/TASCMaude
CANEs EE
Bowman NodeOS
Security Guardian
Barman
Active Multicast Repair Services
Receiver
SenderConventional Routers
Repair latency is a complete round trip time
Link causing loss of original
message
Lost message retransmission
request
Retransmitted message
Traditional Error Recovery (TCP)
Base premise:Active Networking can significantly improve latency, efficiency, and scalability of transport protocols
Repair latency much less than one round trip
Loss detected by nearest router
downstream from lossMessage retransmitted
by nearest router upstream from loss
Active Error Recovery (AER)
Active Packet ‘
Active Node
Active Routers
Active Packet
AER/NCA
AER Repair Servers (RSs)• Co-located with routers
AER loss handling:• Rcvrs and RSs unicast NAKs • RSs subcast NAKs one level
downstream • subcast repairs, NAK supression
NCA• Estimating worst receiver• TCP friendliness• Decoupled from AER
SenderSender
Repair ServersRepair Servers
RoutersRouters
ReceiversReceivers
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
With repair servers active, dropped packet repaired before playout time: quality improved
With repair servers inactive, dropped
packets not repaired before playout time:
quality suffers
Video Server (Multicast)
Emulated bottleneck
link
Multicast MPEG-2 Video Client Multicast MPEG-2 Video Client
Highlight 2: Maude Analysis of AER/NCA
SRI/Stanford
Reliable MulticastMaude
CANEs EE
Bowman NodeOS
Security Guardian
Barman
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 state-transition 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 formS S’ if condS 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
a
b c
d e
f g
sender
rcvr
rcvr
rcvr
rcvr
Analysis of the Repair ServiceComponent -- 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 -- Result1
• Using symbolic simulation a deadlock is uncovered
Maude> ( rew- [3000] Rstate . )
result ClockedSystem: {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 ClockedSystem:
{ <‘e:NOMreceiverAlone|isNomiee:false,...> <‘a:NOMreceiverAlone|csmNomiee:’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 MulticastMaude
CANEs EE
Bowman NodeOS
GT/UKy
Security Guardian
Barman
Bowman NodeOS
signaling code fetch
admin flows
virtual topos
Bowmanchannels state-store a-flows
timers
Host OS
security
CANEs EE model
incoming channels
customizing code
outgoing channels
predefined slots
genericprocessing
function
Walkthrough
A1
activenode0 activenode1
receiver0
receiver1
R1
R0
source0
source1
S1
S0
A0WAN emulators
Step 1: Configure virtual topos
A1
R1
R0
S1
S0 virtual topos
A0
cockpit
one unicast, bidirectional topologymultiple unidirectional multicast topologies (e.g., (S1,{R0,R1})
managementstation
Step 2: Send signaling messages
A0 A1
R1
R0
S1
S0 signaling
managementstation
Step 2a: Guard signaling calls
1:sg_hwtInit(certificate,callParams)
2:hwtInit(callParams)
signaling a-flow (with “undo” capabilities)
SecurityGuardian
Bowman
Step 2b: Load code
signalingflow code fetch
flow
Bowmancode fetch
module
WU codeserver
1:wucf:://foo.c
2:foo.c 5:foo.c
3:foo.c
SG
WUgateway
4:0xabcd
Step 2c: Instantiate a-flows
lookuproute: ip_lookup
generic forwarding (mcast)
cache_put
data pkt postproc
postprocess
CANEs
eight a-flows
DATA
Step 3: Transmit data
timers set/sec
timers cancelled/sec
control pkts/sec
data pkts/sec
SPMDATA
Step 4: Check authorization
generic forwarding (mcast)
CANEs
source path msg flow(SPM)
preprocess
SecurityGuardian
authorize
Highlight 4: Security Policy Management
Reliable MulticastMaude
CANEs EE
Bowman NodeOS
Security GuardianUIUC
Barman
Seraphim Security Guardian BOWMAN/CANES: Active Security for Active Networks
University of Illinois at Urbana-Champaign
Demo-A0 knows A1 Cert
Server Server
Client0 Client
Wan Em Wan Em
Wan Em
Active Router 0
Active Router 1
[, A1]
[,]
Demo- Video Flow Starts
Server Server
Client0 Client
Wan Em Wan Em
Wan Em
Active Router 0
Active Router 1
[, A1]
[,]
Demo- Policy Installed
Server Server
Client0 Client
Wan Em Wan Em
Wan Em
Active Router 0
Active Router 1
[P1s, A1]
[,]
Demo- Video Flows
Server Server
Client0 Client
Wan Em Wan Em
Wan Em
Active Router 0
Active Router 1
[P1s, A1]
[,]
Demo- Add Policy & Client Cert
Server Server
Client0 Client
Wan Em Wan Em
Wan Em
Active Router 0
Active Router 1
[P1s, A1]
[P1s, C0]
Demo- Video to Client
Server Server
Client0 Client
Wan Em Wan Em
Wan Em
Active Router 0
Active Router 1
[P1s, A1]
[P1s, C0]
Demo- Revocation
Server Server
Client0 Client
Wan Em Wan Em
Wan Em
Active Router 0
Active Router 1
[P1s, A1]
[P1s, C0]
Demo- Change Policy ACL
Server Server
Client0 Client
Wan Em Wan Em
Wan Em
Active Router 0
Active Router 1
[P1s, A1]
[P2s, C0]
Demo- Invalid Authorization
Server Server
Client0 Client
Wan Em Wan Em
Wan Em
Active Router 0
Active Router 1
[P1s, A1]
[P2s, C0]
Demo- Stops Video
Server Server
Client0 Client
Wan Em Wan Em
Wan Em
Active Router 0
Active Router 1
[P1s, A1]
[P2s, C0]
Threat and Response Model
Malicious attacks against active packets, links, nodes, EEs, hosts, security service
Unauthorized access to NodeOS resources including bandwidth
Attacks against the confidentiality, privacy and integrity of communication
Distributed Denial of Service
Seraphim Features
Access Control NodeOS resources EEs Active Packet Contents using Security Guardian with Dynamic Policy and
Active Capability Security NodeOS API (PAM,GAA,GSS) QoS independent Prevention of DoS Composable/Pluggable Active Security Demonstrable on ANTS, CANES, Flux
Access Control
• All accesses to NodeOS 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
NodeOS Security API
NodeOS
EE
Authentication AuthorizationSecurity Services
PAM API GAA API GSS API
X.509,Password-based,
Kerberos,SESAME,
Etc.
Active Capability,PolicyMaker,
ACLEtc.
JCE,Kerberos,SESAME,
Etc.
Public Key API
Security Guardian
Dynamic PolicyFramework
X.509 PKIRFC 2510
Demo-CAB (Key Neg)
Server Server
Client0 Client
Attacker
Wan Em Wan Em
Wan Em
Active Router 0
Active Router 1
Demo-CAB Initialization
Server Server
Client0 Client
Attacker
Wan Em Wan Em
Wan Em
Active Router 0
Active Router 1
Demo Bandwidth Cert Installed
Server Server
Client0 Client
Attacker
Wan Em Wan Em
Wan Em
Active Router 0
Active Router 1
CAB{B1s}
Demo Safe Mode, No Cab Enabled
Server Server
Client0 Client
Attacker
Wan Em Wan Em
Wan Em
Active Router 0
Active Router 1
CAB{B1s}
Demo Safe Mode, Video
Server Server
Client0 Client
Attacker
Wan Em Wan Em
Wan Em
Active Router 0
Active Router 1
CAB{B1s}
Demo Safe Mode, Attack
Server Server
Client0 Client
Attacker
Wan Em Wan Em
Wan Em
Active Router 0
Active Router 1
CAB{B1s}
Video Degrades
Demo Enabled CAB Mode, Attack
Server Server
Client0 Client
Attacker
Wan Em Wan Em
Wan Em
Active Router 0
Active Router 1
CAB{B1s}
Demo Enabled CAB Mode, Attack
Server Server
Client0 Client
Attacker
Wan Em Wan Em
Wan Em
Active Router 0
Active Router 1
CAB{B1s}
Attack defeated – Video Improves
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 DDoS
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• NodeOS/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 NodeOS calls– Performance monitoring capability