| > If a state actor were trying to intercept traffic (MITM), the last thing they would do is pad the AS path That's presumptuous: A state actor would (and could trivially) pad the wrong directions to flow traffic down to pops that are not making new announcements (and thus not-implicated by cloudflare and other "journalistic" efforts). There's also a lot between fat-fingers and deep-state: I know of some non-state actors who do this sort of thing just to fuck with ad impressions. I also doubt much usable intelligence can be gained from mere route-manipulation thing, but I do know that if it is a fat-finger, every techdude in the area was busy at that time trying to figure it out, and wasn't doing their best work twelve hours later... > most likely a route map intended to manipulate traffic engineering for their own upstream links ...that being said, this does seem plausible: Most smaller multihomed sites I've seen (and a few big ones!) have some kind of adhoc health monitoring/rebalance function that snmp or something and does autoexpect/curl or something-else to the router to run some (probably broken) script, because even if your uplinks are symmetrical, the rest of the Internet isn't, so route-stuffing remains the best way to manipulate ingress traffic. > Never attribute to malice that which is adequately explained by a missing export filter. As soon as I peer with two big sites that don't peer directly with each-other, they both gotta let me forward announcements unfiltered across them. Once I have a third, I have a legitimate need to manipulate my own ingress. The problems with the BGP are legion, and not just one thing that prevents BGP and security from sharing time in a sentence. |
| |
| ▲ | Fiveplus 2 days ago | parent | next [-] | | You're spot on regarding the mechanics. It's important to reinforce that in BGP, AS-PATH length is a cost metric and not a steering wheel. | |
| ▲ | codexon a day ago | parent | prev | next [-] | | Actually many networks will prefer routing over a cheap AS path no matter how long it is. | | |
| ▲ | mlyle a day ago | parent [-] | | > > and is (one of many attributes) used to judge the quality of route | | |
| ▲ | codexon a day ago | parent [-] | | Lower cost usually means lower quality and is an example of how a long path being leaked can result in traffic flowing away from high quality path to the leaked path. Not saying that this is the case with Venezuela, just explaining the reality of BGP where path prepends are often ignored. | | |
| ▲ | mlyle a day ago | parent [-] | | His claim-- as best as I can read it-- is that B leaking a long-length route changes where traffic is routed, but not to B. It's possible he's saying something else, but I can't figure out, and he hasn't clarified. |
|
|
| |
| ▲ | a day ago | parent | prev | next [-] | | [deleted] | |
| ▲ | darig 2 days ago | parent | prev | next [-] | | [dead] | |
| ▲ | geocar 2 days ago | parent | prev [-] | | > This isn't how BGP works This is exactly how BGP works. https://bgplabs.net/policy/7-prepend/ > Leaking a new route isn't going to magically make some other route become more preferred. Not magic, but technology can look like magic when you don't understand it. | | |
| ▲ | mlyle 2 days ago | parent [-] | | > > > That's presumptuous: A state actor would (and could trivially) pad the wrong directions to flow traffic down to pops that are not making new announcements > > Leaking a new route isn't going to magically make some other route become more preferred. > Not magic, but technology can look like magic when you don't understand it. Please let me know of the scenario where route A is preferred, undesirable, long-path route B is advertised/leaked, and as a result traffic flows over route C. I've used BGP for over 25 years, so I'm really curious what you're thinking. Or if you're describing something else, you're being really unclear. Or if you're just describing withdrawing a route and replacing it with a really undesirable route -- sure, we do that all the time. But that doesn't match this scenario and isn't going to get flagged as a routing anomaly. > https://bgplabs.net/policy/7-prepend/ You know what's really toxic? Not explaining what you mean and just sending some introductory lab documentation about what the other person has already clearly shown they understand. I don't even know what you mean by a lot of these things.. e.g. > > > As soon as I peer with two big sites that don't peer directly with each-other, they both gotta let me forward announcements unfiltered across them. A straightforward reading of "forward" doesn't work for this sentence. I should not take a route from peer A and send it to peer B. Peering isn't transitive. If I try, it should be filtered. Peering means to give your own routes (and your transit customers' routes) to someone else. Not your other peers routes. | | |
| ▲ | geocar a day ago | parent [-] | | > Please let me know of the scenario where route A is preferred, undesirable, long-path route B is advertised/leaked, and as a result traffic flows over route C. > ... I'm really curious what you're thinking That the actor actually wanted the traffic to flow over route C. > You know what's really toxic? Not explaining what you mean and just sending some introductory lab documentation about what the other person has already clearly shown they understand. I think perhaps you and I have different ideas of what is "clear", for example when you said something that is totally covered in introductory lab documentation, I thought it was clear that you did not understand. > I don't even know what you mean by a lot of these things That is clear! But confusing! How can you clearly understand but not know what I mean? > Peering means to give your own routes (and your transit customers' routes) to someone else. That's exactly what's happening here: Not every transit customer peers with every other transit customer. | | |
| ▲ | mlyle a day ago | parent [-] | | > > Please let me know of the scenario where route A is preferred, undesirable, long-path route B is advertised/leaked, and as a result traffic flows over route C. Yes, but how does advertising undesirable route B make traffic go over route C? This is why I think you're confused. > That's exactly what's happening here: Not every transit customer peers with every other transit customer. I am not understanding what you're saying at all. You said: > > > > As soon as I peer with two big sites that don't peer directly with each-other, they both gotta let me forward announcements unfiltered across them. This is the thing you are supposed to never do as a peer, and the thing that I have a whole bunch of filtering to prevent my peers from inadvertently doing. Are you misusing the word "peer"? It's hard to talk about BGP and routing policy without using these words correctly. I think I'm going to give up here. | | |
| ▲ | geocar a day ago | parent [-] | | > This is why I think you're confused. I think you're confused. > I am not understanding what you're saying at all. And that is why; You seem to have a very strong opinion about something that you don't understand "at all" and frankly I cannot understand how that can work. > This is the thing you are supposed to never do as a peer So you say, but that's what I did when back in the early 2000s, and that's what the parties in the news were doing, and if you're not totally lying to me, you know this because it's the default in BGP, that's why you would say you need to: > I have a whole bunch of filtering to prevent my peers from inadvertently doing. because that's how BGP works. Duh. > It's hard to talk about BGP without using these words correctly. and I am flabbergasted you continue to persist at it, when I have even offered you "introductory lab documentation" to help. | | |
| ▲ | mlyle a day ago | parent [-] | | Peering means "give our downstream customers' routes plus our own routes; receive the same from them". Transit means "give our entire table, receive their routes plus their downstream customers routes". You don't give one peer's routes to another. You filter to make sure you are not doing this. They hopefully filter (using data from RIRs) to make sure you're not doing it. If both parties screw up the filtering, you "leak routes" like we're discussing here. This has been standard practice for peering since at least 1997. It is codified, among other places, in RFC7454. > And that is why; You seem to have a very strong opinion about something that you don't understand "at all" and frankly I cannot understand how that can work. Do you operate an AS? Are you a peering contact? I mean, I only do it mostly for funsies now but for quite awhile that was part of my job. :P Also, still seeking an answer to this question: > > > Yes, but how does advertising undesirable route B make traffic go over route C [that previously went over route A]? This is why I think you're confused. | | |
| ▲ | geocar 20 hours ago | parent [-] | | > Do you operate an AS? Are you a peering contact? > I mean, I only do it mostly for funsies now but for quite awhile that was part of my job. :P I'm retired now. I wrote some about my experiences on HN a long time ago: https://news.ycombinator.com/item?id=18535518 https://news.ycombinator.com/item?id=2727993 I set up multihoming in the US (going through ARIN assignment for ASN and PI) in the early 2000s and for another larger company in the UK (doing the same same but different) in the early 2010s. > Also, still seeking an answer to this question: Not sure what to tell you. I've answered this within the context of the news article, if you're asking specifically what kinds of configurations do that they're the kinds that are in that "introductory lab documentation" and if you're not overstating your credentials you should be able to understand. | | |
| ▲ | mlyle 10 hours ago | parent [-] | | OK, so you've never actually been involved in peering between providers. That explains things. If you are buying transit for multihomed site, you just mostly need to worry about advertising your few local routes and receiving a table. These words mean specific things in a provider environment. Peering between providers is not transitive. You should not give a peer's routes to another peer-- else you are offering to provide transit to that peer. None of the three parties involved (the peer the route came from, the peer the route would go to, or you), generally, want this. > As soon as I peer with two big sites that don't peer directly with each-other, they both gotta let me forward announcements unfiltered across them. So -- this is true for neither scenario. If you buy transit from two people, you don't want to "forward" routes between them. Likewise for two peers. You only want to pass on your own routes, plus routes for your downstream customers or to your downstream customers. The other topic that caused confusion: leaking a route to somewhere won't change where traffic goes unless that new leaked route wins. If it wins, the traffic will come to you (regardless of AS path). If it doesn't win, the existing route will still be used. I'm retired-ish now, too (now I'm mostly a high school teacher for the funsies). But if you find yourself with BGP infrastructure in HE.NET Fremont, or somewhere that can peer with FREMIX, or somewhere that can access KCIX, feel free to send me a peering request. I currently have 2 direct upstream transit providers and 55 peers across 3 sites and export 6 prefixes plus 2 downstream prefixes :P |
|
|
|
|
|
|
|
|
