A: Please refer to the  Indiana GigaPOP BGP Communities documentation.

A: The cost for the scrubbing service will be shared between Indiana GigaPOP members, including I-Light.   Once we know how many of the GigaPOP members are going to participate we will spread the costs proportionally.  We’ll be InTouch with the individual GigaPOP members to discuss these costs in more detail in the near future.

A: We think so, initially the scrubbing service will be a manual action by either the Indiana GigaPOP and I-Light Network Engineers or members themselves via BGP Communities.  A future automated process would need to take into account prefixes which would be excluded.  Considerations may need to be made for frequency of Opt-In/Opt-Out changes as well as time required to process changes.

A: Members may Opt-In or Opt-Out by notifying the appropriate NOC; Indiana GigaPOP or I-Light.  **Please note the anticipated turnaround time to be three (3) days to change a members status.

A: No.  BGP allows the Indiana GigaPOP or I-Light member to initiate the scrubbing service independently of Indiana GigaPOP or I-Light Engineers.  Without BGP, a manual process will be implemented by Indiana GigaPOP or I-Light Engineers.

A: Yes!  Indiana GigaPOP and I-Light Engineers can help in three ways.

1. Documentation of examples.  Please refer to DDoS Mitigation (Scrubbing) Service Scenario and Configuration Examples.
2. Proactive discussion on BGP Configuration
3. Reactive assistance for BGP Configuration Verification

A:  The NOC for Indiana GigaPOP or I-Light will send targeted notifications to member institutions when an attack is detected, when mitigation (scrubbing) is implemented and when the attack has subsided.

A: The DDoS Scrubbing service only functions on commodity traffic from transit providers.  Currently no active transit providers support Multicast.  Multicast traffic should not be affected internal to the Indiana GigaPOP or I-Light, although public senders or receives can still be attacked and external traffic to those hosts may be scrubbed.

A: Yes. Measured increased RTT (round trip time) was between 22 and 55ms, dependent on the external endpoint and path to Indiana GigaPOP or I-Light member.  To provide reference, latency from Indiana to the West coast is approximately 48ms round trip, to the East coast is approximately 22ms round trip.

A: At this time, our thought is yes.  We feel sharing attack analytics will be valuable to the overall community on several fronts.  Sharing the attack information in some form or another will allow the member community to gain exposure to different attack types and will aid in helping the member community learn how to protect their network and users.  We recognize that the attack information is sensitive and we understand the importance of this information not getting into the wrong hands to be used for nefarious purposes.  With that being said, our work continues on how to distribute the information securely.  We’ll be sure to provide more information on this front at things begin to solidify.

A: No. Initial attack analytics indicate most of the attacks span about 1 minute and sometimes repeat 2-3 times within a 15-minute window.  In these cases, the attack has subsided before anyone could actually react.  Reports on short attacks will be available to members.

A: Our plan is to notify members if an attack is occurring or has occurred lasting longer than 15 minutes (see previous question).  The notification to the members will be sent by the GlobalNOC.  The standard policy and language around notification is still being ironed out by the Engineering group and the Service Desk, but our thought is that we’ll notify on the following:

1. When an attack occurs and subsides within 15 minutes.
2. When an attack occurs lasting longer than 15 minutes.
3. When mitigation/scrubbing was initiated.
4. When the attack has subsided.

* For attacks lasting less than 15 minutes, members will receive a notification that an attack occurred and subsided, no mitigation/scrubbing occurred.

A: If the attack creates a situation where the commodity links become saturated, and if we get multiple complaints from other members notifying us that are being effected, then it’s our thought that we should disconnect the targeted member from the network until the issue is resolved.