Comparison of Some Reachability Control Architectures: Off-by-Default, SANE, and UReCA
description
Transcript of Comparison of Some Reachability Control Architectures: Off-by-Default, SANE, and UReCA
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!