Secure and Reliable Multicast Video Distribution

1
Secure and Reliable MulticastVideo Distribution

• Team 4
• Active Networks Demonstrations
• 8 December 2000

2
Team Four Composition
3
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

4
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

5
Team 4 Demonstration Configuration
6
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)

7
Highlight 1 Active Reliable Multicast
AER Reliable Multicast
Maude
UMass/TASC
CANEs EE
Security Guardian
Bowman NodeOS
Barman
8
Active Multicast Repair Services
Active Packet
Traditional Error Recovery (TCP)
Active Error Recovery (AER)
Sender
Conventional Routers
Retransmitted message
Active Routers
Active Node
Link causing loss of original message
Active Packet
Lost message retransmission request
Loss detected by nearest router downstream from
loss
Message retransmitted by nearest router upstream
from loss
Receiver
Repair latency is a complete round trip time
Repair latency much less than one round trip
Base premise Active Networking can significantly
improve latency, efficiency, and scalability of
transport protocols
9
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

10
Demo Performance Indicators
Total AER Packets Received
Short-term average goodput in packets/sec
Short-term average of error recovery ratio -gt
dropped packets recovered / dropped
packets detected
Short-term average delay in packet recovery
11
AER Demo Semi-reliable Multicast
Multicast MPEG-2 Video Client
Multicast MPEG-2 Video Client
Video Server (Multicast)
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
12
AER Demo Enhanced Reliable Transport
Unicast MPEG-2 Video Client
Unicast MPEG-2 Video Client
Video Server (Unicast)
Emulated bottleneck link
With repair servers inactive, dropped packets
repaired by video server - increased latency
delays playout
With repair servers active, dropped packets
repaired locally - decreased latency speeds
playout
13
Highlight 2 Maude Analysis of AER/NCA
Reliable Multicast
Maude
SRI/Stanford
CANEs EE
Security Guardian
Bowman NodeOS
Barman
14
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

15
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

16
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

17
The Real-Time Maude Tool

• Supports distributed object-oriented formal of
  network protocols by rewrite rules of the form
• S S if cond
• S 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

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

19
Configuration for analysis
sender
a
c
b
rcvr
d
e
rcvr
g
f
rcvr
rcvr
20
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.

21
Analysis of the Repair Service Component --
Result1

• Using symbolic simulation a deadlock is uncovered
• Maudegt ( rew- 3000 Rstate . )
• result ClockedSystem ERROR in time 17841
  

22
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

23
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

24
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.
• Maudegt ...
• result ClockedSystem
• lteNOMreceiverAloneisNomieefalse,...gt
  ltaNOMreceiverAlonecsmNomieee,...
  gt
• ...
• in time 19504

