1 / 26

Internet2 DNSSEC Pilot

Internet2 DNSSEC Pilot. Shumon Huque University of Pennsylvania Sprint Internet2 Member Meeting Arlington, Virginia, U.S.A., Apr 23rd 2007. This is mostly a repeat of a presentation I gave at the Winter 2007 Joint Techs meeting, February 2007, Minneapolis, Minnesota, U.S.A.

lindyt
Download Presentation

Internet2 DNSSEC Pilot

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Internet2 DNSSEC Pilot Shumon Huque University of Pennsylvania Sprint Internet2 Member Meeting Arlington, Virginia, U.S.A., Apr 23rd 2007

  2. This is mostly a repeat of a presentation I gave at the Winter 2007 Joint Techs meeting, February 2007, Minneapolis, Minnesota, U.S.A.

  3. Description of the Pilot • http://www.dnssec-deployment.org/internet2/ • Deploy DNSSEC • Gain Operational experience • Does it work (does it catch anything?) • Test DNSSEC aware applications • Participants sign at least one of their zones • Exchange keys (trust anchors) that will allow them to mutually validate DNS data

  4. What is DNSSEC? • A system to verify the authenticity of DNS “data” • RFC 4033, 4034, 4035 • Helps detect: spoofing, misdirection, cache poisoning • Some secondary benefits appear: • You could store keying material in DNS • DKIM, SSHFP, IPSECKEY, etc

  5. A little background .. • Feb ‘06: DNSSEC Workshop held at Albuquerque Joint Techs • Mar ‘06: dnssec@internet2 mailing list • Apr ‘06: Internet2 Spring Member meeting • Advisory group formed and plans for a pilot project formulated • May ‘06: Pilot group began • Monthly conference calls and progress reports

  6. Co-ordination • Internet2 • Shinkuro シンクロ • Partner in DNSSEC Deployment Initiative • http://www.dnssec-deployment.org/ • Some funding from US government

  7. DNSSEC Deployment Efforts so far • MAGPI GigaPoP • All zones: magpi.{net,org} & 15 reverse zones • https://rosetta.upenn.edu/magpi/dnssec.html • MERIT • radb.net • nanog.org • http://www.merit.edu/networkresearch/dnssec.html • NYSERNet - test zone • nyserlab.org

  8. Others considering or planning deployment • University of Pennsylvania • University of California - Berkeley • University of California - Los Angeles • University of Massachusetts - Amherst • Internet2

  9. DLV (DNSSEC Lookaside Validation) • A mechanism to securely locate DNSSEC trust anchors “off-path” • An early deployment aid until top-down deployment of DNSSEC happens • Pilot group is in talks to make use of ISC’s DLV registry • http://www.isc.org/index.pl?/ops/dlv/ • More on this at a later date ..

  10. More participants welcome! • (participation not restricted to Internet2) • Join mailing list • Participate in conference calls

  11. Thoughts on deployment obstacles (1) • A Chicken & Egg problem • Marginal benefits, until much more deployment • Why should I go first? • We had (have?) the same problem with other technologies (IPv6 etc) • Some folks will need to take the lead, if there is hope for wider adoption • Good way to find out how well it works

  12. Thoughts on deployment obstacles (2) • Operational stability • More complicated software infrastructure • New processes for: • Zone changes • Secure delegations • Security (protection of crypto keys) • Key rollover and maintenance • Integration w/ existing DNS management software • What is the experience of the pilot?

  13. Thoughts on deployment obstacles (3) • Additional system requirements • Authoritative servers: memory • Resolvers: memory & CPU • Memory use can be calculated • Probably not a big issue (unless you’re .COM!) • CPU • Not too much of an issue today (dearth of signed data that needs validation) • Caveat: some potential DoS attacks could hit CPU

  14. Thoughts on deployment obstacles (4) • Key distribution in islands of trust • Why is there no top down deployment? • Work on signing root and (many) TLDs and in-addr.arpa is in progress • .SE, RIPE reverse done • .EDU work in motion • Interim mechanisms like DLV exist • Manual key exchange (unscalable)

  15. Thoughts on deployment obstacles (5) • Stub resolver security (e2e security) • An area of neglect in my opinion • Push DNSSEC validation to endstations? • Secure path from stub resolver to recursive resolver • Possibilities: SIG(0), TSIG, IPSEC

  16. Thoughts on deployment obstacles (6) • Application layer feedback • Coming gradually • DNSSEC aware resolution APIs and applications enhanced to use them • DNSSEC aware applications • See http://www.dnssec-tools.org/ • Note: some folks think it might be nice to protect DNSSEC oblivious applications silently as an interim step

  17. Thoughts on deployment obstacles (7) • Zone enumeration threat • See NSEC3 record (spec almost done) • draft-ietf-dnsext-nsec3-09.txt • Hashed Authenticated Denial of Existence • Also provides “Opt-Out” (to allow spans of unsecured records in a signed zone)

  18. Additional BoF topics

  19. DLV participation procedures • See Joao Damas’ earlier presentation • ISC DLV registry • http://www.isc.org/index.pl?/ops/dlv/ • Policy and practice statement: • https://secure.isc.org/ops/dlv/dlv-pol-pract-v1.0.php

  20. edu Top-Level-Domain signing • Who’s involved: Educause, Verisign, US Dept of Commerce • What can Internet2 schools do to help make this a reality? • NSEC3 is not needed: • edu zone is small (< 8000 delegations) • Relatively static • No zone privacy requirements

  21. Securing last hop(s) • Most university threat models include untrustworthiness of the local network • ie. path between client and recursive resolver is NOT secure • Need stub resolvers capable of: • 1. Validating DNSSEC signatures, or • 2. Supporting channel protection mechanisms that allow them to authenticate response from recursive resolver • SIG(0), TSIG etc

  22. Securing last hop(s) cont .. • Which channel protection mechanism? • Simple symmetric key TSIG has problems • Can’t distribute same TSIG key to many clients - that allows any of them to forge DNS answers to others • Need per-client keys and thus additional key management infrastructure • SIG(0) may be more manageable • A public key signature of the response msg • Need to only distribute the public key

  23. Application feedback • DNSSEC aware resolution API/libraries • eg. • draft-hayatnagarkar-dnsext-validator-api-03 • Plus applications enhanced to use them

  24. References • Internet2 DNSSEC Pilot • http://www.dnssec-deployment.org/internet2/ • http://rosetta.upenn.edu/magpi/dnssec.html • Mailing list: dnssec@internet2.edu • https://mail.internet2.edu/wws/info/dnssec • Internet2 DNSSEC Workshop • http://events.internet2.edu/2006/jt-albuquerque/sessionDetails.cfm?session=2491&event=243

  25. References (2) • DNSSEC(bis) technical specs: • RFC 4033, 4034, 4035 • Related: • DNSSEC HOWTO: • http://www.nlnetlabs.nl/dnssec_howto/ • Threat analysis of the DNS: RFC 3833 • Operational practices: RFC 4641 • NSEC3: draft-ietf-dnsext-nsec3-09 • DLV: draft-weiler-dnssec-dlv-01 • draft-hubert-dns-anti-spoofing-00

  26. Questions? • Shumon Huque • shuque -at- isc.upenn.edu

More Related