1. Internet Infrastructure Protection May 23, 2006 Steve Crocker, steve@shinkuro.com ICANN Security and Stability Committee Shinkuro, Inc.

2. 2 My Primary Message Build security into the infrastructure Good architecture is cheaper and better than chasing the bad guys It’s less sexy but more effective CERTs, Firewalls, Honeynets, etc. are all good Networking the security community is good Do all of this, but also invest in the architecture

3. 3 Latin America has unique opportunity Plenty of technical talent Networks are still in a growth stage Not as much legacy as North America, Europe Good communication, cooperation Opportunity to leap ahead

4. 4 Incidents Reported to CERT/CC

5. 5 Vulnerabilities Reported to CERT/CC

6. 6 Attack Sophistication vs. Intruder Knowledge email propagation of malicious code “stealth”/advanced scanning techniques widespread attacks using NNTP to distribute attack widespread attacks on DNS infrastructure executable code attacks (against browsers) automated widespread attacks GUI intruder tools hijacking sessions Internet social engineering attacks packet spoofing automated probes/scans widespread denial-of-service attacks techniques to analyze code for vulnerabilities without source code DDoS attacks increase in worms sophisticated command & control anti-forensic techniques home users targeted distributed attack tools increase in wide-scale Trojan horse distribution Windows-based remote controllable Trojans (Back Orifice) Intruder Knowledge Attack Sophistication 19902004

7. 7 Internet Infrastructure Threats 1. Physical disruption of major lines and switching centers 2. Loss of DNS service continuity and/or fidelity 3. Loss of routing infrastructure continuity and/or fidelity 4. Flooding of network or specific sites, i.e. denial of service attack

8. 8 Internet Infrastructure Protection DNSSEC Address Security DDoS suppression

9. DNSSEC Deployment

10. Segments Demo DNS & DNSSEC basics Deployment Issues Opportunity!

11. Hijack Demo Connect to BADNET network We will intercept your queries…

12. DNSSEC Basics Slides from RIPE NCC

13. 13 Why DNSSEC? DNS is not secure Known vulnerabilities People depend more and more on DNS DNSSEC protects against data spoofing and corruption

14. 14 DNS: Known Concepts Known DNS concepts: Delegation, Referral, Zone, RRs, label, RDATA, authoritative server, caching forwarder, stub and full resolver, SOA parameters, etc

15. Reminder: DNS Resolving Resolver Question: www.ripe.net A www.ripe.net A ? Caching forwarder (recursive) root-server www.ripe.net A ? “go ask net server @ X.gtld-servers.net” (+ glue) gtld-server www.ripe.net A ? “go ask ripe server @ ns.ripe.net” (+ glue) ripe-server www.ripe.net A ? “193.0.0.203” 193.0.0.203 12345 6 7 Add to cache 9 810 TTL

16. DNS: Data Flow master Caching forwarder resolver Zone administrator Zone file Dynamic updates 12 slaves 345

17. DNS Vulnerabilities master Caching forwarder resolver Zone administrator Zone file Dynamic updates 12 slaves 3 Server protection 45 Corrupting data Impersonating master Unauthorized updates Cache impersonation Cache pollution by Data spoofing Data protection Altered zone data

18. 18 DNSSEC protects.. DNSSEC protects against data spoofing and corruption DNSKEY/RRSIG/NSEC: provides mechanisms to establish authenticity and integrity of data DS: provides a mechanism to delegate trust to public keys of third parties A secure DNS will be used as an infrastructure with public keys However it is NOT a PKI

19. 19 DNSSEC Current State RFC 4033 DNS Security Introduction and Requirements RFC 4034 Resource Records for the DNS Security Extensions RFC 4035 Protocol Modifications for the DNS Security Extensions March 2005 Obsoletes RFC 2535

20. 20 DNSSEC hypersummary Data authenticity and integrity by signing the Resource Records Sets Public DNSKEYs used to verify the RRSIGs Children sign their zones with their private key Authenticity of that key established by signature/checksum by the parent (DS) Ideal case: one public DNSKEY distributed

21. Deployment Issues Getting the Root Signed Getting TLDs Signed  Getting Enterprises Signed Resolvers Applications

