Building Accountability into the Future Internet

1. Building Accountability into the Future Internet JELENA MIRKOVIC (USC) PETER REIHER (UCLA) In Proc. IEEE NPSec, 2009 Speaker: Yun Liaw

2. Nuggets of Wisdom for Accountability • Accountability mandates perfect identification of actors • Identification of sources must be cheap enough to be universal • Traffic filtering should occur as close to the sources as possible • It is desirable that servers can identify malicious clients before having any interaction with them Speaker : Yun Liaw

3. Contribution and Overview • Identify Spoofing Elimination: Lightweight unspoofable signature • Reducing Unwanted Traffic: Capability scheme built on top of unspoofable identities • Client reputation system Speaker : Yun Liaw

4. Identity Spoofing Elimination • Solution: To attach an unspoofable source signature to each packet • Mechanism: Trapdoor hash function with inversion property Speaker : Yun Liaw

5. Trapdoor Hash Functions • Hash key (public key): HK • Trapdoor key (Private key): TK • One-way trapdoor hash function: h( ) • Cheap to compute h(x) by knowing HK • Collision free • If TK is known, it is easy to find collision Speaker : Yun Liaw

6. Using Trapdoor Hash Functions for Identity Spoofing Elimination • Source publishes HK and the verification token V. And also enumerates sending packets with an increasing sequence number. • Verifiers store HK and V to verify the source. And also keep a short record of sequence numbers to prevent replay attacks Speaker : Yun Liaw

7. Using Trapdoor Hash Functions for Identity Spoofing Elimination • The source use any hash function to compute a hash m over the packets and the sequence number, then use the trapdoor key TK to find r so that h(m,r) = V+SEQp. The packet’s signature is r • Verifiers check the packet’s signature by calculating the hash over (m, r) Speaker : Yun Liaw

8. Using Trapdoor Hash Functions for Identity Spoofing Elimination Source Verifier m: the hash of packet content r: the signature of the packet that can be found by TK Public Key HK, Verification Token V Verifier stores HK, V to perform following verification h(m,r) = V+SEQp Packet, Seq. Number, m, r Verifier use HK to compute if h(m,r) = V+SEQp And check Seq. Number to prevent replay attacks Speaker : Yun Liaw

9. Scalability and Cost • Hierarchical signature scheme • Each host signs its packet by the proposed approach • When the packets leave the source AS, the border router verifies the host-level signature and replaces it by the AS-level signature • In case of some untrusted ASes that do not verify host, the capability scheme could restrict the traffic from these Ases • Header space: total of 256 bits (including “ticket”) • Computing Cost • Signing: 5 modular exponentions • Verification: One hash operation Speaker : Yun Liaw

10. Key Management • Update of V and HK: Once per day via a push from the source to a representative node in the AS • Representative node: A server or router that updates the new key information to all other routers in the same AS • Bootstrapping Key Exchange for Peering Ases • Use traditional public-key approach for key exchange • ASes exchange the public key using out-of-band communication as they establish a peering relation Speaker : Yun Liaw

11. Reducing Unwanted Traffic • Destination-Generated Ticket Scheme • Client issues a ticket request with server ticket to a server • Server generates a client ticket T = {sID, sAS, cID, type=‘client’, lastValidTime, Sh) • Sh = sign(sID, sAS, cID, type=‘client’, lastValidTime) • Server’s border router verify Sh and replaces it with AS-level signature • The client attaches T and Sas to each packet • The routers on the path validate the freshness and the ticket T • The validity of ticket should be short-lived – expected for several seconds Speaker : Yun Liaw

12. Building Client Reputations • Client-based reputation system: Be used for servers to issue ticket • Whether the ticket should be issued • To prioritize the ticket request handling Speaker : Yun Liaw

13. Client-Based Reputation System • The system collects reports from servers about client who have misbehaved • The report contains client’s identity and the context of the misbehavior • Example: Worm traffic with a rate of x scans to port y per second • Each report need to be accompanied with a traffic sample for proving the report context • The report from a server must be authenticated • The client that was a object of a bad report should be notified by the system • The system would aggregate the report into a reputation score Speaker : Yun Liaw

14. Client-Based Reputation System • Short-term reputation system • Giving a higher weight to recent reports and discounting old ones • Are used by servers to accept redeemed clients’ traffic during normal operation • Long-term reputation system • Using all reports submitted in a recent and long time interval • Are used during an attack, which leads to dropping of redeemed clients’ traffic Speaker : Yun Liaw

15. Deployment of Reputation System • Peer-to-peer design • Each AS deploys a local reputation center • Reputation centers propagate reports or reputation scores • Compromised reputation center • A center’s peer can monitor its updates and vouch for correct score calculation • A server may need to contact several reputation centers for an update to minimize the risk of lying Speaker : Yun Liaw

16. Deployment of Reputation System • The overhead of reputation system communication • May be large due to large-scale security incident, such as worm attack • A server should aggregate all its report within some interval into a combined report • The distribution of reputation scores • Periodically download by reputation users (server) • Push by center when numerous bad reports indicate a large-scale Internet incident Speaker : Yun Liaw

17. Related Work • Spoofing Elimination • Passport, SPM • Unwanted Traffic Handling • TVA, SIFF: Route-dependent DoS limiting architecture • Routers mark packets on route to destination, if destination accepts the communication, it would return the marks to the source as the “ticket” • Route-dependent architecture is invalid when route changes • Inflict collateral damage when ticket-request flooding • Client Reputations Speaker : Yun Liaw

18. Future Works • Implementation • PKI (for bootstrapping) • Issue of handling packets that come from malicious sources: indemnification system • Algorithms for computing reputation score Speaker : Yun Liaw

19. Comments • This is a conceptual paper which introduce some useful thoughts for enhance accountability • No concrete analysis or system implementation • Still have much issues to breakthrough Speaker : Yun Liaw