[rpki-deployathon] Loose or strict prefix-length

As stated by André the ROA's are not here to prevent AS-spoofing.
The /24's are (unfortunately) needed when one uses a DDoS Scrubbing center as a service.
There are possibilities to host your own CA/PS element with tools like Krill (https://github.com/NLnetLabs/krill)

I haven't tested this, as it also has another downside, you are not in control of the caching side, and there are possibilities where ROAs are only fetched a limited set of times during the day.
This is something that will interfere with the ability of rerouting traffic through a scrubbing center. 

This brings me to a point where I believe there should be some kind of a BCP for doing ROA validation and the speed of renewing caches. (There is  BCP185 but timing for cache renewal was determined to be out of scope.) 


Met vriendelijke groet, 

MARTIJN GROENLEER
NETWORK ENGINEER

HET BETROUWBARE IT FUNDAMENT 
Interconnect Services B.V. | 073 - 88 000 00
De Steenbok 1 | 5215 MG | 's-Hertogenbosch | KvK 50100572
Park Forum 1041 | 5657 HJ | Eindhoven | bedrijfsnummer 6020

------------------------------------------------------------------------------------------------------------------
Van: rpki-deployathon [mailto:rpki-deployathon-bounces at ripe.net] Namens Leeuwen, Andre van
Verzonden: vrijdag 22 maart 2019 14:20
Aan: 'rpki-deployathon at ripe.net' <rpki-deployathon at ripe.net>
Onderwerp: Re: [rpki-deployathon] Loose or strict prefix-length

IMHO ROAs do not protect against hijacks using AS spoofing.
However there is still value in rejecting INVALIDs caused by configuration mistakes.
 
BR,
 
André
 
From: rpki-deployathon [mailto:rpki-deployathon-bounces at ripe.net] On Behalf Of Mike Mulder
Sent: 19 March 2019 11:31
To: mailto:rpki-deployathon at ripe.net
Subject: [rpki-deployathon] Loose or strict prefix-length
 
Hi all,
 
We currently have a discussion about loose or strict prefix-length defined in the ROAs. What exactly is the win when you do strict?
 
Example: we announce a /22 and in some cases a more specific /24 from that /22, no other prefixes. We have one strict ROA for /22 and 4 strict ROAs for /24 in place. In case of AS-spoofing a malicious party will announce a /24 so that announcement will be VALID. Only the announcement of the 2 /23's will be protected (INVALID) as there are no matching ROAs. If a party intends to do harm by doing AS spoofing the bad already happens. So what is the win of doing strict vs loose, besides protecting the 2 /23's? Are there other possible practical cases I am overlooking here?
 
Thanks,
 
Mike.
 
-- 
Mike Mulder
iunxi BV
E: mailto:mike.mulder at iunxi.eu
T: +31 (0)88 5400516
M: +31 (0)6 43165195