For creating ROAs care is needed. Only create ROAs for the aggregate and the exact sub next expected in the routing table the slide shows some examples and I will step through each of the example to explain them the first line shows the prefix tender 10/16 it declares a max length of slash 24 and origin 6 5 5 3 4 this means that the raw covers 10.10 slash 16 and all subnets through to and including a slash 24 all these will be valid if they originated from a s 6 5 5 3 4 which means any subnet at all out of tender 10/16 up to a slash 24 will be valid the next line is for tender 10/16 but here the max line is only slash 16 the raw only covers this slash 16 and no subnets at all it's only this slash 16 4 origin S 6 5 5 3 4 if any subnet is announced they will be invalid the third line is for 10.10.5.3 s 6 5 5 3 4 this raw covers the slash 22 through to the slash 24 subnets subnet sizes smaller than this will be invalid 10 10.30 2.0 slash 22 is covered up to a max landis of slash 24 by origin a s 6 4 5 1 2 this is a valid roar covering slash 22 through 24 if the prefix announcements come from a s 6 4 5 1 2 notice that 10.10.5.3 0 slash 16 so as I was saying earlier it's important to be a little bit careful about creating rows some operators have a temptation to create roars of the address prefix all the way down to the smaller subnet possible this means that any subnet of that prefix being originated from the correct a s will be considered valid there's absolutely nothing stopping another entity using the same a s to originate a smaller subnet of this prefix causing a hijack or denial-of-service on the original address space my advice is always to create roars for the aggregate and individual subnets being routed in bgp no more and no less so for example if creating a row for 10.10 slash 60 and max prefix length is set to slash 16 the only valid roar will be for 10.10 slash 16 if a subnet of 10.10 slash 16 is originated it will be of state invalid avoid creating roars for subnets of an aggregate unless they're actually being actively routed as I mentioned previously if a row exists but subnet is not routed it leaves an opportunity for someone else to miss originate the subnet using the valid origin s resulting in a hijack in fact there's an IETF draft at time of this recording which discusses some of the issues and some of the care that is needed when creating ROAs looking at this internet draft which is work in progress some of the recommendations there include avoiding using max length attribute unless in special cases there advice also is to use minimal roars wherever possible in other words create Aurora only for the prefixes that are actually being announced there's also discussion about roars for facilitating DDoS services this is the case where a third party is providing DDoS services for the network operator and this would mean that the third party is originating subnets which are subject to DDoS from their own autonomous system there's even a strong suggestion by the authors that max length should be deprecated some entities were assigned address space by internet this is prior to the existence of the regional internet registries so how do we sign rules for these resources today some registries will support the signing of legacy address space roars usually there needs to be documentation proving the holding or if there's some service agreement for resources allocated by the registry they will include historical resources within that service agreement as well or by some other arrangement I have listed on the slides two examples a peenics example and the ripe NCC example please check with your own registry region about how they will handle the raw signing for legacy address space resources as at the time of recording the situation was in flux.
© Produced by Philip Smith and the Network Startup Resource Center, through the University of Oregon.
Attribution-NonCommercial 4.0 International (CC BY-NC 4.0)
This is a human-readable summary of (and not a substitute for) the license. Disclaimer. You are free to: Share — copy and redistribute the material in any medium or format Adapt — remix, transform, and build upon the material The licensor cannot revoke these freedoms as long as you follow the license terms. Under the following terms: Attribution — You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use. NonCommercial — You may not use the material for commercial purposes. No additional restrictions — You may not apply legal terms or technological measures that legally restrict others from doing anything the license permits.