Comparison of SomeReachability Control

Architectures:Off-by-Default, SANE, and UReCA

Routing Security Reading Group

Aug 1, 2006Chang Kim

2

Reachability Control?

Routing decides how to deliver packets, whereas …

reachability dictates whether to deliver packets.

A reachability control architecture defines how to Express Encode Disseminate and Enforce

reachability constraints.

3

Conventional Framework

Packet filters, a.k.a. Access Lists (ACLs) L2-4 inspection Stateless

Firewalls L2-7 inspection Statefull Network-based (installed at some vantage points)

vs. distributed, host-based

Misc. Null routing, VLAN, middle-boxes, etc.

A Kind of Reachability Control Architecture?

Expression: Managers describe reachability policy in human languages

Encoding: Human languages, Custom encodings, etc. Dissemination: Email, Off-line delivery, etc. Enforcement: Manual configuring packer filters or firewall rule sets at some contrived points

4

Problems of Conventional FrameworkExpression, encoding, and dissemination mechanisms

missing!

Control and mgmt. plane support is absent Operators directly configure data plane Labor-intensive, error-prone, and sub-optimal

Network-wise intention, local implementation Devoid of unified, high-level policy description

Inadequate self-adjustment to network dynamics Manual adaptation to topology and routing changes Traffic-agnostic operation

5

Case-I: Off by default!

“Traffic must be permitted only when its recipient explicitly informsnetwork of its willingness to accept the traffic.”

Design Decisions Discard unless permitted Proactive deployment, not on-demand Recipient hosts signals explicit permission to routers Permissions disseminated along with route advertisements

Destination prefix-based permission management Permissions encoded using Bloom filters

Best-effort filtering due to false positives Scalability measures

Permission aggregation and reverse path signaling for “off” hosts

Applicable to both inter- and intra-domain settings

6

Expression and Dissemination

Three Kinds of Reachability Constraints (RCs) RC0: permit for any sources

dst IP addr, protocol, and port RC1: permit for certain sources

src IP addrs, dst IP addr, protocol, and port RC2: deny for certain sources (selective off)

src IP addrs, dst IP addr, protocol, and port

Reachability Expression[ prefix, prefix-length, {RC, RC, …}, scope ]

Reachability Dissemination Routers periodically and incrementally exchange

reachability state

Off-by-default

7

Encoding and Enforcement

Bloom Filter Encoding Useful for efficient dissemination and enforcement False positives

Progressively better protection as packets come closer to a dst

FIB Structure for Filtering

Trading Accuracy for Memory Saving Prefix aggregation Filter aggregation

Prefix (P )

…

Next Hop

Router FIB

P’

Rechability entries for P

RC0 Filter RC1 Filter

…

Off-by-default

8

FeasibilityNumber of prefixes, P = 200,000, Number of permitted hosts per AS, H = 45

Model-1: customer prefix aggregation allowedModel-2: customer prefix aggregation disallowed

(For both models, non-customer prefixes are aggregated before customer prefixes)

Off-by-default

9

Criticism

Tightly coupled with routing Not every reachability constraint can be tied with a destination

prefix,e.g. anti-spoofing policies

Best-effort filtering It might satisfy net operators; might it be able to satisfy end users

as well?

Threat to the proposed infrastructure Not enough concern on misbehaving entities

Permission withdrawal Intrinsic defect of Bloom filters

Insufficient expressibility Hard to specify customized reachability constraints

Weak host mechanisms How hosts decide on their reachability?

Off-by-default

10

Case-II: SANE

Secure Architecture for Networked Enterprise

“All routing and access control decisions are made by a centralized server by handing out capabilities according to policies published by recipients.”

Design Decisions Targeting enterprises and campuses Clean-slate redesign for hard security (strong protection)

Introduce a new protection layer beneath IP Reachability policy described and exported by recipients Capability-based control

Append encrypted source routes to every packet The Brain: Domain Controller (DC)

Authentication, directory service, reachability policy management, reachability control, routing decision, topology monitoring, etc.

Some interoperability and compatibility mechanisms

11

Service ModelSANE

0) Authenticate with DC

Switch 2

1) Publish B.http Allow A access

Server B

Client A

Switch 1

DC

Switch 3

0) Authenticate with DC

2) Request capability to B.http

3) Use returned capability to communicate with B S1 S2 S3 dataB

