jelena mirkovic (usc) peter reiher (ucla) building accountability into the future internet in proc....

JELENA MIRKOVIC (USC)PETER REIHER (UCLA)

Building Accountability into the Future Internet

In Proc. IEEE NPSec, 2009

Speaker: Yun Liaw

Nuggets of Wisdom for Accountability

07/21/09Speaker : Yun Liaw

2

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

Contribution and Overview


3

Identify Spoofing Elimination: Lightweight unspoofable signature

Reducing Unwanted Traffic: Capability scheme built on top of unspoofable identities

Client reputation system

Identity Spoofing Elimination


4

Solution: To attach an unspoofable source signature to each packet

Mechanism: Trapdoor hash function with inversion property

Trapdoor Hash Functions


5

Hash key (public key): HKTrapdoor key (Private key): TKOne-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

Using Trapdoor Hash Functions for Identity Spoofing Elimination


6

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

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+SEQp. The packet’s signature is r

4. Verifiers check the packet’s signature by calculating the hash over (m, r)



8

Source Verifier

Public Key HK, Verification Token V

m: the hash of packet contentr: the signature of the packet that can be found by TK

Packet, Seq. Number, m, rh(m,r) = V+SEQp

Verifier use HK to compute if h(m,r) = V+SEQp

And check Seq. Number to prevent replay attacks

Verifier stores HK, V to perform following verification

Scalability and Cost


9

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

Key Management


10

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

Reducing Unwanted Traffic


11

Destination-Generated Ticket Scheme1. Client issues a ticket request with server ticket to a

server2. Server generates a client ticket T = {sID, sAS, cID,

type=‘client’, lastValidTime, Sh) Sh = sign(sID, sAS, cID, type=‘client’, lastValidTime)

3. Server’s border router verify Sh and replaces it with AS-level signature

4. The client attaches T and Sas to each packet5. The routers on the path validate the freshness and the

ticket T

The validity of ticket should be short-lived – expected for several seconds

Building Client Reputations


12

Client-based reputation system: Be used for servers to issue ticket

Whether the ticket should be issued

To prioritize the ticket request handling

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


13

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


14

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


15

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


16

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


17

Future Works

Implementation

PKI (for bootstrapping)

Issue of handling packets that come from malicious sources: indemnification system

Algorithms for computing reputation score


18

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


19

jelena mirkovic (usc) peter reiher (ucla) building accountability into the future internet in proc....

Documents