Deploy360 Programme (Internet Society), profile picture
Uploaded byDeploy360 Programme (Internet Society)
PDF, PPTX515 views

ION San Diego - ARIN Support for DNSSEC and RPKI

The document discusses DNSSEC and RPKI. It provides an overview of DNSSEC, explaining how it uses public key cryptography and digital signatures to authenticate DNS data and verify the authenticity of DNS responses. It then discusses RPKI, explaining that it attaches ASNs and IP address blocks to X.509 certificates to validate the origination of IP routes announced in BGP. The certificates are issued based on resource allocations and signed based on the resource allocation hierarchy.

Embed presentation

Download as PDF, PPTX
ARIN Support for DNSSEC and RPKI ION San Diego 11 December 2012 Pete Toscano, ARIN
2 DNS and BGP •  They have been around for a long time. •  DNS: 1982 •  BGP: 1989 •  They are not very secure. •  Methods for securing them exist.
3 DNSSEC •  Domain Name System Security Extensions •  Took a while to implement -- •  Design work started in 1993 at IETF 28. •  The root zone signed: July 15th, 2010.
4 DNSSEC •  Designed to verify data integrity and authenticity. •  Does not prevent data snooping. •  Generally, that first point outweighs these others.
5 DNSSEC •  DNSSEC is an overlay on top of DNS, not a replacement. •  Uses public key cryptography and a chain of trust similar to X.509 certificates.
6 DNSSEC •  Adds six new RR types and extension mechanisms for DNS (EDNS). •  DNSKEY •  DS •  RRSIG •  NSEC •  NSEC3 •  NSEC3PARM
7 DNSSEC •  DNSKEY: The public keys. Either a Key Signing Key (KSK) or Zone Signing Key (ZSK). •  DS: Delegation Signer. Hashes and identifies the KSK of a signed, delegated child zone.
8 DNSSEC •  RRSIG: Resource Record Signature. Every RRset for each name has a single RRSIG. There are two exceptions: •  NS records at delegation points. •  Glue records. •  DNSKEY RRSIGs are signed by the KSK, all others by ZSK.
9 DNSSEC •  NSEC/NSEC3: Next Secure Record / Next Secure Record version 3. •  Used to prove the non-existence of a resource record.
10 DNSSEC • A simple example of securing a zone. example.com. SOA [SOA STUFF]! NS ns! MX 10 mail! mail A 128.66.0.100! AAAA 2001:db8::100! ns A 128.66.0.10! AAAA 2001:db8::10! sub NS ns.sub! ns.sub A 128.66.10.10! AAAA 2001:db8:10::10! !
11 DNSSEC • Throw in the keys... example.com. SOA [SOA STUFF]! NS ns! MX 10 mail! DNSKEY 256 [DNSKEY STUFF]; ZSK! DNSKEY 257 [DNSKEY STUFF]; KSK! mail A 128.66.0.100! AAAA 2001:db8::100! ns A 128.66.0.10! AAAA 2001:db8::10! sub NS ns.sub! ns.sub A 128.66.10.10! AAAA 2001:db8:10::10!
12 DNSSEC •  Add the NSEC records so that all gaps are accounted for... example.com. SOA [SOA STUFF]! example.com. NS ns! example.com. MX 10 mail! example.com. DNSKEY 256 [DNSKEY STUFF]; ZSK! example.com. DNSKEY 257 [DNSKEY STUFF]; KSK! example.com. NSEC mail.example.com. SOA NS MX DNSKEY NSEC! mail.example.com. A 128.66.0.100! mail.example.com. AAAA 2001:db8::100! mail.example.com. NSEC ns.example.com. A AAAA NSEC! ns.example.com. A 128.66.0.10! ns.example.com. AAAA 2001:db8::10! ns.example.com. NSEC sub.example.com. A AAAA NSEC! sub.example.com. NS ns.sub! sub.example.com. NSEC example.com. NS NSEC! ns.sub.example.com. A 128.66.10.10! ns.sub.example.com. AAAA 2001:db8:10::10! • NSEC doesn’t do glue. • Zone enumeration? That’s where NSEC3 comes in.
DNSSEC 13 •  Sign each label’s RRset and update NSECs... example.com. SOA [SOA STUFF]! example.com. RRSIG SOA [RRSIG STUFF]! example.com. NS ns! example.com. RRSIG NS [RRSIG STUFF]! example.com. MX 10 mail! example.com. RRSIG MX [RRSIG STUFF]! example.com. DNSKEY 256 [DNSKEY STUFF]; ZSK! example.com. DNSKEY 257 [DNSKEY STUFF]; KSK! example.com. RRSIG DNSKEY [RRSIG STUFF]! example.com. NSEC mail.example.com. SOA NS MX DNSKEY NSEC RRSIG! example.com. RRSIG NSEC [RRSIG STUFF]! mail.example.com. A 128.66.0.100! mail.example.com. RRSIG A [RRSIG STUFF]! mail.example.com. AAAA 2001:db8::100! mail.example.com. RRSIG AAAA [RRSIG STUFF]! mail.example.com. NSEC ns.example.com. A AAAA NSEC RRSIG! mail.example.com. RRSIG NSEC [RRSIG STUFF]! ns.example.com. A 128.66.0.10! ns.example.com. RRSIG A [RRSIG STUFF]! ns.example.com. AAAA 2001:db8::10! ns.example.com. RRSIG AAAA [RRSIGSTUFF]! ns.example.com. NSEC sub.example.com. A AAAA NSEC RRSIG! ns.example.com. RRSIG NSEC [RRSIG STUFF]! sub.example.com. NS ns.sub! sub.example.com. NSEC example.com. NS NSEC RRSIG! sub.example.com. RRSIG NSEC [RRSIG STUFF]! ns.sub.example.com. A 128.66.10.10! ns.sub.example.com. AAAA 2001:db8:10::10!
DNSSEC 14 •  Signed delegations. Add DS records and update NSEC and RRSIGs. example.com. SOA [SOA STUFF]! example.com. RRSIG SOA [RRSIG STUFF]! example.com. NS ns! example.com. RRSIG NS [RRSIG STUFF]! example.com. MX 10 mail! example.com. RRSIG MX [RRSIG STUFF]! example.com. DNSKEY 256 [DNSKEY STUFF]; ZSK! example.com. DNSKEY 257 [DNSKEY STUFF]; KSK! example.com. RRSIG DNSKEY [RRSIG STUFF]! example.com. NSEC mail.example.com. SOA NS MX DNSKEY NSEC RRSIG! example.com. RRSIG NSEC [RRSIG STUFF]! mail.example.com. A 128.66.0.100! mail.example.com. RRSIG A [RRSIG STUFF]! mail.example.com. AAAA 2001:db8::100! mail.example.com. RRSIG AAAA [RRSIG STUFF]! mail.example.com. NSEC ns.example.com. A AAAA NSEC RRSIG! mail.example.com. RRSIG NSEC [RRSIG STUFF]! ns.example.com. A 128.66.0.10! ns.example.com. RRSIG A [RRSIG STUFF]! ns.example.com. AAAA 2001:db8::10! ns.example.com. RRSIG AAAA [RRSIG STUFF]! ns.example.com. NSEC sub.example.com. A AAAA NSEC RRSIG! ns.example.com. RRSIG NSEC [RRSIG STUFF]! sub.example.com. NS ns.sub! sub.example.com. DS [Hash of sub’s KSK]! sub.example.com. RRSIG DS [RRSIG STUFF]! sub.example.com. NSEC example.com. NS DS NSEC RRSIG! sub.example.com. RRSIG NSEC [RRSIG STUFF]! ns.sub.example.com. A 128.66.10.10! ns.sub.example.com. AAAA 2001:db8:10::10!
15 DNSSEC •  What to do with all this extra data? •  Publishing the signed data is only half the battle. •  The authoritative DNS responses need to be validated.
16 DNSSEC •  Response validation involves following a chain of trust from the trust anchor to the answer received. •  Typically, the root zone’s KSK == Trust Anchor
17 DNSSEC •  The backbone of the chain of trust is the DS, DNSKEY, RRSIG interaction. •  Trust travels from the parent zone down to the child zone. Repeat until the target zone is found. •  Start at the trust anchor’s zone.
18 DNSSEC RRSIG! KSK DNSKEY! ZSK DNSKEY! Parent Zone RRSIG! ...! DS! RRSIG! KSK DNSKEY! Child Zone ZSK DNSKEY! RRSIG! ...! DS!
19 DNSSEC •  Once the target child zone is found, the ZSK is used the verify the appropriate RRSIG. •  If the question cannot be answered, the ZSK can be used to verify the appropriate NSEC/NSEC3 RRSIG. •  If the answer can’t be verified, then NXDOMAIN status is returned.
20 DNSSEC •  From a DNS publisher’s point of view, DNSSEC can greatly expand the size of zones. •  On average, responses are larger. •  Management of the keys can be tricky. •  Protects the data, not the headers. •  Does nothing to protect the stub resolver to recursive resolver communication.
21 DNSSEC •  At ARIN, we currently sign our v4 /8s and v6 /12 and /24s. •  ARIN Online allows members to add DS records to the zones their resources are delegated from.
22 DNSSEC •  DNSSEC Analyzer: http://dnssec-analyzer.verisignlabs.com •  DNSViz: http://dnsviz.net •  ldns / Drill: http://www.nlnetlabs.nl/projects/ldns/ •  DNSSEC Validator: http://www.dnssec-validator.cz/ (FF Plugin) •  Other Tools: https://www.dnssec-deployment.org/wiki/ index.php/Tools_and_Resources
23 RPKI
24 “The inter-domain routing protocol BGP was created when the Internet environment had not yet reached the present, contentious state. Consequently, the BGP design did not include protections against deliberate or accidental errors that could cause disruptions of routing behavior.” • Intro to RFC 4272 “BGP Security Vulnerabilities Analysis” January 2006
25 RPKI This is the basic problem... Send  a  packet   to   209.85.128.100   I  have   209.85.128.0/17  
26 RPKI 165.135.0.2 209.85.128.100 AS100   AS200   AS300  
27 RPKI 165.135.0.2 209.85.128.100 AS100   AS200   AS300   AS666   209.85.128.100
28 RPKI •  April 1997 – AS 7007 announced paths for all of the internet to themselves. •  Feb. 24, 2008 –Pakistan Telecom announced a part of YouTube’s address blocks. •  April 2010 - China Telecom mis-originated about 15% of Internet address blocks affecting I-root. •  Nov. 2012 – Google was unavailable some places via route leak from Moratel.
29 RPKI 165.135.0.2 209.85.128.100 AS100   AS200   AS300   Phase 1: Origin Validation (requires RPKI) Phase 2: Path Validation (still in draft phase)
30 RPKI •  Resource Public Key Infrastructure •  RPKI attaches ASNs and IP address blocks to X.509 v3 certs. •  These resource certs are signed by the resource parent.
31 RPKI IANA! Resource Allocation Hierarchy AFRINIC! APNIC! ARIN! LACNIC! RIPE NCC! ISP 1! ISP 2! ISP 4! ISP 3! ISP! ISP! ISP!
32 Certificates RPKI IANA! issued to match allocations. AFRINIC! APNIC! ARIN! LACNIC! RIPE NCC! Issuer: ARIN! Subject: ARIN! Resources: 192.0.0.0/8! ISP 1! ISP 2! ISP 4! Key Info: <arin-key-pub>! Signed: <arin-key-priv>! ISP 3! ISP! ISP! ISP!
33 Certificates RPKI IANA! issued to match allocations. AFRINIC! APNIC! ARIN! LACNIC! RIPE NCC! Issuer: ARIN! Issuer: ARIN! Subject: ISP1! Subject: ARIN! Resources: 192.2.0.0/16! Resources: 192.0.0.0/8! Key Info: <isp1-key-pub>! ISP 1! ISP 2! ISP 4! Key Info: <arin-key-pub>! Signed: <arin-key-priv>! Signed: <arin-key-priv>! ISP 3! ISP! ISP! ISP!
34 Certificates RPKI IANA! issued to match allocations. AFRINIC! APNIC! ARIN! LACNIC! RIPE NCC! Issuer: ARIN! Issuer: ARIN! Subject: ISP1! Subject: ARIN! Resources: 192.2.0.0/16! Resources: 192.0.0.0/8! Key Info: <isp1-key-pub>! ISP 1! ISP 2! ISP 4! Key Info: <arin-key-pub>! Signed: <arin-key-priv>! Signed: <arin-key-priv>! Issuer: ISP1! Subject: ISP3! Resources: 192.2.200.0/24! Key Info: <isp3-key-pub>! Signed: <isp1-key-priv>! ISP 3! ISP! ISP! ISP!
35 RPKI •  Address holders issue Route Origin Authorizations (ROAs).
36 Certificates RPKI IANA! issued to match allocations. AFRINIC! APNIC! ARIN! LACNIC! RIPE NCC! Issuer: ARIN! Issuer: ARIN! Subject: ISP1! Subject: ARIN! Resources: 192.2.0.0/16! Resources: 192.0.0.0/8! Key Info: <isp1-key-pub>! ISP 1! ISP 2! ISP 4! Key Info: <arin-key-pub>! Signed: <arin-key-priv>! Signed: <arin-key-priv>! Issuer: ISP1! Subject: ISP3! Resources: 192.2.200.0/24! Key Info: <isp3-key-pub>! Signed: <isp1-key-priv>! ISP 3! ISP! ISP! ISP!
37 Certificates RPKI IANA! issued to match allocations. AFRINIC! APNIC! ARIN! LACNIC! RIPE NCC! Issuer: ARIN! Issuer: ARIN! Subject: ISP1! Subject: ARIN! Resources: 192.2.0.0/16! Resources: 192.0.0.0/8! Key Info: <isp1-key-pub>! ISP 1! ISP 2! ISP 4! Key Info: <arin-key-pub>! Signed: <arin-key-priv>! Signed: <arin-key-priv>! Issuer: ISP1! Subject: ISP3! Resources: 192.2.200.0/24! Key Info: <isp3-key-pub>! Signed: <isp1-key-priv>! ISP 3! ISP! ISP! ISP! Issuer: ISP3! ROA: “ISP 3 permits ASN 123 to originate its Subject: ISP3-EE! 192.2.200.0/24 network space.”! Resources: 192.2.200.0/24! ! Key Info: <isp3EE-key-pub>! ! Signed: <isp3-key-priv>! ß Attached! Signed, <isp3EE-key-priv>! !
38 RPKI •  Two RPKI implementation types: •  Delegated: Each participating node becomes a CA and runs their own RPKI repository, delegated to by the parent CA. •  Hosted: The RIR runs the CA functionality for interested participants.
39 RPKI •  For most participants, running a CA would be an insurmountable obstacle to the implementation of RPKI. •  This is why the hosted option exists.
40 RPKI •  Regardless of the method used, the RPKI repositories are published. •  TAL: Trust Anchor Locator •  Points to the rsync entry point of that repo. •  Includes that repo’s public key.
41 RPKI •  Reliant third parties would gather all relevant TALs. •  Get all of the RPKI repos. •  Validate, validate, validate.
42 RPKI •  Once we have validated ROAs and the backing resource hierarchy, what do we do?
43 RPKI •  Once we have validated ROAs and the backing resource hierarchy, what do we do? •  Use ROAs to weight BGP path announcements as they’re received.
44 RPKI 165.135.0.2 209.85.128.100 AS100   AS200   AS300   AS666   209.85.128.100
45 RPKI 165.135.0.2 209.85.128.100 AS100   AS200   AS300  
46 RPKI “Only AS 300 can originate 209.85.128.0/24 network space.”! 165.135.0.2 209.85.128.100 AS100   AS200   AS300  
47 RPKI “Only AS 300 can originate my 209.85.128.0/24 network space.”! 165.135.0.2 209.85.128.100 AS100   AS200   AS300   AS666   209.85.128.100
48 RPKI “Only AS 300 can originate my 209.85.128.0/24 network space.”! 165.135.0.2 209.85.128.100 AS100   AS200   AS300   AS666   209.85.128.100
49 RPKI •  Border routers use the RPKI with the RPKI/Router protocol. •  http://tools.ietf.org/html/draft-ietf- sidr-rpki-rtr •  Implemented on Cisco IOS and Quagga. JunOS recently added.
50 RPKI •  Offload validation and origin evaluation to some other box. •  “Valid”, “Invalid”, “Unknown” •  What’s done with these values is up to the local policy.
51 RPKI •  As with DNSSEC, the more buy in, the better the security. •  Be a good netizen: certify your resources. •  Even better: publish ROAs. •  Be the best happy shiny: validate route origins as support allows.
52 RPKI @ ARIN •  Only hosted model is currently implemented. •  The delegated model will be released in the not-too-distant future. •  Non-repudiation requirement. •  Third parties need to sign a RPA before getting the TAL.
53 Future of RPKI •  Single TAL. •  Inter-RIR transfers. •  Integrated with a path validation system.
54 Questions

