ISP Working Group Internet Vulnerability

Summary & Discussion

Avi Freedman

Akamai Technologies

ISPWG: Background (1)

• 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.

ISPWG: Background (2)• 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.

ISPWG: Background (3)

• 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.

Key Recommendations (1)

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

Key Recommendations (2)

• 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

Personal Summary

• 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.

Working Group Summaries

• 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.

BGP & DNS WG (1)

• 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)

BGP & DNS WG (2)

• 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

Hardening WG (1)

• 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

Hardening WG (2)

• 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

Net Ops WG (1)

• 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

Net Ops WG (2)

• 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

Disaster Recovery WG (1)

• 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”

Disaster Recovery WG (2)

• 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

Coordination WG (1)

• 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)

Coordination WG (2)

• 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

Enforcement & Privacy WG (1)

• 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

Summary• 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?

Personal Summary (Revisit)

• Real IGP work done to prevent BGPOSPF leading to catastrophe would be a great step.

• Having community support for assembling a ‘net-wide 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.