Avi Freedman
Akamai Technologies

• In Jan 2002, Dick Clarke called a meeting of industry and government to cover Internet vulnerabilities in the hope of starting a process that would lead to identification of vulnerabilities and that would lead to recommendations for the cyberdefense plan.
• Clarke’s group works for/with both the National
Security Council and the Homeland Defense groups.

• From Feb-Apr, different groups formed and had teleconference and list discussions of the following issues:
– BGP & DNS
– Hardening the peering & router infrastructure
– Network ops & management
– Disaster recovery
– Inter-provider coordination
– Enforcement nad privacy
• The process was shepherded by Marj Gilbert from
Dick Clarke’s staff (the PCIPB) and by Marty
Lindner from CERT.

• The following assumptions were made:
– Poor software quality is a problem that must be addressed separately (not everyone agrees that this can be easily dismissed)
– Domestic vs. international issues are not easy to solve, so focus on domestic US first
– Information sharing (vulnerabilities, network data, etc) need to be protected from FOIA/kept proprietary.

• Establish ISP best practices
– Address accountability
– Filtering
– Access control and authentication
– Change control
– Personnel policies and procedures
– Standardized training
– Refer to NRIC & other processes

• Establish secure, real-time, crisis-available
ISP/Vendor/Gov’t channels
• Establish policy-based network management capabilities
• Have a master study to analyze and identify single points of failure (buildings, logical infrastructure, fiber) domestically and internationally
• Review law enforcement procedures; amend
FOIA/anti-trust, and provide immunity to ISPs for emergency disclosures and data submission, and to allow govt and industry to exchange info
• Create national Internet disaster management team

• The “barreling down the road” issues for providers to (finally) achieve proactive progress on are:
– Address accountability
– Filtering
– BGP vulnerabilities
• These are critical because there could be a move to regulate, legislate, or fund less than wise solutions.

• The following slides present VERY excerpted summaries of the groups’ reccomendations, mostly intended to cover the critical issues and provide flavor.
• One key question is how the NANOG community becomes involved and sanity-checks. Unclear that
IETF-ers are the right crowd for consensus – perhaps that concept needs to find tha NANOG crowd and then interact with the gov’t.

• Leader – Steve Blumenthal, Genuity
• Recommend (DNS):
– Best practices for DNS (not all on one /24, etc)
– Source address (packet) + ingress (route) filtering to prevent spoofing
– DNS server software, network, and geo diversity
– Finishing and implementing DNSSEC (+funding)

• Recommend (ctd):
– Best practices (max-prefix, dampening, etc)
– Explore IPSEC to sign & auth BGP routing data
– Complete Secure BGP & test in an operational environment
– Investigate feasibility of egress route filtering at peering points
– Design routers to better withstand DoS attacks
– Greater diversity of peering interconnection
– MD5 on BGP4 connections (help with RST attacks)
– Improve authentication of routing info

• Leader - Avi Freedman, Akamai
• Recommendations (short-term):
– Education & training on default initial configs
– Security at common facilities
– Filtering access to management & control planes
– Out-of-band access
– Investigate interconnection infrastructure diversity & options (NOT regulation)
– Login authentication
– Investigate insider-threat issues

• Recommendations (long-term):
– Router protection: Architecture & Configuration
– Continued investigation of diversity of interconnection infrastructure
– Continued work on better OOB deployment
– Awareness of data center devices & overlay networks
– Criticality of solving source address filtering
– Continued work on best practices

• Leader – Art Deacon, AT&T
• Recommendations (short-term):
– Network management should use one-time keys, crypto sums on software upgrades, strong AAA methods, avoid static passwords, and use encrypted management traffic with strong authentication
– Repetitive tasks should be automated and APIs such as
SNMP/XML for configuration should be available
– Protection of management flows via ACLs etc; logged and auditable management traffic/sessions
– Documented network access policy

• Recommendations (long-term):
– Continue work on policy-based network management capabilities
– IETF should work on requirement and standards for interoperability
– Address accountability is essential
– Migrate from SNMPv1 to SNMPv3
– Need to improve incident disclosure to help operators and vendors

• Leader – Surprise surprise (Sean Donelan, SBC)
• Recommendations:
– Set criteria for gov’t invovement
– Work on simulation & modeling
– Deal with vulnerabilities proactively
– Perform vulnerability assessments
– Work with NSTAC/NRIC
– Share information
– Define and practice the “Plan”

• Recommendations (ctd):
– Define skill sets needed
– Create “contact list” and methods
– Establish 24x7 Internet emergency management office
– Get ISPs involved with emergency preparedness
– Funding is needed
• Undecided issues:
– Priority communications for key individuals
– Restoration priorities
– Load shedding during periods of capacity shortages

• Leader – Kelly Cooper, Genuity
• Recommendations:
– Major: Establish and standardize communication channels between Internet-supporting sectors
– ISPs: Inter-ISP real-time communications, contact info, best practices forum, collect/maintain info (?ISP-ISAC,
?NCC-ISAC, ?NIST)
– Gov’t: Single focal point, contact info across ISPs and vendors, long-term plans, info-sharing network, continuity of operations (?IRC, ?NCC/NCS)

• Recommendations (ctd):
– Vendors (equipment): Single forum, operational best practices, reporting standards, common feature sets, timely communicaftions, training (NCC-ISAC, IT-
ISAC)
• Independents
– Disseminate best practices, provide advance notice of issues, pass vulnerability info, establish trusted ISP and
“correct sector” contacts

• Leader – John Ryan, AOL
• Recommendations:
– Meaningful info sharing is critical for dealing with any widespread threats, but legal impediments must be resolved:
• FOIA & Sunshine Laws
• Discovery provisions
• Lack of immunity for emergency disclosures & voluntary surveillance under USA/Patriot Act
• Statutory environments do not limit liability
• Coordination may require central training, investigative unit, access to states of resources, and simulation and cyber gaming

• A lot of government interest in Internet infrastructure vulnerabilities.
• Awareness of BGP limitations and of issues with lack of filtering.
• Please get involved and seek info/provide input.
• It’s critical that we as a community address filtering
(packet & route) and route authentication before solutions are imposed in some way (i.e. government requiring solution from all vendors). In particular, is there a lightweight in-addr based method that could be set up for describing authorized origin AS(s) for prefixes? Other lightweight solutions?

• Real IGP work done to prevent BGP 
OSPF leading to catastrophe would be a great step.
• Having community support for assembling a ‘netwide Origin-AS

Prefix mapping database is key to any route/packet filtering work. Real progress here could help stave off a S-BGP
“before its time” push.
– NOT talking about SWIP-type info
– NOR about IRR-type policy info?
– Store in in-addr?
– Something good enough to start is key.