More Related Content

PDF
dns-sec-4-slides
bykj teoh
 
PDF
DNSSEC: The Antidote to DNS Cache Poisoning and Other DNS Attacks
byFindWhitePapers
 
PDF
Understanding the DNS & DNSSEC
byICANN
 
PDF
PLNOG 5: Eric Ziegast, Zbigniew Jasinski - DNSSEC
byPROIDEA
 
ODP
2012 07-24 dnssec-og_open_dnssec_-_martin_toft_og_georg_sluyterman_slideshow
bysman_dk
 
PDF
2010 za con_todor_genov
byJohan Klerk
 
PDF
DNSSEC at Penn
byShumon Huque
 
PDF
DNS OARC 27: DNS over IPv6 - A study in fragmentation
byAPNIC
 
dns-sec-4-slides
bykj teoh
 
DNSSEC: The Antidote to DNS Cache Poisoning and Other DNS Attacks
byFindWhitePapers
 
Understanding the DNS & DNSSEC
byICANN
 
PLNOG 5: Eric Ziegast, Zbigniew Jasinski - DNSSEC
byPROIDEA
 
2012 07-24 dnssec-og_open_dnssec_-_martin_toft_og_georg_sluyterman_slideshow
bysman_dk
 
2010 za con_todor_genov
byJohan Klerk
 
