Indiana GigaPOP NOC Support - DDoS Mitigation (Scrubbing) Service - Scenario and Configuraiton Examples

Please refer to these scenarios and configuraiton examples for guidance in triggering the DDoS Mitigation (Scrubbing) Service by adding a BGP community to your prefix announcement.  These examples are applicable to membes who administer their own BGP configuraiton.  Indiana GigaPOP Engineers are available to assist with configuration, either proactively or reactively, providing recommendations as needed to our members.

Note: The examples below utilize RFC1918 (IPv4 Private IP Addressing) to illustrate the configuraton required to trigger DDoS Mitigation (Scrubbiing).  Please adjust the prefix addressing appropriately for your insttitution.

Scenario #1

Member typically announces varous prefix lengths, from a /16 to a /23 to the Indiana GigaPOP.  In the scenario with a DDoS detection against a specific host, the /16 would remain announced to the Indiana GigaPOP Commodity Transit and Peer providers with a more specific /24 announced through Internet2/Radware for DDoS Mitigation (Scrubbing).  More specific prefixes will force traffic to the specific host within the prefix through the DDoS Mitigation (Scrubbing) Service.

A possible BGP policy configuration for a member's peer defintion to the Indiana Gigapop.

Cisco

!
ip prefix-list MEMBER seq 5 permit 192.168.0.0/16
!
route-map OUT permit 10
 match ip address prefix-list MEMBER
!
route-map OUT deny 100
!

Juniper

policy-options {
    prefix-list MEMBER {
        192.168.0.0/16;
    }
    policy-statement OUT {
        term ANNOUNCE {
            from {
                prefix-list MEMBER;
            }
            then accept;
        }
        term REJECT {
            then reject;
        }
    }
}

Assuming a DDoS attack is occurring against 192.168.73.33. The member would announce 192.168.73.0/24 with the added DDOS BGP community.

Cisco

!
ip prefix-list MEMBER seq 5 permit 192.168.0.0/16
ip prefix-list MEMBER-DDOS seq 5 permit 192.168.73.0/24
!
route-map OUT permit 5
 match ip address prefix-list MEMBER-DDOS
 set community 19782:666 additive
!
route-map OUT permit 10
 match ip address prefix-list MEMBER
!
route-map OUT deny 100
!

Juniper

policy-options {
    community DDOS {
        members 19782:666;
    }
    prefix-list MEMBER-DDOS {
        192.168.73.0/24;
    }
    policy-statement OUT {
        term ANNOUNCE-DDOS {
            from {
                prefix-list MEMBER-DDOS;
            }
            then {
            community add DDOS;
            accept;
            }
        }
        term ANNOUNCE {
            from {
                prefix-list MEMBER;
            }
            then accept;
        }
        term REJECT {
            then reject;
        }
    }
}

Scenario #2

Member typically announces a /24 to the Indiana GigaPOP.  In the scenario with a DDoS detection against a specific host, the /24 would would suppress the announce to Commodity Transit and Commodity Peer Networks, instead announcing the /24 through Internet2/Radware for DDoS Mitigation (Scrubbing). 

A possible BGP policy configuration for a member's peer defintion to the Indiana Gigapop.

Cisco

!
ip prefix-list MEMBER seq 5 permit 192.168.89.0/24
!
route-map OUT permit 10
 match ip address prefix-list MEMBER
!
route-map OUT deny 100
!

Juniper

policy-options {
    prefix-list MEMBER {
        192.168.89.0/24;
    }
    policy-statement OUT {
        term ANNOUNCE {
            from {
                prefix-list MEMBER;
            }
            then accept;
        }
        term REJECT {
            then reject;
        }
    }
}

Assuming a DDoS attack is occurring against 192.168.89.33. The member would add the DDoS BGP Community to their announcement of 192.168.73.0/24.

Cisco

!
ip prefix-list MEMBER seq 5 permit 192.168.0.0/16
!
route-map OUT permit 10
 match ip address prefix-list MEMBER
 set community 19782:666 additive
!
route-map OUT deny 100
!

Juniper

policy-options {
    community DDOS {
        members 19782:666;
    }
    policy-statement OUT {
        term ANNOUNCE {
            from {
                prefix-list MEMBER;
            }
            then {
            community add DDOS;
            accept;
            ]
        }
        term REJECT {
            then reject;
        }
    }
}