Internet2 Network Security SIG

["Spurling, Shannon" <>]

So, I'm kind of watching this, but want to get a better idea of why. I think 
that is Larry's question. Why publish these for prefix lengths you don't 
normally plan on advertising? I think the elephant in the policy is wither 
non documented prefixes would be a blanket permit or blanket deny.
What is the default behavior for non-defined prefixes? 

Common sense would probably get me to the point of, if I have a /16 I would 
define my handful of /19's and /18's like normal, and anything outside of 
that in that /16 would be a violation of that policy. If I configure some 
prefixes in a /16 ARIN assignment, and leave a /19 out of it, I would presume 
it (the /19) was not to be advertised from any source ASN until defined... 
Not sure if that would be the standard behavior for RPKI implementation. Is 
there a place where they define how the ROA's should be used? I may have 
missed it when glossing over the documentation.

Thanks

Shannon Spurling




-----Original Message-----
From: 

 
<>
 On Behalf Of Larry Blunk
Sent: Monday, August 20, 2018 10:49 AM
To: 

Subject: Re: [Security-WG] Generating an RPKI ROA request with lots of 
prefixes

On 08/20/2018 11:07 AM, Andrew Gallo wrote:
>
>>    I'm really failing to see the big win here.   It's not so much the 
>> use of maxlength that's the issue, but rather having ROA's allowing 
>> announcements of prefixes which you do not normally announce (which 
>> are more specifics of prefixes you normally do announce).
>> When you use maxlength, the attacker still needs to spoof origin AS 
>> in the AS_PATH in order to hijack a prefix.    By registering a bunch 
>> of /24's (or
>> /48's) which
>> are not normally announced, you still opening yourself up to hijacks 
>> of those individual prefixes with the same type of origin AS 
>> spoofing.   For most networks, hijacking a few strategic /24's or 
>> /48's will likely be just as deadly as hijacking a larger block.
>>
>>
>>  -Larry Blunk
>>   Merit
>>
>>
>>
>
> Yes, that is true, creating ROAs for all the /24s does create a large 
> attack surface.  BUT, it is still less than creating *all* the 
> prefixes between /16 and /24
>
> Creating a ROA that covers a /16 and all /24s is 257 prefixes, while
> 16-24 (inclusive) would be 511 total prefixes, some of which are 
> pretty large.
>
> You are correct in that this type of attack would require AS spoofing, 
> which should (hopefully) be harder.
>
> I think we're seeing the mismatch between real-time operational 
> changes to the routing infrastructure (changing BGP advertisements) 
> and the non-real-time data that is used to validate it.
>
> We're also seeing a change in guidance from the standards bodies- the 
> max length field was useful, but is no longer recommended.
>
> Good discussion all around.
>
>

Andrew,
    I think you are missing my point.   I'm not arguing for creating ROAs for 
all possible permutations of more specifics.   I'm pointing out that by 
registering more specific ROAs for prefixes which are not normally announced, 
you are essentially opening yourself up to the exact same attacks which are 
enabled by the use of maxlength (the attacks in both cases require AS_PATH 
spoofing).    What you are proposing is not actually a solution to the 
maxlength issue.


  -Larry