S2 S3 dataB

S3 dataB

dataB

data

Ethernet hdrSANE hdr IP hdr Data

12

Some Mechanics – 1.Packet Types

A New, Switch-based Control Plane Substitute for conventional L2 and L3 control planes Spanning tree protocol for routing toward DC Link-state protocol for topology discovery Capability-based point-to-point communication protocol

Minimizing Cryptographic Overhead Public keys for authentication Symmetric keys for capability manipulation

SANE

HELLO Payload

DC Request Capability

FORWARD Cap-Id

REVOKE

Authenticator Payload

Cap-Exp Capability Payload

Cap-Id Cap-Exp SignatureDC

13

Some Mechanics – 2.

Revoking Capabilities Recipients or intermediate switches can request revocation

to DC Revocation packets are processed upstream DC’s signature vouches for revocations

Additional Attack Resistance Mechanisms Tolerating resource exhaustion

Data/request flooding: Rate limiting Revocation flooding: Key renewal (@switch) and rate limiting

(@DC) Tolerating malicious entity

Malicious switches: End hosts-based probing, etc. Malicious DC: Multiple DCs with threshold cryptography and

Byzantine agreement protocols

SANE

14

Criticism

Heavy and complex Authentication load Reverse-path signaling for “off” hosts Resource tax for short-lived flows Attack resistance mechanisms too complicated

Poor backward compatibility Hard to replace all conventional IP-based service mechanisms;

e.g., some pervasive services, such as DNS, L2 broadcast, etc.

Inapt recovery mechanisms from network failures Hosts are responsible for determining failures; probing required Potential request flooding upon a failure Use of multiple paths may be an option, but clumsy

Incoherent layering: Duplication and inefficiency Service identifiers (equivalent to port numbers) included at SANE headers

SANE

15

Case-III: UReCA

A Unified Reachability Control Architecture for enterprise networks

“Packet filters are triggered by data traffic and enforced by a centralized server according to network-wise

reachability policies.”

2) FEQ

4) FER3) Policy look-up

1) Arrival of a new kind of packet

5) Filterenforcement

PermitRouter A

Router ERouter C

Router DRouter B

0) Policy and topology description

ReachabilityControl Server

Deny

RCS

16

Design DecisionsUnified policy description

High-level policy description framework, e.g. KeyNote, Firmato

Packet filters as a measure High customizability Non-prefix-based reachability management Default-off (permits are explicitly configured)

Ingress filtering Obviates the need to understand routing dynamics Stronger security than internal link filtering

Demand-based filter enforcement Keeps the number of filter clauses minimum Natural support for usage-based filter optimization

Aging out dormant filters, usage-based reordering,early evaluation of default deny, default proxy, etc.

Infrastructure protection

UReCA

17

Interface-level Packet HandlingUReCA

Evaluate existing filterswith P

Router R receives packet P

Has R receivedand denied packets with

the same 5-tuple as Pbefore?

yes

no

match

no-match

R asks RCS whetherto install a filter regarding P

no

Mark Hash(P) on the hash table

yes

Forward or deny Paccording to the matched rule

Deny P

Should R installa filter regarding P?

Install the filter(The filter may either

be permit or deny)

Forward or deny Paccording to the newly installed filter

18

Mechanics

Keeping filtering history Keeping permit history with corresponding filter rules Keeping default denial history using Bloom filters

(or multi-stage hashing) False positives: dropping a legitimate, unprecedented type of

packets Can be contained by engineering hash parameters and

periodic flushing

Infrastructure protection Assumes that a DOS incidence and legitimate FEQs rarely

coincide RCS protection by rate limiting FEQs per router Router protection by rate limiting FEQs per MAC

UReCA

19

Advantages

Minimizes incorrect or sub-optimal filter configuration By unified policy description and automated translation

Simple Operators don’t need to maintain configuration details Very simple, stateless dissemination protocol

Makes ingress filtering “affordable” By avoiding manual configuration process By demand-based filter enforcement

Reduces routers’ operational load By usage-based filter optimization

Provides network-wise view on filtering status Centralized logging Proactive filter installation for attack prevention

UReCA

20

Conclusion

Reviewed what a reachability control architectures should do and behave

Compared Off-by-default, SANE, and UReCA

Welcome criticism and suggestions on UReCA!