CCDE Study Group October 2019
Date: May 30, 2019. Rev 0.
As a consultant and SME in network design from the T2-SP-Consortium, last week you received a report about the state of Internet routing system and security related incidents in the past year. That report stated that the number of incidents is rapidly growing as well as some advances in the future of securing the Internet exchange.
The report highlighted:
- +15k total security incidents
- +2k networks causing Internet security incidents
- +5k victims of security incidents derived from lack of Internet security measures
Being BGP route leak or hijacking the ones with most impact in the organizations. Because of this, consortium members are very worried and asked you for advice in checking and deploying the most efficient, large scope and cost effective measures to avoid events that may impact network availability.
In the case some measures were proposed to be implemented in the current network, that measures should not affect the business plans and ROI of the deployed infrastructure.
As a reference, you’ve been provided with a brief network diagram of the AS that are members of the network.
All members are customers of Tier-1 SPs. They use those services to exchange international traffic with customers of other AS, being that other AS members or not of the Consortium.
There is also common to have peering exchange with other providers of the same geographical area/country. These peering are based on equal exchange of traffic, and are free in case the difference in the amount of TB exchanged does not exceed in 20%. If that range is exceeded, then the SP that accepts the exceed of traffic should be economically compensated.
The rate of international customers is about 10% in each AS, so in order to provide international VPN services, they use transit carriers. Transit carrier interconnection technology as well as relationship between them is handled out of the Consortium contracts, so each AS can freely negotiate its own rates. For intra-consortium VPN services, the routing information exchange for international customers is done with 1 VRF per customer in the data plane and 1 BGP session between ASBR routers. The reason for this setup is to keep a harder control in the data plane between different AS.
Re: 1_Consultancy work
After some serious serious security incident that affected one AS of SP consortium they started to build a plan for hardening their network.
Your work towards hardening the T2-SP-Consortium members network starts here. You have been asked about what direction and measures should the members implement to increase network security and availability.
Do you need some other information to start working on this case?
- No, I have plenty of information
- Yes, I would need more information
In case you answered YES to the previous question, what additional information would you need? (Select 2 options)
- In-depth details about the incident
- SNMP logs from every device at the perimeter
- Description of the incident
- Security measures in place
- Encryption type used
Re: 2_Incident related information
Last incident report informed about prefix hijacking. The result was that traffic with origin and/or destination to one of our customers end up forwarded to a wrong AS.
About the security measures in place, we have recently deployed a BGP monitoring system to be able to detect and be able to respond as fast as possible to BGP attacks. This monitoring system monitors routing tables as well as privacy and security of our user base.
We incorporated recently automation at some extent to the infrastructure, so our developers coded some scripts to match bogons as well as to be able to interact with BGP configuration faster than our management team interacting with the CLI.
The same centralized automation system has been recently updated to implement AS path filtering. That way, if our monitoring system detects some kind of attack, we can accept or reject routes with some kind of characteristics in the AS path from our customers, providers or peers.
Are the measures capable of stopping those kind of attacks? (Select 1 option)
- Yes, should be enough
- No, they are not. I would recommend additional measures
- Yes, but probably there is some tuning needed
In case you selected “No”. What additional measures would you propose to help mitigate those attacks? (Select 1 option)
- Externalize security management in a NOC
- Perform prefix filtering
- Load balancers at the edge to redirect traffic to other AS member
Ok, where would you apply prefix filtering? (Select PINs in the picture)
Re: 3_Customer service
The prefix filtering measures you proposed worked very well and now we’ve deployed filtering with upstream providers, peers and customers to avoid any kind of redirection of traffic out of our AS for addressing originated in our respective autonomous systems.
Since we applied that, our customer service is opening more and more tickets with compliances from some of our customers.
We are sure that problem appeared after applying the filters to avoid the attacks. What do you think it could be the reason? (Select 2 options)
- Some of your clients may be attackers, so they are blocked
- Some of your clients are multihomed
- Some of your clients need to update their security policies to be compliant with new ones
- Some of your clients are advertising their addressing via another provider and it’s being blocked <<<
How would you solve the problem? (Select 2 options)
- Ask the customer to initiate the paperwork to become a LIR
- Accept customer prefixes from peers and upstreams
- Assign the multihomed customers PI addressing
- Adjust the deployed filters to support multihoming customers
- Use PA addressing as a backup
Order the sequence of events to modify the configuration in place: (Select 1 to 5)
- Remove previous filtering configuration ( )
- Apply new filters to peers ( )
- Open anti-spoofing filters with upstream providers ( )
- Disaggregate the IP pool range ( )
- Define new filtering rules with exceptions in place ( )
Filters are in place. Autonomous Systems are now filtering its own prefixes on peerings with all its peers in inbound direction to prevent local traffic leaking over external peerings as well as protecting the infrastructure problems that may happen if backbone infrastructure prefixes are prefered over the Internet. The exceptions for the multihomed customers have been applied too, and in this cases, we keep accepting the customer prefix from peers and upstreams.
We are planning to add some additional peerings to some of the AS. The trust relationship is not deep with some of them, so we should be able to protect the peerings in place from possible DoS attacks coming from the untrusted peers.
What additional measures would you apply to be able to avoid peer connection availability? (Select 2 options):
- Filtering per peer
- GRE over IPSec
Once previous measures are in place, shall we expect some cases where peers more than one hop away could establish a successful connection to the TCP port 179? (Select the ones that apply):
- No, once peers filters are in place
- Yes, using GRE tunneling to the BGP termination device
- Yes, if they use labeled switched paths with uniform mode
- Yes, if they use labeled switched paths with pipe mode
Which of the following technologies offers significant benefits in partial deployments? (Select 2 options):
- BGP PIC
- Path-End Validation
- RPKI-based ROV
- Transport Layer Security
HTH. Best regards!