Internet2 Network Security SIG

["Spurling, Shannon" <>]

You just need to be shorter than some... How many I2 participants prepend I1 peers so traffic will better prefer I2?

S-

Sent via the Samsung Galaxy S® 6, an AT&T 4G LTE smartphone

-------- Original message --------

From:

Date: 4/19/19 1:25 PM (GMT-06:00)

To:

Subject: Re: [Security-WG] [External] RE: BCP for Origin validation (RFC7115)

I’m going to agree with Shannon and re-phrase Doug’s comments:

It’s easy to fake an announcement that contains the correct RPKI-ROA-matching origin, however the resulting AS path is likely to be longer (for most) than the valid path……unless….the ROA allows a more specific route that isn’t being announced by the true origin AS, in which case the hi-jack is likely to work.

For example, if the ROA for 129.79.0.0 is loosely specified to match /16/-24, and any one of the possible /24s aren’t being announced by the true origin, then an evildoer could announce a fake route for a previously unannounced /24 that matches the ROA, and because it’s a more specific that fact that its path is longer won’t matter.

Steve

On Apr 19, 2019, at 2:14 PM, Spurling, Shannon <> wrote:

This message was sent from a non-IU address. Please exercise caution when clicking links or opening attachments from external sources.

I take it as the opposite. That the origin announcement can be faked, like in the hijacking attack. Even with a valid source ROA, If you can make your AS path shorter for some of the Internet, it doesn’t matter what the owners ASN is. You can fool some of the internet all of the time.

I guess that’s where the IRR data and filters help out. Personally, it seems a lot more palatable than cryptographically signing everything and trying to produce some “Chain of Trust” to try to authenticate every little piece. That’s a lot of things to break. How often and what is my mechanism to roll my keys? Who keeps the keys and how secure are they?

 

Shannon Spurling

 

 

From:  <> On Behalf Of David Farmer
Sent: Friday, April 19, 2019 11:46 AM
To: 
Subject: Re: [Security-WG] BCP for Origin validation (RFC7115)

 

I completely agree about the Path issues, but that is the next paragraph from the one I quoted. To me, the paragraph I quoted isn't about Path issues at all, it about the fact that it is possible for a prefix owner to lie about the origin of a prefix.  I'm not sure what's to be gained by doing so maliciously, but it is certainly a vector from mistakes.  

 

Thanks

 

On Fri, Apr 19, 2019 at 11:31 AM "Montgomery, Douglas (Fed)" <> wrote:

It is well known that current RPKI-based BGP-OV is subject to forged origin attacks, where the attacker adds an origin AS to the path that is listed in a ROA.

If your ROAs are tight, it still prevents sub-prefix hijacks, it does make the path 1 hop longer, and it might trigger other AS-PATH filters in neighboring networks.

Certainly RPKI-OV would address many of the hijacks / mis originations we have seen to date.  What remains to be seen is of those that were actually intentional/malicious, how effective forged origin prepending attacks would be.

There are two approaches to closing the remaining vulnerabilities in PATH manipulations.

Full AS-PATH signing/validation (crypto on router) -
https://datatracker.ietf.org/doc/rfc8205/

or, if that is a bridge too far ... near term approach.

RPKI-based data to filter in-feasible paths -
https://datatracker.ietf.org/doc/draft-azimov-sidrops-aspa-verification/
https://datatracker.ietf.org/doc/draft-azimov-sidrops-aspa-profile/


dougm
--
Doug Montgomery, Manager Internet  & Scalable Systems Research @ NIST


On 4/19/19, 12:05 PM, "Brad Fleming" < on behalf of> wrote:

    I’m assuming it means “there’s not way to cryptographically sign the actual BGP update on the router and it’s easy to pretend to be any ASN; thus a malicious actor can still defeat RPKI-based OV. meaning OV will generally only protect against configuration mistakes.”

    Which somewhat goes with the spirit of the following paragraph:
       Origin validation does not address the problem of AS_PATH validation.
       Therefore, paths are open to manipulation, either malicious or
       accidental.

    So I think maybe Randy was just pointing out the two major, known limitations of OV; malicious actors can still hijack in at least some cases, and this doesn’t do anything for path-level validation.
    --
    Brad Fleming
    Assistant Director for Technology
    Kansas Research and Education Network

    > On Apr 19, 2019, at 10:49 AM, David Farmer <> wrote:
    > 
    > The Security Considerations of RFC7115 has the following statement in it;
    > 
    >    As the BGP origin AS of an update is not signed, origin validation is
    >    open to malicious spoofing.  Therefore, RPKI-based origin validation
    >    is expected to deal only with inadvertent mis-advertisement.
    > 
    > I think what this is saying is that the owner of a prefix could maliciously say the prefix is originated by an ASN incorrectly.  However, I don't believe the converse is true, an ASN cannot maliciously say the prefix is originated by it.
    > 
    > Or put another way ROAs say which ASNs originate the prefix, and they are signed by the owner of the prefix, but there is no way for an ASN to say which prefixes it originates, that is then signed by the owner of the ASN.
    > 
    > Do I have that right?
    > 
    > Thanks.
    > 
    > 
    >  
    > -- 
    > ===============================================
    > David Farmer               
    > Networking & Telecommunication Services
    > Office of Information Technology
    > University of Minnesota   
    > 2218 University Ave SE        Phone: 612-626-0815
    > Minneapolis, MN 55414-3029   Cell: 612-812-9952
    > ===============================================

 

-- 

===============================================
David Farmer               
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota   
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================