Bi-Lateral Security Management Framework (a.k.a. DDoS peering) · 2017. 10. 3. · •Max-prefix N,...

13
1 15 Bi-Lateral Security Management Framework (a.k.a. DDoS peering) CenturyLink & AT&T Nimrod Levy, Don Smith, John Schiel [email protected], [email protected] , [email protected] of Bi-Lateral Security Management Framework (a.k.a DDoS peering)

Transcript of Bi-Lateral Security Management Framework (a.k.a. DDoS peering) · 2017. 10. 3. · •Max-prefix N,...

Page 1: Bi-Lateral Security Management Framework (a.k.a. DDoS peering) · 2017. 10. 3. · •Max-prefix N, alert for % of N, tear down at N+1 •Consistency with redundant announcements

1 15

Bi-Lateral Security Management Framework (a.k.a. DDoS peering)

CenturyLink & AT&T

Nimrod Levy, Don Smith, John Schiel

[email protected], [email protected] , [email protected]

of Bi-Lateral Security Management Framework (a.k.a DDoS peering)

Page 2: Bi-Lateral Security Management Framework (a.k.a. DDoS peering) · 2017. 10. 3. · •Max-prefix N, alert for % of N, tear down at N+1 •Consistency with redundant announcements

2 15 2 15

LEXICON

Inter-ISP Flowspec

• Flowspec announcements initiated by a DDoS peer to drop attack traffic towards a victim ip

Unwanted traffic

• Traffic to be filtered by one ISP for another ISP

DDoS peering

• An ISP is dropping “unwanted traffic” for another

Peer

• Settlement-free peer

of Bi-Lateral Security Management Framework (a.k.a DDoS peering)

Page 3: Bi-Lateral Security Management Framework (a.k.a. DDoS peering) · 2017. 10. 3. · •Max-prefix N, alert for % of N, tear down at N+1 •Consistency with redundant announcements

3 15 3 15

BACKGROUND, ASSUMPTIONS AND CONTEXT

• Provides a process for peer networks to exchange filtering requests

• Between peering networks

• A relationship/environment for reciprocal benefits

• Institutional, not personal -> consistent approach

of Bi-Lateral Security Management Framework (a.k.a DDoS peering)

Page 4: Bi-Lateral Security Management Framework (a.k.a. DDoS peering) · 2017. 10. 3. · •Max-prefix N, alert for % of N, tear down at N+1 •Consistency with redundant announcements

4 15 4 15

REASONS TO INITIATE OUTREACH TO PEER

• Significant impact on customer/victim or infrastructure of the requesting network

• Significant benefit to the notified network

• Convey Network hygiene recommendations

• Management of vulnerabilities

• Pre-Requisite: Requesting network has implemented reasonable mitigations on its own network

of Bi-Lateral Security Management Framework (a.k.a DDoS peering)

Page 5: Bi-Lateral Security Management Framework (a.k.a. DDoS peering) · 2017. 10. 3. · •Max-prefix N, alert for % of N, tear down at N+1 •Consistency with redundant announcements

5 15 5 15

DDoS Peering Diagram

of Bi-Lateral Security Management Framework (a.k.a DDoS peering)

Page 6: Bi-Lateral Security Management Framework (a.k.a. DDoS peering) · 2017. 10. 3. · •Max-prefix N, alert for % of N, tear down at N+1 •Consistency with redundant announcements

6 15 6 15

REQUESTS : INITIATING, AUTHENTICATING, VERIFYING

• Must have AAA and CIA basic concepts.

• Not just Authenticated, Authorized and Accounting required − Confidentiality

− Integrity

− Availability

• Methods of secure filtering requests − BGP route announcements / inter-ISP Flowspec

− Call using pre-established points of contact

− EMAIL to a NOC/SOC common alias

− Ticketing system

− Other (TBD in individual frameworks)

of Bi-Lateral Security Management Framework (a.k.a DDoS peering)

Page 7: Bi-Lateral Security Management Framework (a.k.a. DDoS peering) · 2017. 10. 3. · •Max-prefix N, alert for % of N, tear down at N+1 •Consistency with redundant announcements

7 15 7 15

