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