Internet2 Network Security SIG

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

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.