nanog mailing list archives
Re: AT&T/as7018 now drops invalid prefixes from peers
From: Job Snijders <job () instituut net>
Date: Tue, 12 Feb 2019 23:24:16 +0000
On Tue, Feb 12, 2019 at 7:30 PM Matthew Walster <matthew () walster org> wrote:
On Tue, 12 Feb 2019 at 16:05, Nick Hilliard <nick () foobar org> wrote:Matthew Walster wrote on 12/02/2019 14:50:For initial deployment, this can seem attractive, but remember that one of the benefits an ROA gives is specifying the maximum prefix length. This means that someone can't hijack a /23 with a /24.they can if they forge the source ASN. RPKI helps against misconfigs rather than intentional hijackings.As it stands today, RPKI is only useful to prevent fat-fingering of ebgp
routing policies, where routes are leaked from a point of "legitimate" re-origination such as a web filter service. This simply isn't true. I'm willing to argue a bit about to what degree and in what circumstances RPKI Origin Validation technology is useful or not, but the use of the word "only" in this context is incorrect.
It's entirely unsuitable (at present) for anything where someone is
re-originating the prefix somewhere else with the same origin ASN present (i.e. maliciously) and it doesn't protect against someone accidentally sending you a prefix they heard elsewhere that is valid. This also is not true. It is not as black and white as you make it out to be. 1/ For instance AT&T does not accept BGP UPDATES with 2914 anywhere in the AS_PATH except on the direct EBGP sessions between 7018 and 2914. This means that you can craft BGP UPDATES with 2914 all you want, but 7018 won't accept them. You can't inject yourself between AT&T and NTT using spoofing. 2/ Many networks give all their peering partners the same LOCAL_PREFERENCE, so you'll have to not only spoof the BGP Origin ASN but also compete & win for the shortest path in order for your hijack to arrive at the intended location. We as industry essentially already have path validation for paths of length 1. This may not seem much, but since people in this industry tend to peer directly with networks that matter to them. The majority of Internet traffic flows over paths that have an AS_PATH length of 1.
My understanding is that part of that problem can be solved with
https://tools.ietf.org/html/draft-ietf-sidrops-rpki-tree-validation-03 but once again it's still only preventing fat-fingering and not malicious intent. Uh... that draft is about something else entirely. :-)
I think I'd have a hard time convincing people of that though, and the
RIR policy folk would have a small heart attack at the level of complexity required. you are probably right about that, I'd prefer to stick to a technology that actually exists and is deployable! :-) Kind regards, Job
Current thread:
- Re: AT&T/as7018 now drops invalid prefixes from peers, (continued)
- Re: AT&T/as7018 now drops invalid prefixes from peers Job Snijders (Feb 11)
- Re: AT&T/as7018 now drops invalid prefixes from peers Jay Borkenhagen (Feb 11)
- Re: AT&T/as7018 now drops invalid prefixes from peers Niels Raijer (Feb 12)
- Re: AT&T/as7018 now drops invalid prefixes from peers Matthew Walster (Feb 12)
- Re: AT&T/as7018 now drops invalid prefixes from peers Nick Hilliard (Feb 12)
- Re: AT&T/as7018 now drops invalid prefixes from peers Denis Fondras (Feb 12)
- Re: AT&T/as7018 now drops invalid prefixes from peers Job Snijders (Feb 12)
- Re: AT&T/as7018 now drops invalid prefixes from peers Matthew Walster (Feb 12)
- Re: AT&T/as7018 now drops invalid prefixes from peers Nick Hilliard (Feb 12)
- Re: AT&T/as7018 now drops invalid prefixes from peers Michael Hallgren (Feb 12)
- Re: AT&T/as7018 now drops invalid prefixes from peers Job Snijders (Feb 12)
- Re: AT&T/as7018 now drops invalid prefixes from peers Matthew Walster (Feb 12)
- Re: AT&T/as7018 now drops invalid prefixes from peers Owen DeLong (Feb 13)
- Re: AT&T/as7018 now drops invalid prefixes from peers Jay Borkenhagen (Feb 11)
- Re: AT&T/as7018 now drops invalid prefixes from peers Job Snijders (Feb 11)
- Re: AT&T/as7018 now drops invalid prefixes from peers Jay Borkenhagen (Feb 11)
- Re: AT&T/as7018 now drops invalid prefixes from peers Alex Band (Feb 12)
- Re: AT&T/as7018 now drops invalid prefixes from peers Jay Borkenhagen (Feb 14)
- Re: AT&T/as7018 now drops invalid prefixes from peers Jay Borkenhagen (Feb 11)