Internet2 Network Security SIG

["Montgomery, Douglas (Fed)" <>]

There might be two levels of answer to your question.  The first is from an 
RPKI validation perspective, the results of ROA creation are well and 
completely defined.  See https://tools.ietf.org/html/rfc6811 and 
https://datatracker.ietf.org/doc/draft-ietf-sidrops-ov-clarify/

The creation of ROAs that cover an announced prefix with matching AS and 
length less than MaxLength results in a VALID, if no such matching ROA 
exists, but there are others that cover the announce prefix results in 
INVALID.  If no ROAs exist that cover the announce prefix the result is 
NOTFOUND.

Note one can use AS0 to create ROAs for address space that is not authorized 
to be announced.  Here you can use MaxLength=24 because you can't 
(supposedly) prepend AS0 to a path and have BGP accept it.

What routers do with RPKI validation results (the second level) is always 
left as a local matter.  All implementations that I know of allow you to 
write policies to decide what you want to do with the validation results.  
Examples range from ignoring INVALIDs to using local_pref to change route 
preference based upon the result.

Some local policies make more sense (ignore, INVALIDS), some make less sense 
(e.g., "prefer valid" ... since longest match wins in routing, you still 
might get a subprefix hijack).

A good tutorial here will example local policy examples:
https://www.ripe.net/manage-ips-and-asns/resource-management/certification/router-configuration


dougm
-- 
DougM at NIST
 

On 8/20/18, 12:10 PM, 
"
 on behalf of Spurling, Shannon" 
<
 on behalf of 
>
 wrote:

    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