Comparison of Some Reachability Control Architectures: Off-by-Default, SANE, and UReCA

1. Comparison of SomeReachability Control Architectures:Off-by-Default, SANE, and UReCA Routing Security Reading Group Aug 1, 2006 Chang Kim

2. Reachability Control? • Routing decides howto 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 Framework • Expression, 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 Off-by-default • 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

7. Router FIB Rechability entries for P Prefix (P ) Next Hop P’ RC0 Filter RC1 Filter … … Encoding and Enforcement Off-by-default • 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

8. Feasibility Off-by-default • Number of prefixes, P = 200,000, Number of permitted hosts per AS, H = 45 • Model-1: customer prefix aggregation allowed • Model-2: customer prefix aggregation disallowed • (For both models, non-customer prefixes are aggregated before customer prefixes)

9. Criticism Off-by-default • 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?

10. Case-II: SANE • Secure Architecture for Networked Enterprise • “All routing and access control decisions are made by a centralized server byhanding 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. S2 S3 B data B data S1 S2 S3 B data S3 B data Ethernet hdr SANE hdr IP hdr Data Service Model SANE 2) Request capability to B.http DC 1) Publish B.http Allow A access 0) Authenticate with DC 0) Authenticate with DC Switch 1 Switch 3 Client A 3) Use returned capability to communicate with B Server B Switch 2 data

12. Some Mechanics – 1. SANE • 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 HELLO Payload DC Request Capability Authenticator Payload FORWARD Cap-Id Cap-Exp Capability Payload REVOKE Cap-Id Cap-Exp SignatureDC

13. Some Mechanics – 2. SANE • 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

14. Criticism SANE • 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. • Inaptrecovery 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

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.” 0) Policy and topology description RCS 3) Policy look-up 4) FER Reachability Control Server 2) FEQ Router E Router C 1) Arrival of a new kind of packet Router A • Permit 5) Filterenforcement • Deny Router D Router B

16. Design Decisions UReCA • Unified 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

17. Deny P Interface-level Packet Handling UReCA Router R receives packet P match Evaluate existing filterswith P no-match Has R receivedand denied packets with the same 5-tuple as Pbefore? yes no R asks RCS whetherto install a filter regarding P Should R installa filter regarding P? yes no Install the filter (The filter may eitherbe permit or deny) Mark Hash(P) on the hash table Forward or deny Paccording to the newly installed filter Forward or deny Paccording to the matched rule

18. Mechanics UReCA • 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

19. Advantages UReCA • 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

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!