22. Key Generation Key Distribution Root Signing Serving Signed Root TLD Key Acquisition Serving Signed Root with TLD Keys AB C FE D Root Signing Road Map

23. Getting TLDs Signed -- Issues Current Status Zone Walking Zone Size

24. TLD Zone Status.SE (Sweden) is signed and operational RIPE’s portion of in-addr.arpa is signed.ORG,.COM and.NET have test beds More coming

25. Zone Walking NSEC (“Next Secure”) makes it possible to “walk the zone” to find all entries Some (many?) TLD operators object NSEC3, using hashes, solves this problem NSEC3 design is done(?) Shakedown workshop at DENIC in early May Good progress. Further testing and documentation needed

26. Zone Size Memory requirements expand three to five times for a fully signed zone Significant impact on large zones -- COM, NET, ORG, DE, UK, … Current design requires one NSEC record for every delegation, even if it’s not signed “Opt-in” requires NSEC (or NSEC3) record only for signed zones (Some call this “opt-out”. Same thing.) Slightly different but equivalent security Much lower initial impact Opt-in is coming with NSEC3

27. Getting Enterprises Signed In house operation Outsourced operation

28. In House Operation Software Possible hardware Operations Policies Key lifetimes, management chain Procedures, Training Become a founding operator…

29. Outsourced Operation Many enterprises outsource DNS service Registrars, hosting services Managed DNS Service Providers UltraDNS, VeriSign, Akamai, Netriplex, Infoblox, EasyDNS, DNS Made Easy DNS Service Providers can add DNSSEC with zero imposition on domain name holder Except perhaps for a charge  DNS Service Providers will be the source of many signed zones

30. Opportunity! Meanwhile, in the short run, it’s up to us. Be a DNSSEC founding operator Sign your zone Be the primary for others Be a secondary Tuesday we will announce a small directory of primary and secondary signer/operators http://www.dnssec-deployment.org/zones Sign up. Talk to us today. Send email.

31. 31 DNSSEC Deployment is… … the transition from specs to operation … a multinational effort … a complex process … a project that needs your help

32. 32 Organizational Matters Pockets of expertise Sweden, Netherlands, U.S., Japan Active test bed and deployment in a few places Deployment Working Group active

33. 33 What’s Needed Local efforts in each country Regional cooperation for training, etc. Awareness campaigns Testing Application development

34. 34 Government Role(s) Awareness, motivation Prioritization – protect critical infrastructure Funding of key local activities Participation in global forum Adoption and leadership internally

35. Contacts & Resources steve.shinkuro.com www.dnssec-deployment.org Slides and other DNSSEC material at: www.ripe.net/training/dnssec/ www.ripe.net/training/dnssec/ http://www.nlnetlabs.nl/dnssec/ http://www.dnssec.net/ ===================================== Support provided by U.S. Dept. of Homeland Security, Science and Technology Directorate Cooperative work with Sparta, NIST, MIT Lincoln Laboratory

36. 36 Acknowledgements Olaf Kolkman, RIPE Edward Lewis, NeuLevel The Whole DNSSEC Deployment Working Group

37. Address Validation

38. 38 Address Validation is Essential Address spoofing is a key component of multiple attacks Must check at ingress Every ISP must do this

39. 39 What is Address Validation? Does the source address belong to this customer? Requires knowing authorized source addresses Same as destination addresses Requires checking Adds cost, hardware Do it anyway Insist your peers do it too

40. 40 Suppression of Distributed Denial of Service (DDoS) Attacks

41. 41 The Denial of Service Problem Denial of service attacks are increasing This will get worse – probably much worse Law enforcement is important but necessarily at the wrong end of the problem Technical changes in the Internet would help a lot

42. 42 A modest(?) proposal for controlling DDoS Attacks Identify sources of traffic Identify “well managed” computers on “well managed” networks Traffic from well managed networks gets preference

43. 43 “Well managed” “Well managed” computers aren’t zombies Details on the next slide Well managed networks quarantine computers which appear to be infected or misbehaving Well managed networks report misbehaviors and accept reports of misbehaviors