25
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.
26
Highlight 3 CANEs/Bowman
Reliable Multicast
Maude
CANEs EE
GT/UKy
Security Guardian
Bowman NodeOS
Barman
27
Bowman NodeOS
admin flows
virtual topos
signaling
code fetch
channels
state-store
a-flows
Bowman
timers
security
Host OS
28
CANEs EE model
generic processing function
predefined slots
customizing code
outgoing channels
incoming channels
29
Walkthrough
receiver0
source0
R0
S0
activenode1
activenode0
A1
A0
WAN emulators
R1
S1
receiver1
source1
30
Step 1 Configure virtual topos
R0
virtual topos
S0
A1
A0
cockpit
R1
management station
S1
one unicast, bidirectional topology multiple
unidirectional multicast topologies (e.g.,
(S1,R0,R1)
31
Step 2 Send signaling messages
R0
signaling
S0
A0
A1
R1
S1
management station
32
Step 2a Guard signaling calls
signaling a-flow (with undo capabilities)
1sg_hwtInit(certificate,callParams)
Security Guardian
2hwtInit(callParams)
Bowman
33
Step 2b Load code
signaling flow
WU gateway
code fetch flow
40xabcd
3foo.c
1wucf//foo.c
5foo.c
WU code server
2foo.c
SG
code fetch module
Bowman
34
Step 2c Instantiate a-flows
generic forwarding (mcast)
eight a-flows
DATA
lookuproute ip_lookup
postprocess
cache_put
CANEs
data pkt postproc
35
Step 3 Transmit data
control pkts/sec
timers set/sec
SPM
DATA
timers cancelled/sec
data pkts/sec
36
Step 4 Check authorization
generic forwarding (mcast)
preprocess
source path msg flow (SPM)
authorize
CANEs
Security Guardian
37
Highlight 4 Security Policy Management
Reliable Multicast
Maude
CANEs EE
Security Guardian
UIUC
Bowman NodeOS
Barman
38
Seraphim Security Guardian BOWMAN/CANES Active
Security for Active Networks

• University of Illinois at Urbana-Champaign

39
Demo-A0 knows A1 Cert
Server
Server
Wan Em
Wan Em
Active Router 0
, A1
Wan Em
Active Router 1
,
Client0
Client
40
Demo- Video Flow Starts
Server
Server
Wan Em
Wan Em
Active Router 0
, A1
Wan Em
Active Router 1
,
Client0
Client
41
Demo- Policy Installed
Server
Server
Wan Em
Wan Em
Active Router 0
P1s, A1
Wan Em
Active Router 1
,
Client0
Client
42
Demo- Video Flows
Server
Server
Wan Em
Wan Em
Active Router 0
P1s, A1
Wan Em
Active Router 1
,
Client0
Client
43
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
44
Demo- Video to Client
Server
Server
Wan Em
Wan Em
Active Router 0
P1s, A1
Wan Em
Active Router 1
P1s, C0
Client0
Client
45
Demo- Revocation
Server
Server
Wan Em
Wan Em
Active Router 0
P1s, A1
Wan Em
Active Router 1
P1s, C0
Client0
Client
46
Demo- Change Policy ACL
Server
Server
Wan Em
Wan Em
Active Router 0
P1s, A1
Wan Em
Active Router 1
P2s, C0
Client0
Client
47
Demo- Invalid Authorization
Server
Server
Wan Em
Wan Em
Active Router 0
P1s, A1
Wan Em
Active Router 1
P2s, C0
Client0
Client
48
Demo- Stops Video
Server
Server
Wan Em
Wan Em
Active Router 0
P1s, A1
Wan Em
Active Router 1
P2s, C0
Client0
Client
49
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

50
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

51
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

52
NodeOS Security API
EE
Authentication
Authorization
Security Services
GAA API
PAM API
GSS API
X.509, Password-based, Kerberos, SESAME, Etc.
Active Capability, PolicyMaker, ACL Etc.
JCE, Kerberos, SESAME, Etc.
Public Key API
Security Guardian
X.509 PKI
NodeOS
Dynamic Policy Framework
RFC 2510
53
Demo-CAB (Key Neg)
Server
Server
Wan Em
Wan Em
Active Router 0
Attacker
Wan Em
Active Router 1
Client0
Client
54
Demo-CAB Initialization
Server
Server
Wan Em
Wan Em
Active Router 0
Attacker
Wan Em
Active Router 1
Client0
Client
55
Demo Bandwidth Cert Installed
Server
Server
Wan Em
Wan Em
Active Router 0
CABB1s
Attacker
Wan Em
Active Router 1
Client0
Client
56
Demo Safe Mode, No Cab Enabled
Server
Server
Wan Em
Wan Em
Active Router 0
Attacker
CABB1s
Wan Em
Active Router 1
Client0
Client
57
Demo Safe Mode, Video
Server
Server
Wan Em
Wan Em
Active Router 0
Attacker
CABB1s
Wan Em
Active Router 1
Client0
Client
58
Demo Safe Mode, Attack
Server
Server
Wan Em
Wan Em
Active Router 0
Attacker
CABB1s
Wan Em
Active Router 1
Client0
Client
Video Degrades
59
Demo Enabled CAB Mode, Attack
Server
Server
Wan Em
Wan Em
Active Router 0
Attacker
CABB1s
Wan Em
Active Router 1
Client0
Client
60
Demo Enabled CAB Mode, Attack
Server
Server
Wan Em
Wan Em
Active Router 0
Attacker
CABB1s
Wan Em
Active Router 1
Client0
Client
Attack defeated Video Improves
61
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

62
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

63
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

64
Demo Contributions

• Access control for the CANES signaling mechanism
• Dynamic control of AER flows
• Prevention of bandwidth clogging DDoS attacks

65
Wrapup
66
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,

67
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 dont 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

68
Bowman/CANEs Demo Benefits

• Robustness!
• Added capabilities
• Heavyweight timers
• Security checks on NodeOS calls
• Performance monitoring capability