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 NodeOS
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 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)
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 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
UMass/TASC
AER Reliable Multicast
CANEs EE
Security Guardian
Barman
Bowman NodeOS
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
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 NodeOS
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
-- 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 Multicast
CANEs EE
GT/UKy
Security Guardian
Barman
Bowman NodeOS
Maude
Bowman NodeOS
admin flows
signaling
Bowman
channels
virtual
topos code fetch
state-store a-flows
security
timers
Host OS
CANEs EE model
predefined slots
generic
processing
function
customizing
code
incoming channels
outgoing channels
Walkthrough
receiver0
source0
R0
S0
activenode0
WAN emulators
S1
source1
A0
activenode1
A1
R1
receiver1
Step 1: Configure virtual topos
S0
virtual topos
A0
S1
R0
A1
cockpit
management
station
R1
one unicast, bidirectional topology
multiple unidirectional multicast topologies (e.g., (S1,{R0,R1})
Step 2: Send signaling messages
S0
signaling
A0
S1
R0
A1
management
station
R1
Step 2a: Guard signaling calls
signaling a-flow (with “undo” capabilities)
1:sg_hwtInit(certificate,callParams)
Security
Guardian
2:hwtInit(callParams)
Bowman
Step 2b: Load code
signaling
flow
code fetch
flow
WU
gateway
4:0xabcd
3:foo.c
1:wucf:://foo.c
SG
code fetch
module
2:foo.c
5:foo.c
Bowman
WU code
server
Step 2c: Instantiate a-flows
generic forwarding (mcast)
eight a-flows
DATA
lookuproute: ip_lookup
postprocess
CANEs
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 NodeOS
Maude
Seraphim Security Guardian BOWMAN/CANES:
Active Security for Active Networks
University of Illinois at Urbana-Champaign
Demo-A0 knows A1 Cert
Server
Server
Wan Em
Wan Em
Active Router 0
[, A1]
Wan Em
Active Router 1
[,]
Client0
Client
Demo- Video Flow Starts
Server
Server
Wan Em
Wan Em
Active Router 0
[, A1]
Wan Em
Active Router 1
[,]
Client0
Client
Demo- Policy Installed
Server
Server
Wan Em
Wan Em
Active Router 0
[P1s, A1]
Wan Em
Active Router 1
[,]
Client0
Client
Demo- Video Flows
Server
Server
Wan Em
Wan Em
Active Router 0
[P1s, A1]
Wan Em
Active Router 1
[,]
Client0
Client
Demo- Add Policy & Client Cert
Server
Server
Wan Em
Wan Em
Active Router 0
[P1s, A1]
Wan Em
Active Router 1
[P1s, C0]
Client0
Client
Demo- Video to Client
Server
Server
Wan Em
Wan Em
Active Router 0
[P1s, A1]
Wan Em
Active Router 1
[P1s, C0]
Client0
Client
Demo- Revocation
Server
Server
Wan Em
Wan Em
Active Router 0
[P1s, A1]
Wan Em
Active Router 1
[P1s, C0]
Client0
Client
Demo- Change Policy ACL
Server
Server
Wan Em
Wan Em
Active Router 0
[P1s, A1]
Wan Em
Active Router 1
[P2s, C0]
Client0
Client
Demo- Invalid Authorization
Server
Server
Wan Em
Wan Em
Active Router 0
[P1s, A1]
Wan Em
Active Router 1
[P2s, C0]
Client0
Client
Demo- Stops Video
Server
Server
Wan Em
Wan Em
Active Router 0
[P1s, A1]
Wan Em
Active Router 1
[P2s, C0]
Client0
Client
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
EE
Authentication
PAM API
GAA API
GSS API
X.509,
Password-based,
Kerberos,
SESAME,
Etc.
Active Capability,
PolicyMaker,
ACL
Etc.
JCE,
Kerberos,
SESAME,
Etc.
Public Key API
X.509 PKI
RFC 2510
Authorization Security Services
Security Guardian
NodeOS
Dynamic Policy
Framework
Demo-CAB (Key Neg)
Server
Server
Wan Em
Wan Em
Active Router 0
Wan Em
Attacker
Active Router 1
Client0
Client
Demo-CAB Initialization
Server
Server
Wan Em
Wan Em
Active Router 0
Wan Em
Attacker
Active Router 1
Client0
Client
Demo Bandwidth Cert Installed
Server
Server
Wan Em
Wan Em
Active Router 0
CAB{B1s}
Wan Em
Attacker
Active Router 1
Client0
Client
Demo Safe Mode, No Cab Enabled
Server
Server
Wan Em
Wan Em
Active Router 0
CAB{B1s}
Wan Em
Attacker
Active Router 1
Client0
Client
Demo Safe Mode, Video
Server
Server
Wan Em
Wan Em
Active Router 0
CAB{B1s}
Wan Em
Attacker
Active Router 1
Client0
Client
Demo Safe Mode, Attack
Server
Server
Wan Em
Wan Em
Active Router 0
CAB{B1s}
Wan Em
Attacker
Active Router 1
Client0
Video Degrades
Client
Demo Enabled CAB Mode, Attack
Server
Server
Wan Em
Wan Em
Active Router 0
CAB{B1s}
Wan Em
Attacker
Active Router 1
Client0
Client
Demo Enabled CAB Mode, Attack
Server
Server
Wan Em
Active Router 0
CAB{B1s}
Wan Em
Active Router 1
Client0
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 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