Internet2 Network Security SIG

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

As one last thought on this issue. While origin validation alone still has 
some weaknesses for capable & malicious attackers, it is important to compare 
origin validation against doing nothing, not just against itself.

1.  No origin validation - no defense against hijacks of same (shortest path 
win) or longer length.  No defense against mis-originations that are not 
malicious (i.e., misconfigurations).  No way to authorize origin ASes or DDoS 
mitigation providers.  Limited ability to filter outside customer cone.

2.  With origin validation - defense against mis configurations (the majority 
of "hijacks"), defense against same length and sub-prefix attacks without 
forged origin, forged origin attacks still possible but have longer path and 
more "visibility" to the system.  Ability to filter unauthorized originations 
outside your customer cone.

The design of RPKI origin validation was highly influenced by a "no crypto on 
the router" perceived requirement.  Without the ability to digitally sign 
elements of the path / NLRI you will always be susceptible to various forms 
of path forgery and cut-n-paste attacks.

In short ROV raises the bar ... but it doesn't put it at the ceiling.  That 
was a purposeful design tradeoff.

dougm
-- 
DougM at NIST
 

On 8/20/18, 4:05 PM, "Montgomery, Douglas (Fed)" 
<>
 wrote:

    A new version of the spec I mentioned earlier was just posted.
    
    BGP RPKI-Based Origin Validation Clarifications
    https://tools.ietf.org/html/draft-ietf-sidrops-ov-clarify-05
    
    Mainly just cleaning up the wording, but if you have not read it yet, 
start with the one above.
    
    dougm
    -- 
    DougM at NIST
     
    
    On 8/20/18, 1:13 PM, "Montgomery, Douglas (Fed)" 
<>
 wrote:
    
        I should have provided an additional link with for the ASPA work.  
The link below deals with the PATH validation aspects.
        
https://datatracker.ietf.org/doc/draft-azimov-sidrops-aspa-verification/
        
        Also there is another RFC that provides a somewhat more fluid 
description of RPKI validation.
        https://tools.ietf.org/html/rfc6483
        
        -- 
        DougM at NIST
         
        
        On 8/20/18, 12:49 PM, "Andrew Gallo" 
<
 on behalf of 
>
 wrote:
        
            
            
            On 8/20/2018 11:49 AM, Larry Blunk wrote:
            > 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
            >
            >
            No, I understand your point.  I wasn't actually proposing this as 
a 
            solution.  Seth had asked how this could be done, so I wrote a 
script to 
            see if it could be done, and in the process found a bug in ARIN's 
ROA 
            request submission portal, as well as a limit to the number of 
prefixes 
            it will accept in a single ROA.
            
            I agree creating ROAs that cover more specifics that aren't 
normally 
            announced is a risk, but it could be a requirement given the 
difference 
            between the real-time nature of having a DDoS provider announce 
one of 
            your subnets, and the non-real-time creation and distribution of 
a ROA 
            to cover it.  If you were forced into a position where you didn't 
know 
            which /24 would need to be announced, or when it would need to be 
            announced, how would you handle it?
            
            Right now, there doesn't seem to be a good option, though Doug 
has 
            shared some work that I wasn't aware of.