Internet2 Network Security SIG

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

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.