Checklists and References

Publishing information - checklist

There are many places where information can be published. This summary can be used as a checklist when publishing and updating information, and can be included in your organisation’s processes and procedures.

• For the AFRINIC, APNIC and RIPE NCC region:

  • Publish contact information for roles/departments as ROLE objects Optionally: create PERSON objects for staff members and link from the ROLE
  • Create IRR objects and refer to the correct POCs from those objects and document your routing policy:
    • INETNUM and INET6NUM
      • admin-c: refer to your IPAM administrators
      • tech-c: refer to the administrators of the systems on this network
    • AUT-NUM
      • admin-c: refer to your peering coordinators
      • tech-c: refer to your NOC
      • mp-import/mp-export: document your BGP connections
    • ROUTE and ROUTE6
      • remarks: document contacts for your NOC, abuse desk, etc.
      • ping-hdl: refer to your NOC
  • Create RPKI ROAs for all prefixes that you announce from your ASNs
  • Publish your peering locations, policy and contacts in PeeringDB
  • Publish your peering locations, policy and contacts on your website
  • Publish your NOC and abuse contacts on your website

• For the LACNIC region:

  • Publish contact information for roles/departments as POC objects
  • Publish contact information for the Organizations holding resources (directly allocated by LACNIC or re-allocated by a LIR)
  • Publish the DNS that provides the reverse resolution for IP blocks
  • Refer to the correct POCs for you resources: tech-c: refer to your IPAM administrators abuse-c: refer to your network abuse desk
  • Create RPKI ROAs for all prefixes that you announce from your ASNs
  • Publish your peering locations, policy and contacts in PeeringDB
  • Publish your peering locations, policy and contacts on your website
  • Publish your NOC and abuse contacts on your website

• For the ARIN region:

  • Publish contact information for roles/departments as POC objects

  • Refer to the correct POCs from your resources

    • NET
      • NOC POC: refer to your NOC and optionally sysadmins
      • Tech POC: refer to your IPAM administrators
      • Abuse POC: refer to your systems abuse desk
    • ASN
      • NOC POC: refer to your NOC and peering coordinators
      • Tech POC: refer to your IPAM administrators
      • Abuse POC: refer to your network abuse desk

  • Create IRR objects and refer to the correct POCs from those objects and document your routing policy:

    • INETNUM and INET6NUM
      • admin-c: refer to your IPAM administrators
      • tech-c: refer to the administrators of the systems on this network
    • AUT-NUM
      • admin-c: refer to your peering coordinators
      • tech-c: refer to your NOC
      • mp-import/mp-export: document your BGP connections
    • ROUTE and ROUTE6
      • remarks: document contacts for your NOC, abuse desk, etc.

  • Create RPKI ROAs for all prefixes that you announce from your ASNs

  • Publish your peering locations, policy and contacts in PeeringDB

  • Publish your peering locations, policy and contacts on your website

  • Publish your NOC and abuse contacts on your website

Validating information - checklist

Operating a network in a responsible way requires the validation of the traffic you and your customers send to the rest of the Internet, and validation of the routes that your upstreams, peers and customers announce to you. Failing to validate any of this makes your network vulnerable to route hijacks and a potential source of DDOS attack traffic.

• Apply ACLs and/or uRPF filtering to your customers’ connections
• Apply ACLs, uRPF and/or SAVI filtering to your own networks
• Use the information in the IRRs to filter routes that your neighbours announce to you
• Verify the routes in your routing table against the RPKI ROAs

Historical Background Materials

This document is built on decades of work by network and security professionals around the world who have developed, deployed, and communicated techniques which allow for a more robust Internet. The following materials capture some of the work this document is compiled upon:

• RFC2827 (BCP38) — Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing — http://www.ietf.org/rfc/rfc2827.txt
• SSAC004 — Securing the Edge — http://www.icann.org/committees/security/sac004.txt
• SSAC008 — DNS Distributed Denial of Service (DDoS) Attacks — http://www.icann.org/committees/security/dns-ddos-advisory-31mar06.pdf
• Spoofer Project — https://spoofer.caida.org/
• RFC3024 — Reverse Tunneling for Mobile IP, revised — ftp://ftp.rfc-editor.org/in-notes/rfc3024.txt
• ISOC Anti-Spoofing Page — http://www.internetsociety.org/deploy360/anti-spoofing/
• "Network Hygiene Pays Off": The Business Case for IP Source Address Verification — Joao Luis Silva Damas & Daniel Karrenberg — https://www.ripe.net/publications/docs/ripe-432
• "RIPE Anti-Spoofing Task Force HOW-TO" — https://www.ripe.net/publications/docs/ripe-431
• Comparative Evaluation of Spoofing Defenses — Ezra Kissel (University of Delaware) and Jelena Mirkovic (USC/ISI)
• Understanding the Efficacy of Deployed Internet Source Address Validation Filtering — Robert Beverly (MIT CSAIL), Arthur Berger (MIT CSAIL), Young Hyun (CAIDA), k claffy (CAIDA)
• RFC 4948 — Report from the IAB workshop on Unwanted Traffic, March 9-10, 2006

Acknowledgements

The main authors of this document are David Freedman, Brian Foust, Barry Greene, Ben Maddison, Andrei Robachevsky, Job Snijders and Sander Steffann. We also thank Mechior Aelmans, Kevin Chege, Anirban Datta, Will van Gulik, Jakob Heitz and Aris Lambrianidis, Flavio Luciani, Kevin Meynell, Michelle Opiyo, Lia Solis, Simon Mayoye, Greg Hankins, Florian Hibler and Massimiliano Stucchi for their review and contributions to this document.