1. © 2008 Andreas Haeberlen, MPI-SWS 1 Pretty Good Packet Authentication Andreas Haeberlen MPI-SWS / Rice University Rodrigo Rodrigues MPI-SWS Peter Druschel MPI-SWS Krishna Gummadi MPI-SWS

2. 2 © 2008 Andreas Haeberlen, MPI-SWS Packet authentication Internet packets cannot be authenticated Example: Alice receives P, source address X Can Alice be sure that P was sent by the host with address X? (no, addresses can be spoofed!) Can Alice convince a third party that P was sent by this host? (no, packets can be forged!) Alice Bob Foo.net Bar.net Internet Assigns IP address X Packet P (source address X) Admin

3. 3 © 2008 Andreas Haeberlen, MPI-SWS The Internet needs packet authentication The lack of packet authentication is causing a variety of problems, e.g.: Bypassing spam blacklists [SIGCOMM'06] Eve Bar.net Foo.net Innocen t.net Mail server No more mail from bar.net! Innocent.net Internet

4. 4 © 2008 Andreas Haeberlen, MPI-SWS The Internet needs packet authentication The lack of packet authentication is causing a variety of problems, e.g.: Bypassing spam blacklists [SIGCOMM'06] False accusations [HotSec'08] Alice Eve Bar.net Foo.net Innocen t.net Tracker "Hi, I am Alice"

5. 5 © 2008 Andreas Haeberlen, MPI-SWS The Internet needs packet authentication The lack of packet authentication is causing a variety of problems, e.g.: Bypassing spam blacklists [SIGCOMM'06] False accusations [HotSec'08] Unverifiable complaints, plausible deniability Can we add authentication to the Internet? Alice Eve Bar.net Foo.net Admin "Alice has been portscanning me!" ?!?

6. 6 © 2008 Andreas Haeberlen, MPI-SWS Which properties do we want? There is a spectrum of possible solutions Strength vs. other goals (such as privacy) Strength vs. feasibility/practicability Can we find a good compromise? Strong Weak Internet today More ingress filtering Clean-slate designs (e.g. AIP) Crypto+ biometrics Brain scanner PGPA IP traceback Infeasible / too strong Deployment path?

7. 7 © 2008 Andreas Haeberlen, MPI-SWS Proposed solution: PGPA We propose Pretty Good Packet Authentication PGPA provides the following capability: Given a packet, a source address and timestamp, the ISP that owns the source address can verify whether the packet was sent at approximately that time Alice Bob Foo.net Bar.net Internet Address X assigned here Packet (source address X) Judy Has X sent at 4:11pm today? Yes Has X sent at 4:11pm today?

8. 8 © 2008 Andreas Haeberlen, MPI-SWS Privacy and anonymity PGPA protects users' privacy To ask a question about a packet, the requester must already know the entire packet PGPA is compatible with anonymity Standard techniques (such as onion routing) can still be applied Given a packet, a source address and timestamp, the ISP that owns the source address can verify whether the packet was sent at approximately that time

9. 9 © 2008 Andreas Haeberlen, MPI-SWS Outline Introduction Pretty Good Packet Authentication (PGPA) How PGPA could be used A simple implementation Conclusion

10. 10 © 2008 Andreas Haeberlen, MPI-SWS How PGPA could be used PGPA could be used to solve each of the motivating problems: Bypassing spam blacklists Eve Bar.net Foo.net Innocen t.net Mail server Innocent.net Was this traffic sent from Innocent.net? No

11. 11 © 2008 Andreas Haeberlen, MPI-SWS How PGPA could be used PGPA could be used to solve each of the motivating problems: Bypassing spam blacklists False accusations Alice Eve Bar.net Foo.net Innocen t.net Tracker "Hi, I am Alice" Was this sent from 1.2.3.4? 1.2.3.4 No

12. 12 © 2008 Andreas Haeberlen, MPI-SWS How PGPA could be used PGPA could be used to solve each of the motivating problems: Bypassing spam blacklists False accusations Unverifiable complaints, plausible deniability Alice Eve Bar.net Foo.net Admin "Alice has been portscanning me!" Is that true?

13. 13 © 2008 Andreas Haeberlen, MPI-SWS PGPA tradeoffs Associates packets with addresses, not users Reveals that packets were sent, but not why Assumes that ISPs and users do not collude Very simple Effective against real-world problems Compatible with anonymity Protects users' privacy Straightforward implementation Plausible deployment path Limitations: Advantages: Rest of this talk

14. 14 © 2008 Andreas Haeberlen, MPI-SWS Outline Introduction Pretty Good Packet Authentication (PGPA) How PGPA could be used A simple implementation Conclusion

15. 15 © 2008 Andreas Haeberlen, MPI-SWS Keeping records of past traffic PGPA needs to 'remember' past traffic A set of traffic monitors keep a record of transmitted packets Storing (timestamp, hash) per packet is sufficient Where should the traffic monitors be placed? Natural choice: Access link Backbone is not modified  much easier to deploy Access links Alice Bob A.net B.net Internet Charlie

16. 16 © 2008 Andreas Haeberlen, MPI-SWS Where to place the traffic monitor? A.net User's premises: Inexpensive; good scalability User can physically destroy the device At the ISP: Easy to deploy User has to trust the ISP Secure channel Monitor Both: No trust user  ISP required More overhead Modem Router

17. 17 © 2008 Andreas Haeberlen, MPI-SWS Calculating digests Monitor stores only a digest of each packet Saves space; preserves privacy if monitor is compromised What if packet is transformed in the network? Examples: TTL, ECN bits, IP fragmentation, header options Digest must be invariant to transformations [Snoeren02] Reassemble packet before hashing; zero out certain fields Hash: 0x4711 Hash: 0xD1FF TTL: 63 CONTENT 58 A.net

18. 18 © 2008 Andreas Haeberlen, MPI-SWS PGPA preserves users' privacy Can PGPA be used to snoop on users' traffic? Seen earlier: PGPA only confirms specific packets But what if the attacker tries to guess a packet? Infeasible - attacker would have to correctly guess the transmission time plus TCP seq. no., IPID field, etc. (≥80 bits) What if the monitor is stolen or compromised? Only reveals digests, not actual packets Can include a salt in each digest (against dictionary attacks) Spy Monitor Did you send traffic to cnn.com earlier today? Did you send packet X at time t? Yes

19. 19 © 2008 Andreas Haeberlen, MPI-SWS Traffic monitors are feasible How much storage does a monitor need? Example: DSL connection Assume worst case: 1 Mbps upstream, fully utilized with 40- byte packets at all times  3,125 packets/sec Monitor stores SHA-1 hash, 32-bit timestamp per packet  Need 187 GB/month Single harddisk per user in the worst case Likely to hold in the future (storage grows faster than bw) Many set-top boxes already contain storage

20. 20 © 2008 Andreas Haeberlen, MPI-SWS Summary The Internet needs a mechanism to authenticate packets Pretty Good Packet Authentication (PGPA) is a compromise between power and feasibility PGPA is simple, easy to implement, and has a plausible deployment path Thank you!