Internet2 Network Security SIG

[Brad Fleming <>]

When KanREN faced the same question the best answer was to create a ROA which listed each /24 individually in a single, multi-prefix ROA. If we transition from a Zenedge to a DDoS scrubbing service that must originate the prefix under attack we’ll remove the ROA with AS2495 as valid origin and create a new one with the scrubbing org’s AS.

So for example, KanREN is granted use of 164.113.0.0/16, 198.248.0.0/16, 69.77.0.0/17, 2001:49d0:;/32. For DDoS purposes we created 3 additional ROAs for the IPv4 supernets.

1) Origin: AS2495, 164.113.0.0/24, 164.113.1.0/24, 164.113.2.0/24, 164.113.3.0/24 … 164.113.255.0/24

2) Origin: AS2495, 198.248.0.0/24, 198.248.1.0/24, 198.248.2.0/24, 198.248.3.0/24 … 198.248.255.0/24

3) Origin: AS2495, 69.77.0.0/24, 69.77.1.0/24, 69.77.2.0/24, 69.77.3.0/24 … 69.77.127.0/24

We left out any prefixes that belong to downstream, BGP-speaking KanREN members (not many). The approach provides the smallest surface for a hijack and keeps the ROA count to a reasonable minimum.

The IPv6 supernet was more messy. We tried creating a ROA that covered the /48s but ran into limits on the number of prefixes allowed on a single ROA. I tried splitting it up a couple times (read: using a hammer to make the square peg fit into the round hole) and failed. Eventually got dragged away and haven’t had a chance to return to the topic for the v6 block. I think Andrew might have actually found the limitation so I at least know where to split the ROAs up.

I wish ROAs supported something similar to:

ip prefix-list roa-4-win seq 100 permit 164.113.0.0/16

ip prefix-list roa-4-win seq 110 permit 164.113.0.0/16 ge 24 le 24

ip prefix-list roa-4-win seq 120 permit 198.248.0.0/16

ip prefix-list roa-4-win seq 130 permit 198.248.0.0/16 ge 24 le 24

ip prefix-list roa-4-win seq 140 permit 69.77.0.0/17

ip prefix-list roa-4-win seq 150 permit 69.77.0.0/17 ge 24 le 24

Very possible that I missed a better way to handle the problem but truth is there’s no good and complete answer, using current tools/tech, for the issue Steve raised. AS-Cones seems like it might help some of these issues (I think) but there was some really strong opposition when it was presented at RIPE 76 about a year ago ( https://ripe76.ripe.net/archives/video/103/ ). So dunno if that will become a thing or not.

On May 15, 2019, at 10:42 AM, Andrew Gallo <> wrote:

Very true.  I knew I was missing something.

I think it was Brad from Kansas that had the suggestion of having a ROA allow prefixes of multiple specific masks, such as /16 OR all /24s, but not in between.  There isn't a standard to allow that, and it's only slightly better than the current mask length option, but it does prevent an attacker (or mistaker? if I can make up a word) from spoofing prefixes of intermediate length.

On Wed, May 15, 2019 at 11:24 AM <> wrote:

>
> What's the opinion of having the DDoS vendor advertise the prefix using the original networks ASN, in which case, the original ROA would cover?  Is that bad form in terms of routing?
>

I’m not sure that fixes anything. The DDoS vendor will need to advertise a more specific, so you’re now stuck with creating many ROAs, or select an optional prefix length to cover the more specifics. Either will allow a hijacker to use spoof your origin and advertise more specific to effective divert traffic, all the while passing a validator test.

Attachment: smime.p7s
Description: S/MIME cryptographic signature