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

2. Nuggets of Wisdom for Accountability 07/21/09 Speaker : Yun Liaw 1 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

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

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

5. Trapdoor Hash Functions 07/21/09 Speaker : Yun Liaw 4 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

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

7. Using Trapdoor Hash Functions for Identity Spoofing Elimination 07/21/09 Speaker : Yun Liaw 6 3. 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+SEQ p. The packet’s signature is r 4. Verifiers check the packet’s signature by calculating the hash over (m, r)

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

9. Scalability and Cost 07/21/09 Speaker : Yun Liaw 8 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

10. Key Management 07/21/09 Speaker : Yun Liaw 9 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

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

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

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 07/21/09 Speaker : Yun Liaw 12

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 07/21/09 Speaker : Yun Liaw 13

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 07/21/09 Speaker : Yun Liaw 14

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 07/21/09 Speaker : Yun Liaw 15

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 07/21/09 Speaker : Yun Liaw 16

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

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 07/21/09 Speaker : Yun Liaw 18