DNSSEC at Penn
byShumon Huque
 
DNS OARC 27: DNS over IPv6 - A study in fragmentation
byAPNIC
 

What's hot

PDF
The DNSSEC KSK of the root rolls
byMen and Mice
 
PDF
DNS High-Availability Tools - Open-Source Load Balancing Solutions
byMen and Mice
 
PDF
DNSSEC signing Tutorial
byMen and Mice
 
PDF
MongoDB: Optimising for Performance, Scale & Analytics
byServer Density
 
PDF
DEF CON 27 - GERALD DOUSSOT AND ROGER MEYER - state of dns rebinding attack ...
byFelipe Prado
 
PDF
Encrypted DNS - DNS over TLS / DNS over HTTPS
byAlex Mayrhofer
 
PDF
Namespaces for Local Networks
byMen and Mice
 
PDF
An Overview of DNSSEC
byCarlos Martinez Cagnazzo
 
PDF
Part 3 - Local Name Resolution in Linux, FreeBSD and macOS/iOS
byMen and Mice
 
PPTX
DoH, DoT and ESNI
byJisc
 
PDF
Dns
byARYA TM
 
PDF
Defcon
byOpenDNS
 
PDF
Part 2 - Local Name Resolution in Windows Networks
byMen and Mice
 
PDF
DNSSEC - Domain Name System Security Extensions
byPeter R. Egli
 
