[RPKI] Accepting smaller routes than RPKI object allows (blackholing)

[Stavros Konstantaras]

Based on the current standards and vendor implementations, I believe another potential solution to make this work is to use a separate routing instance (e.g a server running BIRD or other software), where customers can use it to send blackhole routes. 

With BIRD running on a simple box, you could easily implement an import filter where a customer is allowed to advertise a /32 route that carries the BLACKHOLE community as well (and only that, nothing else). Then, with a little bit of python scripting you could either program your basic Juniper or Cisco router accordingly or trigger your purchased anti-DDoS service. 

The positive on that workaround is that programmatically you are more flexible and perhaps apply some extra logic. The drawback is that customers need to maintain a second BGP session (plus your setup is highly more complicated). 


Best regards,

Stavros Konstantaras | NOC Engineer | AMS-IX 
M +31 (0) 620 89 51 04 | T +31 20 305 8999
ams-ix.net

> On 29 Aug 2019, at 14:03, Klimek, Denis <DKlimek at Stadtwerke-Norderstedt.de> wrote:
> 
> Matching two different invalid states (incorrect ASN/prefix length) could solve the issue :-)
> But I don't think that the router vendors are going to implement this soon.... for now I decided to keep local prefixfilter lists if a customer wants to use advantage of blackholing.
> 
> Mit freundlichem Gruß
> Stadtwerke Norderstedt
> 
> Denis Klimek
>  
> Professional Network Engineer
> IP-Systemtechnik
> 
> Tel:        040 / 521 04 - 1049
> Mobil:    0151 / 652 219 06
>  
> dklimek at stadtwerke-norderstedt.de
> www.stadtwerke-norderstedt.de
> 
> 
> -----Ursprüngliche Nachricht-----
> Von: RPKI [mailto:rpki-bounces at nlnetlabs.nl] Im Auftrag von Tim Bruijnzeels
> Gesendet: Donnerstag, 29. August 2019 14:01
> An: Job Snijders
> Cc: rpki at nlnetlabs.nl
> Betreff: Re: [RPKI] Accepting smaller routes than RPKI object allows (blackholing)
> 
> Hi,
> 
> Maybe you can use an export of the VRPs to find the networks for your specific customer ASNs, that you would want to allow them to send /32 or /128 on.
> 
> Unfortunately RPKI implementations in the router do not differentiate between invalid_asn and invalid_length (but correct ASN). Otherwise you could have required (rpki valid | rpki invalid-length).
> 
> Or am I mis-understanding the issue here? Sorry, just learning about actual routing operations, so looking at this from a more theoretical rpki angle - where I have a bit more experience :D 
> 
> Tim
> 
>> On 29 Aug 2019, at 13:34, Job Snijders <job at ntt.net> wrote:
>> 
>> On Thu, Aug 29, 2019 at 11:28 AM Chriztoffer Hansen
>> <chriztoffer at netravnen.de> wrote:
>>> On 29 August 2019 at 09:43:30 -00:00, Klimek, Denis <DKlimek at stadtwerke-norderstedt.de> wrote:
>>> 
>>> Today I played around with RPKI against our customer BGP sessions and noticed that if a customer wants to send a /32 or /128 route to blackhole his traffic that this is not accepted due invalid rpki state.
>>> 
>>> Why not re-configure your route-map to accept host routes. Before the RPKI state validation is done later in the route-map?
>> 
>> You gotta make sure that the customer is allowed to announce those hostroutes...
>> 
>> You don't want (most) customers to be able to blackhole 1.1.1.1 or 8.8.8.8
>> 
>> Kind regards,
>> 
>> Job
>> -- 
>> RPKI mailing list
>> RPKI at nlnetlabs.nl
>> https://www.nlnetlabs.nl/mailman/listinfo/rpki
> 
> -- 
> RPKI mailing list
> RPKI at nlnetlabs.nl
> https://www.nlnetlabs.nl/mailman/listinfo/rpki
> -- 
> RPKI mailing list
> RPKI at nlnetlabs.nl
> https://www.nlnetlabs.nl/mailman/listinfo/rpki