Routing – Creating a JunOS firewall filter based on dynamic routing properties

I don't guess there's any real reason it can't work just fine. You, of course, have the normal loss of information anytime you redistribute from one protocol into another, but there's an argument to be made that you get that when you use network statements as well, so that's kind of a wash.

The main benefit that I see in this is that redistribution would give the setup the ability to react more dynamically to what happens in their network than the more static network statements. The downside would be that that dynamicism (is that a word?) would be harder to keep in control and might end up doing things that you don't want it to do. Of course you can put filters and route-maps and the like to constrain the redistribution...but then that's kinda like putting the network statements in.

Not that I would advocate being deceptive in what you're delivering to a customer, but if its fully managed CEs...would they even know the difference?

Assuming you're only talking about a handful of /24's like your diagram would suggest, I just don't think it makes all that much difference one way or the other. If you set up the redistribution to only allow the /24s, or set up network statements to advertise /24s...ultimately it ends up pretty much the say, right?

What may be the even bigger question that I would have (tongue-in-cheek), is...who uses RIPv2 in this day and age?!

There is no reason to limit customer to blackhole only /32, allow them to blackhole anything from them.

Something like this:

policy-statement AS42-IN {
    term blackhole {
        from {
            community BLACKHOLE;
            prefix-list-filter AS42 orlonger;
        }
        then {
            community add NO-EXPORT;
            next-hop 192.0.2.1;
            accept;
        }
    }
    term advertise {
        from {
            prefix-list AS42;
        }
        then {
            community add ADVERTISE;
            next-hop peer-address;
            accept;
        }
    }
    term reject {
        then reject;
    }
}

Remember to set 'accept-remote-nexthop' under BGP settings, so that the next-hop can be changed to something else than link address.

I also strongly support that providers start to support different blackhole communities than just 'full blackhole'. Especially if you operate in more than one country usually attack is from transit and often customer actually mostly wants to access domestic peerings, so it's useful to implement several levels of blackhhole:

1. Full
2. Outside local country (local IXP, whole own AS + customers seen)
3. Outside local area (if applicable, like for me it could be 'Nordics')
4. Include/Exclude specific peering router in blackhole

I'm happy to give example how to implement something like this with JNPR DCU/SCU, provided your peering routers are JNPR, but it's possible with just communities, just bit more awkward.

If you absolutely want to limit your customer's options you can add this:

policy-statement /32 {
    term /32 {
        from {
            route-filter 0.0.0.0/0 prefix-length-range /32-/32;
        }
        then accept;
    }
    term reject {
        then reject;
    }
}

policy-statement AS42-IN {
    term blackhole {
        from {
            community BLACKHOLE;
            policy /32;
            prefix-list-filter AS42 orlonger;
        }
..
}

This way it should be logical AND. But I really don't see the value in creating complexity to reduce expressiveness of configuration.