PDF
DNSSEC Tutorial; USENIX LISA 2013
byShumon Huque
 
PDF
DNSSEC: What a Registrar Needs to Know (Part 2)
bylaurenrprice
 
PDF
Rolling the Root KSK
byAPNIC
 
PDF
Yeti DNS - Experimenting at the root
byMen and Mice
 
PPT
DNS – Domain Name Service
byJohnny Fortune
 
PDF
4Developers: Dns vs webapp
byPROIDEA
 
The DNSSEC KSK of the root rolls
byMen and Mice
 
DNS High-Availability Tools - Open-Source Load Balancing Solutions
byMen and Mice
 
DNSSEC signing Tutorial
byMen and Mice
 
MongoDB: Optimising for Performance, Scale & Analytics
byServer Density
 
DEF CON 27 - GERALD DOUSSOT AND ROGER MEYER - state of dns rebinding attack ...
byFelipe Prado
 
Encrypted DNS - DNS over TLS / DNS over HTTPS
byAlex Mayrhofer
 
Namespaces for Local Networks
byMen and Mice
 
An Overview of DNSSEC
byCarlos Martinez Cagnazzo
 
Part 3 - Local Name Resolution in Linux, FreeBSD and macOS/iOS
byMen and Mice
 
DoH, DoT and ESNI
byJisc
 
Dns
byARYA TM
 
Defcon
byOpenDNS
 
Part 2 - Local Name Resolution in Windows Networks
byMen and Mice
 
DNSSEC - Domain Name System Security Extensions
byPeter R. Egli
 
DNSSEC Tutorial; USENIX LISA 2013
byShumon Huque
 
DNSSEC: What a Registrar Needs to Know (Part 2)
bylaurenrprice
 
Rolling the Root KSK
byAPNIC
 
Yeti DNS - Experimenting at the root
byMen and Mice
 
DNS – Domain Name Service
byJohnny Fortune
 
4Developers: Dns vs webapp
byPROIDEA
 

Similar to ION San Diego - ARIN Support for DNSSEC and RPKI

PDF
APNIC_TRAINING_NetSec-26062013-Day2_MODUL 2.pdf
bybiasnasional
 
PDF
Introduction DNSSec
byAFRINIC
 
PDF
Hardening the Core of the Internet
byRIPE NCC
 
PDF
DNS Attacks
byHimanshu Prabhakar
 
PPTX
DNSandDNSSecurity (1).pptx
byAisha Siddiqui
 
PDF
CNIT 40: 6: DNSSEC and beyond
bySam Bowne
 
PDF
DNS Over HTTPS by Michael Casadevall
byGlenn McKnight
 
PDF
DNS & DNSSEC
byAPNIC
 
PPT
Dns protocol design attacks and security
byMichael Earls
 
PDF
Tsig 17022011
byphosika sithisane
 
PDF
7 technical-dns-workshop-day3
byDNS Entrepreneurship Center
 
PDF
Dnssec root-lacnog
byMehmet Akcin
 
PPTX
DNS Security (DNSSEC) With BIG-IP Global Traffic Manager
byDSorensenCPR
 
PDF
8 technical-dns-workshop-day4
byDNS Entrepreneurship Center
 
PDF
Internet and DNS evolution
byBill Miller
 
PDF
DNSSEC: How to deploy it, and why you should bother (ION Toronto 2011)
byInternet Society
 
PDF
DNSSEC: How to deploy it, and why you should bother (ION Toronto 2011)
byDeploy360 Programme (Internet Society)
 
PDF
Lamb dnssec
byErol Dizdar
 