TYPES/ACTION SUPPORTED (PER PEER)

• “standard 5-tuple” + ICMP

• Available TYPES − 1: Dest Prefix 2: Src Prefix 3: IP Protocol

− 4: Port Type 5: Dest port 6: Src port

− 7: ICMP type 8: ICMP code 9: TCP flags

− 10: Packet LEN 11: DSCP 12: Fragment

• Initial types 1,3,5,6,7,8.

• Actions allowed -> drop

• Justification?

of

Bi-Lateral Security Management Framework (a.k.a DDoS peering)

Page 8: Bi-Lateral Security Management Framework (a.k.a. DDoS peering) · 2017. 10. 3. · •Max-prefix N, alert for % of N, tear down at N+1 •Consistency with redundant announcements

8 15 8 15

RULES FOR ROUTE ADVERTISEMENTS

• Max-prefix N, alert for % of N, tear down at N+1

• Consistency with redundant announcements

• Duration is indefinite -> max-prefix withdraw then add

• Initial action drop packets

• Use BGPv4 for IPv4 and IPv6 flow routes

• NO_EXPORT, limit length /25 …/32

• Consistent community for this purpose

of Bi-Lateral Security Management Framework (a.k.a DDoS peering)

Page 9: Bi-Lateral Security Management Framework (a.k.a. DDoS peering) · 2017. 10. 3. · •Max-prefix N, alert for % of N, tear down at N+1 •Consistency with redundant announcements

9 15 9 15

RESPONSE FROM NOTIFIED NETWORK

• Implement block at any reasonable point between peers.

• Consider implementation of network hygiene practice

• Acknowledgement − We got your request

− We did something/somewhere

− Feed back loop

of Bi-Lateral Security Management Framework (a.k.a DDoS peering)

Page 10: Bi-Lateral Security Management Framework (a.k.a. DDoS peering) · 2017. 10. 3. · •Max-prefix N, alert for % of N, tear down at N+1 •Consistency with redundant announcements

10 15 10 15

OTHER CONSIDERATIONS

• Requests withdrawn/cancelled by requesting peer

• Limited to significant events

• Peer has no obligation, may terminate action any time at their discretion

• Both networks must assess collateral impacts

• Implement with peers on a bi-lateral basis

of Bi-Lateral Security Management Framework (a.k.a DDoS peering)

Page 11: Bi-Lateral Security Management Framework (a.k.a. DDoS peering) · 2017. 10. 3. · •Max-prefix N, alert for % of N, tear down at N+1 •Consistency with redundant announcements

11 15 11 15

BENEFITS OF THE PILOT/PROOF OF CONCEPT

• Expands ISPs ability to withstand large DDoS attacks

• DDoS response more efficient: − Institutional not personal relationship

− A pre-established/authenticated trust relationship

− Pre-negotiated and pre-defined processes

− Documented requests, specific data elements

• Additional benefit of not carrying unwanted traffic

of Bi-Lateral Security Management Framework (a.k.a DDoS peering)

Page 12: Bi-Lateral Security Management Framework (a.k.a. DDoS peering) · 2017. 10. 3. · •Max-prefix N, alert for % of N, tear down at N+1 •Consistency with redundant announcements

12 15 12 15

ISSUES/CONCERNS

• Legal/Public Policy/Regulatory

• Confidentiality concerns

• Reporting

of Bi-Lateral Security Management Framework (a.k.a DDoS peering)

Page 13: Bi-Lateral Security Management Framework (a.k.a. DDoS peering) · 2017. 10. 3. · •Max-prefix N, alert for % of N, tear down at N+1 •Consistency with redundant announcements

13 15 13 15

REFERENCE MATERIAL

• BCP 38 http://www.bcp38.info/index.php/Main_Page

• BCP 84 https://tools.ietf.org/html/bcp84

• UTRS http://www.team-cymru.org/UTRS/index.html

• DBHF community https://tools.ietf.org/html/rfc7999

• Flowspec − https://tools.ietf.org/html/rfc5575

− https://www.nanog.org/sites/default/files/tuesday_general_ddos_ryburn_63.16.pdf

of Bi-Lateral Security Management Framework (a.k.a DDoS peering)