44. 44 Weeding out Zombies Regular configuration checking Either within the enterprise Or by an outside service Tight configuration control (Eventually) certified appliances

45. 45 Network Wide Cooperation Traffic among well managed networks gets preference Traffic from same sites is labeled with a “good” bit Eerily similar to Bellovin’s “evil” bit(!) When there is congestion, traffic from unmanaged hosts on unmanaged networks is dropped How is traffic labeled? Diffserv? IP header bit? MPLS? Other?

46. 46 DDoS Policy Approaches Pressure on the vendor to supply machines that are safe out of the box Establishment of an ethic that machines should be safe, i.e. it’s the vendor’s problem, not the user’s. This all requires R&D, clarity of vision, and perseverance. Not an overnight process.

47. 47 Arguments in Favor Similar to VPN over private lines, but potentially more efficient Adds incentive to improve security in hosts and networks Raises DDoS protection to a primary goal Incremental – works well with a small set of core ISPs and expands smoothly Robust – does not require 100% correct operation Failures can be detected; adjustments can be made

48. 48 Critique Sharp shift in policy Requires strong cooperation among ISPs Who sets the rules? Enforcement issues Who determines when an ISP or a customer isn’t complying? What appeals process? Efficiency issue for large ISPs: Is it feasible to filter traffic at high speed?

49. Shinkuro Overview

50. 50 Working Together? Why is so hard to work closely together over the net? Email and Instant Messaging… Is that all there is? Need flexible, easily configurable, user- controlled file-sharing, screen-sharing, etc. Need very low cost

51. 51 Shinkuro Collaboration Peer-to-peer, ad hoc group formation and data sharing Secure Lightweight Operational across organizational boundaries Unimpeded by firewalls Implicit communication – less drag, focus on apps Contributions and interactions across… Network technology Collaboration technology Human-computer interactions Security models

52. 52 Our Approach Replicate data between group members Each member specifies a shared folder Data replicates between all members Access control Messages secured during transport Supports intermittent connection of members Approach includes… Direct & relayed transport Presence & instant messaging Screen-sharing Generalized platform capabilities Other small features

53. 53 Status Version 2 is being tested broadly Direct and relay transport Instant messaging & presence Screen-sharing Other platform capabilities Internal use of system; changing the way we work

54. 54 Shinkuro Strengths Group formation protocol Secure, decentralized mechanism for group formation Independent of file sharing and replication Simplex replication model Overcomes human issues of file sharing Resolves difficulties in loosely coupled systems Transport Multiple transports and opportunities to add others Security Encrypted and signed communications without relying on SSL or TLS Opaque message transfer through relays Platform Extensible design for leveraging group formation mechanisms into new applications

55. 55 Group Formation Protocol Peer group formation using cross certification of group members

56. 56 Simplex Model Replication

57. 57 Operational Concept Organization AOrganization B User Desktop Relay User Desktop User Desktop User Desktop User Desktop User Desktop User Desktop User Desktop Relay Organization C User Desktop User Desktop

58. 58 Security Built into the system core Fundamental to group formation Designed to minimize reliance on secured channels (SSL, TLS) X509v3 certificate generated for each user Keys exchanged before other communications Each message is separately encrypted (no session keys)

59. 59 Platform Components designed as separately functional “managers” Designed using a service model Some well known services exist (key ring, crypto, group management) Other services implemented around the core File replication Group chat Core code implemented as a library of services for the main application UI Can be used within other applications Services can be added into as loadable modules (coming soon)

60. 60 Supervisor (extensibility manager) Communications Manager (transport) Direct/RelaySMTPPOP3MAPI Queue Manager (message handling) Group Manager (group formation) Directory Manager (file replication) Chat Manager (group conversation) Instant Messaging (one-to-one chat) Person Manager (keyring) Other Group Functions (extensions) Other Managers (extensions) Other User InterfaceCommand Server DyCER API APIImplementedExpansion Key Architecture Crypto Manager Alerts Manager Settings Manager Implemented Utilities Screen Sharing Manager Other UI/ApplicationsWeb-Based UI Direct File Transfer

61. 61 Try it! www.shinkuro.com Windows, Mac, Linux, FreeBSD Free! Tell us what you think