PPTX
AEP Netwrorks Keyper HSM & ICANN DNSSEC
byChin Wan Lim
 
PDF
Building Trust into DNS: Key Strategies
bySafeNet
 
APNIC_TRAINING_NetSec-26062013-Day2_MODUL 2.pdf
bybiasnasional
 
Introduction DNSSec
byAFRINIC
 
Hardening the Core of the Internet
byRIPE NCC
 
DNS Attacks
byHimanshu Prabhakar
 
DNSandDNSSecurity (1).pptx
byAisha Siddiqui
 
CNIT 40: 6: DNSSEC and beyond
bySam Bowne
 
DNS Over HTTPS by Michael Casadevall
byGlenn McKnight
 
DNS & DNSSEC
byAPNIC
 
Dns protocol design attacks and security
byMichael Earls
 
Tsig 17022011
byphosika sithisane
 
7 technical-dns-workshop-day3
byDNS Entrepreneurship Center
 
Dnssec root-lacnog
byMehmet Akcin
 
DNS Security (DNSSEC) With BIG-IP Global Traffic Manager
byDSorensenCPR
 
8 technical-dns-workshop-day4
byDNS Entrepreneurship Center
 
Internet and DNS evolution
byBill Miller
 
DNSSEC: How to deploy it, and why you should bother (ION Toronto 2011)
byInternet Society
 
DNSSEC: How to deploy it, and why you should bother (ION Toronto 2011)
byDeploy360 Programme (Internet Society)
 
Lamb dnssec
byErol Dizdar
 
AEP Netwrorks Keyper HSM & ICANN DNSSEC
byChin Wan Lim
 
Building Trust into DNS: Key Strategies
bySafeNet
 

More from Deploy360 Programme (Internet Society)

PPTX
ION Malta - IETF Update
byDeploy360 Programme (Internet Society)
 
PPTX
ION Belgrade - ISOC Serbia Belgrade Chapter Presentation
byDeploy360 Programme (Internet Society)
 
PPTX
ION Malta - Introduction to DNSSEC
byDeploy360 Programme (Internet Society)
 
PPTX
ION Belgrade - IETF Update
byDeploy360 Programme (Internet Society)
 
PPTX
ION Durban - What's Happening at the IETF?
byDeploy360 Programme (Internet Society)
 
PPTX
ION Belgrade - MANRS by Serbian Open eXchange (SOX)
byDeploy360 Programme (Internet Society)
 
PPTX
ION Malta - DANE: The Future of TLS
byDeploy360 Programme (Internet Society)
 
PDF
ION Malta - Seeweb Thoughts on IPv6 Transition
byDeploy360 Programme (Internet Society)
 
PPTX
ION Malta - Opening Slides
byDeploy360 Programme (Internet Society)
 
PPTX
ION Belgrade - Closing Slides
byDeploy360 Programme (Internet Society)
 
PDF
ION Malta - Seeweb Why MANRS is good for you
byDeploy360 Programme (Internet Society)
 
PPTX
ION Durban - How peering behaviour affects growth of the internet
byDeploy360 Programme (Internet Society)
 
PPTX
ION Malta - IANA Transition Roles & Accountability
byDeploy360 Programme (Internet Society)
 
PDF
AusNOG - Two Years of Good MANRS
byDeploy360 Programme (Internet Society)
 
PPTX
ION Malta - Closing Slides
byDeploy360 Programme (Internet Society)
 
PPTX
ION Malta - MANRS Introduction
byDeploy360 Programme (Internet Society)
 
PDF
ION Malta - IPv6 Case Study: Finland
byDeploy360 Programme (Internet Society)
 
PPTX
ION Belgrade - Opening Slides
byDeploy360 Programme (Internet Society)
 
PDF
ION Belgrade - Jordi Palet Martinez IPv6 Success Stories
byDeploy360 Programme (Internet Society)
 
PPTX
ION Durban - Introduction to ISOC Gauteng Chapter
byDeploy360 Programme (Internet Society)
 
ION Malta - IETF Update
byDeploy360 Programme (Internet Society)
 
ION Belgrade - ISOC Serbia Belgrade Chapter Presentation
byDeploy360 Programme (Internet Society)
 
ION Malta - Introduction to DNSSEC
byDeploy360 Programme (Internet Society)
 
ION Belgrade - IETF Update
byDeploy360 Programme (Internet Society)
 
ION Durban - What's Happening at the IETF?
byDeploy360 Programme (Internet Society)
 
ION Belgrade - MANRS by Serbian Open eXchange (SOX)
byDeploy360 Programme (Internet Society)
 
ION Malta - DANE: The Future of TLS
byDeploy360 Programme (Internet Society)
 
ION Malta - Seeweb Thoughts on IPv6 Transition
byDeploy360 Programme (Internet Society)
 
ION Malta - Opening Slides
byDeploy360 Programme (Internet Society)
 
ION Belgrade - Closing Slides
byDeploy360 Programme (Internet Society)
 
ION Malta - Seeweb Why MANRS is good for you
byDeploy360 Programme (Internet Society)
 
ION Durban - How peering behaviour affects growth of the internet
byDeploy360 Programme (Internet Society)
 
ION Malta - IANA Transition Roles & Accountability
byDeploy360 Programme (Internet Society)
 
AusNOG - Two Years of Good MANRS
byDeploy360 Programme (Internet Society)
 
ION Malta - Closing Slides
byDeploy360 Programme (Internet Society)
 
ION Malta - MANRS Introduction
byDeploy360 Programme (Internet Society)
 
ION Malta - IPv6 Case Study: Finland
byDeploy360 Programme (Internet Society)
 
ION Belgrade - Opening Slides
byDeploy360 Programme (Internet Society)
 
ION Belgrade - Jordi Palet Martinez IPv6 Success Stories
byDeploy360 Programme (Internet Society)
 
ION Durban - Introduction to ISOC Gauteng Chapter
byDeploy360 Programme (Internet Society)
 

ION San Diego - ARIN Support for DNSSEC and RPKI

  • 1.
    ARIN Support for DNSSECand RPKI ION San Diego 11 December 2012 Pete Toscano, ARIN
  • 2.
    2 DNS and BGP • They have been around for a long time. •  DNS: 1982 •  BGP: 1989 •  They are not very secure. •  Methods for securing them exist.
  • 3.
    3 DNSSEC •  Domain NameSystem Security Extensions •  Took a while to implement -- •  Design work started in 1993 at IETF 28. •  The root zone signed: July 15th, 2010.
  • 4.
    4 DNSSEC •  Designed toverify data integrity and authenticity. •  Does not prevent data snooping. •  Generally, that first point outweighs these others.
  • 5.
    5 DNSSEC •  DNSSEC isan overlay on top of DNS, not a replacement. •  Uses public key cryptography and a chain of trust similar to X.509 certificates.
  • 6.
    6 DNSSEC •  Adds sixnew RR types and extension mechanisms for DNS (EDNS). •  DNSKEY •  DS •  RRSIG •  NSEC •  NSEC3 •  NSEC3PARM
  • 7.
    7 DNSSEC •  DNSKEY: Thepublic keys. Either a Key Signing Key (KSK) or Zone Signing Key (ZSK). •  DS: Delegation Signer. Hashes and identifies the KSK of a signed, delegated child zone.
  • 8.
    8 DNSSEC •  RRSIG: ResourceRecord Signature. Every RRset for each name has a single RRSIG. There are two exceptions: •  NS records at delegation points. •  Glue records. •  DNSKEY RRSIGs are signed by the KSK, all others by ZSK.
  • 9.
    9 DNSSEC •  NSEC/NSEC3: NextSecure Record / Next Secure Record version 3. •  Used to prove the non-existence of a resource record.
  • 10.
    10 DNSSEC • A simple example of securing a zone. example.com. SOA [SOA STUFF]! NS ns! MX 10 mail! mail A 128.66.0.100! AAAA 2001:db8::100! ns A 128.66.0.10! AAAA 2001:db8::10! sub NS ns.sub! ns.sub A 128.66.10.10! AAAA 2001:db8:10::10! !
  • 11.
    11 DNSSEC • Throw in the keys... example.com. SOA [SOA STUFF]! NS ns! MX 10 mail! DNSKEY 256 [DNSKEY STUFF]; ZSK! DNSKEY 257 [DNSKEY STUFF]; KSK! mail A 128.66.0.100! AAAA 2001:db8::100! ns A 128.66.0.10! AAAA 2001:db8::10! sub NS ns.sub! ns.sub A 128.66.10.10! AAAA 2001:db8:10::10!
  • 12.
    12 DNSSEC •  Add theNSEC records so that all gaps are accounted for... example.com. SOA [SOA STUFF]! example.com. NS ns! example.com. MX 10 mail! example.com. DNSKEY 256 [DNSKEY STUFF]; ZSK! example.com. DNSKEY 257 [DNSKEY STUFF]; KSK! example.com. NSEC mail.example.com. SOA NS MX DNSKEY NSEC! mail.example.com. A 128.66.0.100! mail.example.com. AAAA 2001:db8::100! mail.example.com. NSEC ns.example.com. A AAAA NSEC! ns.example.com. A 128.66.0.10! ns.example.com. AAAA 2001:db8::10! ns.example.com. NSEC sub.example.com. A AAAA NSEC! sub.example.com. NS ns.sub! sub.example.com. NSEC example.com. NS NSEC! ns.sub.example.com. A 128.66.10.10! ns.sub.example.com. AAAA 2001:db8:10::10! • NSEC doesn’t do glue. • Zone enumeration? That’s where NSEC3 comes in.
  • 13.
    DNSSEC 13 •  Sign each label’s RRset and update NSECs... example.com. SOA [SOA STUFF]! example.com. RRSIG SOA [RRSIG STUFF]! example.com. NS ns! example.com. RRSIG NS [RRSIG STUFF]! example.com. MX 10 mail! example.com. RRSIG MX [RRSIG STUFF]! example.com. DNSKEY 256 [DNSKEY STUFF]; ZSK! example.com. DNSKEY 257 [DNSKEY STUFF]; KSK! example.com. RRSIG DNSKEY [RRSIG STUFF]! example.com. NSEC mail.example.com. SOA NS MX DNSKEY NSEC RRSIG! example.com. RRSIG NSEC [RRSIG STUFF]! mail.example.com. A 128.66.0.100! mail.example.com. RRSIG A [RRSIG STUFF]! mail.example.com. AAAA 2001:db8::100! mail.example.com. RRSIG AAAA [RRSIG STUFF]! mail.example.com. NSEC ns.example.com. A AAAA NSEC RRSIG! mail.example.com. RRSIG NSEC [RRSIG STUFF]! ns.example.com. A 128.66.0.10! ns.example.com. RRSIG A [RRSIG STUFF]! ns.example.com. AAAA 2001:db8::10! ns.example.com. RRSIG AAAA [RRSIGSTUFF]! ns.example.com. NSEC sub.example.com. A AAAA NSEC RRSIG! ns.example.com. RRSIG NSEC [RRSIG STUFF]! sub.example.com. NS ns.sub! sub.example.com. NSEC example.com. NS NSEC RRSIG! sub.example.com. RRSIG NSEC [RRSIG STUFF]! ns.sub.example.com. A 128.66.10.10! ns.sub.example.com. AAAA 2001:db8:10::10!
  • 14.
    DNSSEC 14 •  Signed delegations. Add DS records and update NSEC and RRSIGs. example.com. SOA [SOA STUFF]! example.com. RRSIG SOA [RRSIG STUFF]! example.com. NS ns! example.com. RRSIG NS [RRSIG STUFF]! example.com. MX 10 mail! example.com. RRSIG MX [RRSIG STUFF]! example.com. DNSKEY 256 [DNSKEY STUFF]; ZSK! example.com. DNSKEY 257 [DNSKEY STUFF]; KSK! example.com. RRSIG DNSKEY [RRSIG STUFF]! example.com. NSEC mail.example.com. SOA NS MX DNSKEY NSEC RRSIG! example.com. RRSIG NSEC [RRSIG STUFF]! mail.example.com. A 128.66.0.100! mail.example.com. RRSIG A [RRSIG STUFF]! mail.example.com. AAAA 2001:db8::100! mail.example.com. RRSIG AAAA [RRSIG STUFF]! mail.example.com. NSEC ns.example.com. A AAAA NSEC RRSIG! mail.example.com. RRSIG NSEC [RRSIG STUFF]! ns.example.com. A 128.66.0.10! ns.example.com. RRSIG A [RRSIG STUFF]! ns.example.com. AAAA 2001:db8::10! ns.example.com. RRSIG AAAA [RRSIG STUFF]! ns.example.com. NSEC sub.example.com. A AAAA NSEC RRSIG! ns.example.com. RRSIG NSEC [RRSIG STUFF]! sub.example.com. NS ns.sub! sub.example.com. DS [Hash of sub’s KSK]! sub.example.com. RRSIG DS [RRSIG STUFF]! sub.example.com. NSEC example.com. NS DS NSEC RRSIG! sub.example.com. RRSIG NSEC [RRSIG STUFF]! ns.sub.example.com. A 128.66.10.10! ns.sub.example.com. AAAA 2001:db8:10::10!
  • 15.
    15 DNSSEC •  What todo with all this extra data? •  Publishing the signed data is only half the battle. •  The authoritative DNS responses need to be validated.
  • 16.
    16 DNSSEC •  Response validationinvolves following a chain of trust from the trust anchor to the answer received. •  Typically, the root zone’s KSK == Trust Anchor
  • 17.
    17 DNSSEC •  The backboneof the chain of trust is the DS, DNSKEY, RRSIG interaction. •  Trust travels from the parent zone down to the child zone. Repeat until the target zone is found. •  Start at the trust anchor’s zone.
  • 18.
    18 DNSSEC RRSIG! KSK DNSKEY! ZSK DNSKEY! Parent Zone RRSIG! ...! DS! RRSIG! KSK DNSKEY! Child Zone ZSK DNSKEY! RRSIG! ...! DS!
  • 19.
    19 DNSSEC •  Once thetarget child zone is found, the ZSK is used the verify the appropriate RRSIG. •  If the question cannot be answered, the ZSK can be used to verify the appropriate NSEC/NSEC3 RRSIG. •  If the answer can’t be verified, then NXDOMAIN status is returned.
  • 20.
    20 DNSSEC •  From aDNS publisher’s point of view, DNSSEC can greatly expand the size of zones. •  On average, responses are larger. •  Management of the keys can be tricky. •  Protects the data, not the headers. •  Does nothing to protect the stub resolver to recursive resolver communication.
  • 21.
    21 DNSSEC •  At ARIN,we currently sign our v4 /8s and v6 /12 and /24s. •  ARIN Online allows members to add DS records to the zones their resources are delegated from.
  • 22.
    22 DNSSEC •  DNSSEC Analyzer: http://dnssec-analyzer.verisignlabs.com •  DNSViz: http://dnsviz.net •  ldns / Drill: http://www.nlnetlabs.nl/projects/ldns/ •  DNSSEC Validator: http://www.dnssec-validator.cz/ (FF Plugin) •  Other Tools: https://www.dnssec-deployment.org/wiki/ index.php/Tools_and_Resources
  • 23.
  • 24.
    24 “The inter-domain routingprotocol BGP was created when the Internet environment had not yet reached the present, contentious state. Consequently, the BGP design did not include protections against deliberate or accidental errors that could cause disruptions of routing behavior.” • Intro to RFC 4272 “BGP Security Vulnerabilities Analysis” January 2006
  • 25.
    25 RPKI Thisis the basic problem... Send  a  packet   to   209.85.128.100   I  have   209.85.128.0/17  
  • 26.
    26 RPKI 165.135.0.2 209.85.128.100 AS100   AS200   AS300  
  • 27.
    27 RPKI 165.135.0.2 209.85.128.100 AS100   AS200   AS300   AS666   209.85.128.100
  • 28.
    28 RPKI •  April 1997– AS 7007 announced paths for all of the internet to themselves. •  Feb. 24, 2008 –Pakistan Telecom announced a part of YouTube’s address blocks. •  April 2010 - China Telecom mis-originated about 15% of Internet address blocks affecting I-root. •  Nov. 2012 – Google was unavailable some places via route leak from Moratel.
  • 29.
    29 RPKI 165.135.0.2 209.85.128.100 AS100   AS200   AS300   Phase 1: Origin Validation (requires RPKI) Phase 2: Path Validation (still in draft phase)
  • 30.
    30 RPKI •  Resource PublicKey Infrastructure •  RPKI attaches ASNs and IP address blocks to X.509 v3 certs. •  These resource certs are signed by the resource parent.
  • 31.
    31 RPKI IANA! Resource Allocation Hierarchy AFRINIC! APNIC! ARIN! LACNIC! RIPE NCC! ISP 1! ISP 2! ISP 4! ISP 3! ISP! ISP! ISP!
  • 32.
    32 Certificates RPKI IANA! issued to match allocations. AFRINIC! APNIC! ARIN! LACNIC! RIPE NCC! Issuer: ARIN! Subject: ARIN! Resources: 192.0.0.0/8! ISP 1! ISP 2! ISP 4! Key Info: <arin-key-pub>! Signed: <arin-key-priv>! ISP 3! ISP! ISP! ISP!
  • 33.
    33 Certificates RPKI IANA! issued to match allocations. AFRINIC! APNIC! ARIN! LACNIC! RIPE NCC! Issuer: ARIN! Issuer: ARIN! Subject: ISP1! Subject: ARIN! Resources: 192.2.0.0/16! Resources: 192.0.0.0/8! Key Info: <isp1-key-pub>! ISP 1! ISP 2! ISP 4! Key Info: <arin-key-pub>! Signed: <arin-key-priv>! Signed: <arin-key-priv>! ISP 3! ISP! ISP! ISP!
  • 34.
    34 Certificates RPKI IANA! issued to match allocations. AFRINIC! APNIC! ARIN! LACNIC! RIPE NCC! Issuer: ARIN! Issuer: ARIN! Subject: ISP1! Subject: ARIN! Resources: 192.2.0.0/16! Resources: 192.0.0.0/8! Key Info: <isp1-key-pub>! ISP 1! ISP 2! ISP 4! Key Info: <arin-key-pub>! Signed: <arin-key-priv>! Signed: <arin-key-priv>! Issuer: ISP1! Subject: ISP3! Resources: 192.2.200.0/24! Key Info: <isp3-key-pub>! Signed: <isp1-key-priv>! ISP 3! ISP! ISP! ISP!
  • 35.
    35 RPKI •  Address holdersissue Route Origin Authorizations (ROAs).
  • 36.
    36 Certificates RPKI IANA! issued to match allocations. AFRINIC! APNIC! ARIN! LACNIC! RIPE NCC! Issuer: ARIN! Issuer: ARIN! Subject: ISP1! Subject: ARIN! Resources: 192.2.0.0/16! Resources: 192.0.0.0/8! Key Info: <isp1-key-pub>! ISP 1! ISP 2! ISP 4! Key Info: <arin-key-pub>! Signed: <arin-key-priv>! Signed: <arin-key-priv>! Issuer: ISP1! Subject: ISP3! Resources: 192.2.200.0/24! Key Info: <isp3-key-pub>! Signed: <isp1-key-priv>! ISP 3! ISP! ISP! ISP!
  • 37.
    37 Certificates RPKI IANA! issued to match allocations. AFRINIC! APNIC! ARIN! LACNIC! RIPE NCC! Issuer: ARIN! Issuer: ARIN! Subject: ISP1! Subject: ARIN! Resources: 192.2.0.0/16! Resources: 192.0.0.0/8! Key Info: <isp1-key-pub>! ISP 1! ISP 2! ISP 4! Key Info: <arin-key-pub>! Signed: <arin-key-priv>! Signed: <arin-key-priv>! Issuer: ISP1! Subject: ISP3! Resources: 192.2.200.0/24! Key Info: <isp3-key-pub>! Signed: <isp1-key-priv>! ISP 3! ISP! ISP! ISP! Issuer: ISP3! ROA: “ISP 3 permits ASN 123 to originate its Subject: ISP3-EE! 192.2.200.0/24 network space.”! Resources: 192.2.200.0/24! ! Key Info: <isp3EE-key-pub>! ! Signed: <isp3-key-priv>! ß Attached! Signed, <isp3EE-key-priv>! !
  • 38.
    38 RPKI •  Two RPKIimplementation types: •  Delegated: Each participating node becomes a CA and runs their own RPKI repository, delegated to by the parent CA. •  Hosted: The RIR runs the CA functionality for interested participants.
  • 39.
    39 RPKI •  For mostparticipants, running a CA would be an insurmountable obstacle to the implementation of RPKI. •  This is why the hosted option exists.
  • 40.
    40 RPKI •  Regardless ofthe method used, the RPKI repositories are published. •  TAL: Trust Anchor Locator •  Points to the rsync entry point of that repo. •  Includes that repo’s public key.
  • 41.
    41 RPKI •  Reliant thirdparties would gather all relevant TALs. •  Get all of the RPKI repos. •  Validate, validate, validate.
  • 42.
    42 RPKI •  Once wehave validated ROAs and the backing resource hierarchy, what do we do?
  • 43.
    43 RPKI •  Once wehave validated ROAs and the backing resource hierarchy, what do we do? •  Use ROAs to weight BGP path announcements as they’re received.
  • 44.
    44 RPKI 165.135.0.2 209.85.128.100 AS100   AS200   AS300   AS666   209.85.128.100
  • 45.
    45 RPKI 165.135.0.2 209.85.128.100 AS100   AS200   AS300  
  • 46.
    46 RPKI “Only AS 300 can originate 209.85.128.0/24 network space.”! 165.135.0.2 209.85.128.100 AS100   AS200   AS300  
  • 47.
    47 RPKI “Only AS 300 can originate my 209.85.128.0/24 network space.”! 165.135.0.2 209.85.128.100 AS100   AS200   AS300   AS666   209.85.128.100
  • 48.
    48 RPKI “Only AS 300 can originate my 209.85.128.0/24 network space.”! 165.135.0.2 209.85.128.100 AS100   AS200   AS300   AS666   209.85.128.100
  • 49.
    49 RPKI •  Border routersuse the RPKI with the RPKI/Router protocol. •  http://tools.ietf.org/html/draft-ietf- sidr-rpki-rtr •  Implemented on Cisco IOS and Quagga. JunOS recently added.
  • 50.
    50 RPKI •  Offload validationand origin evaluation to some other box. •  “Valid”, “Invalid”, “Unknown” •  What’s done with these values is up to the local policy.
  • 51.
    51 RPKI •  As withDNSSEC, the more buy in, the better the security. •  Be a good netizen: certify your resources. •  Even better: publish ROAs. •  Be the best happy shiny: validate route origins as support allows.
  • 52.
    52 RPKI @ ARIN • Only hosted model is currently implemented. •  The delegated model will be released in the not-too-distant future. •  Non-repudiation requirement. •  Third parties need to sign a RPA before getting the TAL.
  • 53.
    53 Future of RPKI • Single TAL. •  Inter-RIR transfers. •  Integrated with a path validation system.
  • 54.