Slashdot Mirror


Fix To Chinese Internet Traffic Hijack Due In Jan.

alphadogg writes "Policymakers disagree about whether the recent Chinese hijacking of Internet traffic was malicious or accidental, but there's no question about the underlying cause of this incident: the lack of built-in security in the Internet's main routing protocol. Network engineers have been talking about this weakness in the Internet infrastructure for a decade. Now a fix is finally on the way."

18 of 92 comments (clear)

  1. Like other internet Upgrades by Monkeedude1212 · · Score: 3, Insightful

    So we're at phase 1, the "Hey, check it out" phase. You can expect this to reach a phase 2, the "actually possible" phase, after IPv6 gets implemented, which will then take years to reach phase 3, the "We should really get on that" phase. Phase 4, the "Okay guys this is actually becoming a problem" phase, comes a couple years later and will no doubt be brought up on slashdot a million times over. Phase 5, is still a theoritcal phase, the "Implementation and execution phase" has not yet been observed but we have reason to believe it might happen one day, if we wish upon enough stars.

    1. Re:Like other internet Upgrades by SEWilco · · Score: 3, Funny

      Hey, you have to wait until it's implemented. Right now, the fix is due in Jan, and we have to wait until Jan writes down the code and gets it working right. Once it's working right, we're OK and we can thank Jan.

  2. Re:What... by bsDaemon · · Score: 4, Informative

    Chinese Telecom perpetrated a specific route 'attack' a few months ago where they advertised via their BGP feed more specific routes (longer netmask prefixes) for a few blocks, thus any other AS who's BGP feed had been updated with the bogus data was selecting the route to China rather than the route to the actual destination. This can either cause minor disruption, or taken advantage of to sniff all the traffic which is incoming towards the affected hosts. Whether China did it for specifically malicious purposes really isn't clear, but its happened by mistake in the past. It's a known issue in the design of the protocol and policies, and doesn't really take an 'exploit' so much as someone advertising a /22 for a block they may or may not own which preempts the legitimate /20.

  3. Re:Could we not just... by Lennie · · Score: 2

    The problem is that their is a lot of routing information shared between routers. If we also need to keep the end-nodes up to date that would not scale. And what would be the use of that ? Because that end-node only has one connection/provider, so the upstream router could tag the traffic if you wanted to do something like that.

    The problem obviously is that if you add something, how do you know you can trust that information more then all the information we currently have.

    --
    New things are always on the horizon
  4. Re:Could we not just... by Anonymous Coward · · Score: 2, Informative

    That's not how the routing on the internet works. You just specify the destination, and the source and just fire that packet away to your next-hop / gateway / router. And then the router, based on what's configured into it by the Humans, makes a decision.

    These configurations are semi-automatic, thanks to the BGP (border gateway protocol), but it's still the humans who tell the router what rules to accept from its BGP peers and what rules to send to them (and what to which). So it can be fine-grained pretty easily (once you've embraced the concepts of AS-PATHs, prefixes and such).

    So, this is not a software error, this is completely a design or human operator problem.

  5. This Is Different, the Chinese Stealed Our Net! by eldavojohn · · Score: 3, Insightful

    So we're at phase 1, the "Hey, check it out" phase. You can expect this to reach a phase 2, the "actually possible" phase, after IPv6 gets implemented, which will then take years to reach phase 3, the "We should really get on that" phase. Phase 4, the "Okay guys this is actually becoming a problem" phase, comes a couple years later and will no doubt be brought up on slashdot a million times over. Phase 5, is still a theoritcal phase, the "Implementation and execution phase" has not yet been observed but we have reason to believe it might happen one day, if we wish upon enough stars.

    Get politicians and pundits in front of the American cameras screaming "ZOMG Chineze Haz Our Intarwebz!" And you'll be simply amazed at how fast the sloth can move. If only they could have made the IPv4 -> IPv6 transition about nationalism or freedom or democracy or Al-Queda working with the Ruskies to undermine our securitization ... then that would have happened instantly!

    --
    My work here is dung.
    1. Re:This Is Different, the Chinese Stealed Our Net! by Doc+Ruby · · Score: 2

      I dunno, it's obvious that "ZOMG Chineze Hz Our National Budgetz!", but our politicians and pundits are just digging deeper holes instead of cutting the vast and counterproductive military budgets that just create debt China uses to own our national budgets. And it was the Qaeda "working with Iraq" that created over a $TRILLION in debt, much greater than even the entire US debt to China ($860B).

      --

      --
      make install -not war

    2. Re:This Is Different, the Chinese Stealed Our Net! by kasperd · · Score: 3, Informative

      Actually ipv6 is less environmentally friendly as it requires bits to be thrown back and forth to get the job done

      Just in case somebody could be mislead to think you were serious, let me point out that the total number of fields in the header was reduced by 38% when switching from IPv4 to IPv6. That should allow for less processing power being used by the routers. The size of addresses was quadrupled, but the accumulated size of the other mandatory header fields was reduced by a third, in total that means the header only doubled in size.

      --

      Do you care about the security of your wireless mouse?
    3. Re:This Is Different, the Chinese Stealed Our Net! by Doc+Ruby · · Score: 2

      You're arguing semantics. The new tax cut is repeating a tax cut that Bush got through Congress by using the Congressional technique of "reconciliation", where ordinary majority rules are suspended but the passed bill must expire in 10 years. It's a new tax cut, following an old tax cut.

      That old tax cut didn't put enough money into the economy, which instead was faked with an orgy of debt spending by almost everyone: Federal/state/local governments, corporations (especially banks, which went bust), somewhere around 175M credit card debtors, and about 10 million homebuyers who couldn't pay mortgages on homes they shouldn't have bought. 40% of GDP growth 2000-2008 was purely in the financial industry, which is not actual wealth (it's inflation, as is all that credit).

      But the main point is that the money has not gone into the pockets of people who spend it in the US economy. Unemployment benefits nearly all go right back into the economy: an estimated $1.64 per dollar of UI moves through the economy. Because unemployed people spend all the money they get on goods right in their neighborhoods. While people who make over $250K a year spend quite a lot on foreign investments and imported goods - something like $0.50 per dollar cumulative effect in the US economy. In the middle are people who also spend a lot of their money on what they need to work, which is the most productive money. Hence the priority of the middle class keeping lower tax rates and the unemployed keeping even a meager income, while rich people are the least useful to give more money to.

      Of course, the unemployed are much more expensive to the rest of us when they can't get UI, because they turn to crime (expensive in damages as well as judicial/jail work) and increased health costs. And of course the rich can actually afford to live quite well while paying a higher total percentage of their income in taxes, as their actual needs are met on a tiny fraction of their income (and accumulated wealth), though poorer people bottom out with a higher tax bill. Of course the rich also benefited vastly more from both the credit bubble and its bust, while also being the ones who caused it (by sponsoring deregulation and actually being bankers).

      Yet $150B of that $850B is reduced taxes for income over $250K, but only $56B is for UI extensions. The $300B in reduced taxes for income under $250K is shared by everyone, including everyone making over $250K for their first $250K. And there's a lot fewer rich people over $250K, so their share of the $850B is a lot more money per person than for everyone else, money that performs a lot worse in the economy.

      Some people's protected incomes have a lot more effect than others'. But then there's government spending (which includes UI), which also has different effects depending on what (and whom) it's spent on. $850B on the military/intel is mostly spent on keeping fairly productive people out of the workforce at mediocre incomes, but also largely spent on weapons never used (like digging and refilling ditches, economically). And then there's the hundreds of $BILLIONS spent on actually destroying things, which of course doesn't produce anything, while increasing costs by turning many people against us, including people among our allies who lose interest in "buying American" because "America isn't cool anymore". There's lots of government spending that just harms the US economy (before even accounting for the interest cost - and uncertainty costs - of the debt it accounts for). But most government spending is worthwhile, to protect and grow Americans' ability to produce what we sell and keep.

      We can argue in the semantic circles hammered out by corporate thinktanks for politicians to peddle to corporate media outlets. Or we can look at what we're actually spending on, from whom we're collecting, who benefits and how much. The semantic madhouse has got us into this mess. As have the previous tax rates, that are being extended on the basis that "they're the best way to get u

      --

      --
      make install -not war

  6. Re:Adding a fix? by KublaiKhan · · Score: 2

    Worked fine before, didn't it?

    In all seriousness, yes, this has always been a hole and people have been calling for it to be filled for years--but there was no attention granted to it because there was no big obvious use of it. The people who would have the resources to divert substantial amounts of traffic were, up until now, playing "nice" for the most part.

    Now there's a clear and present danger, so now the situation's being addressed.

    What's the major lesson here? That large organizations that rule by committee are reactive rather than proactive? Since when is that news?

    --
    In Xanadu did Kubla Khan
    A stately pleasure dome decree
  7. HOSTS use won't work vs. BGP by Anonymous Coward · · Score: 5, Informative

    "Is there no way on a local machine to maybe add to a host file a list of non allowed hops or something, where the packets have info as to where they can not be sent, and avoid. I am not sure as I am not very knowledge about networking, as much as I am programming, I would see this as trivial to add to a packet a flag that says it must stay within a hopping locality or sequence?" - by hesaigo999ca (786966) on Wednesday December 08, @01:10PM (#34489968) Homepage

    Specifically on HOSTS files, since I often post about them here? HOSTS files usage won't work vs. BGP exploits!

    (Think of BGP as SORT OF like arp is, which you also need for routing).

    ISP's use BGP to make routes between one another, and this is not something YOU have any control over... once you get packets in (from who knows where under this type of attack), & send them out again? You have ZERO control now at that point vs. BGP.

    BGP READ:

    http://en.wikipedia.org/wiki/Border_Gateway_Protocol

    That URL's where you can read up more on BGP...

    and

    ARP READ:

    http://en.wikipedia.org/wiki/Address_Resolution_Protocol

    That URL's where you can read up more on ARP which is used between routers/gateways...

    Why did I put those links up for you?

    Well - You stated you're more of a programmer than a network engineer/tech, & I was much the same a decade + 1/2 ago is why...: I KNOW WHERE YOU ARE COMING FROM! Those will help...

    (I too was "mostly coder & hardware tech" ONLY, back then circa 1994-1996, until I started doing webservices based coding + client-server work, where you HAD to have @ least SOME understanding of "things networking", & picked up MOST of it on IRC back then)...

    Later though? Heh, it ended up getting me work as a network administrator many times even, just because I took some initiative to "grow myself" a BIT more, to be more "well-rounded/all-around" & more "liberal arts", albeit STRICTLY around computing (learn BOTH coding & networking - it's worth it!).

    APK

    P.S.=> This isn't a first, though I truly DO suspect China did it intentionally (because of the military information being sampled as mentioned in the source articles is why MOSTLY), but iirc, some ISP in Florida USA did it by accident & FLOORED THEMSELVES (sort of funny, but NOT for their customers though I imagine - especially those that depend on the net for their work/livelyhood, education, etc./et al (& even if only in part))... apk

  8. Re:What... by Anonymous Coward · · Score: 2, Insightful

    No, some moron working on China Telecom's Beijing AS posted the iBGP routing table to the eBGP side. It's that simple. It didn't cause too much trouble, really, since the only routers that were fooled by it were nearby routers - like the other edge routers in China, and those in S. Korea, Japan, and surrounding companies (in the network topology, which loosely mirrors real geography). The routers in the US would get two prefix advertisements, notice that one was too far away, and use the right ones.

    This is some dipshit's attempt at pushing NPKI as the "solution" to prefix hijacking. The solution is not to send sensitive data unencrypted over the Internet. Period.

  9. Re:Adding a fix? by mysidia · · Score: 3, Informative

    What is the adage? Throwing code at a problem?

    Yeah.. like SSL prevents hackers from hijacking CC details in e-commerce transactions.

    RPKI has been in the works for years, and will be in the works for years.

    I don't know where the idea "this will be fixed Jan 1" came from. A pilot program for RPKI is no more an immediate fix than the pilot program for DNSSEC was an immediate fix for security issues, and no more than the IPv6 pilot program / 6Bone was an immediate fix for IP address exhaustion.

    Finalizing a protocol and having pilot programs at the registries is a far cry from having all the vendors implement the solution, providing a stable proven implementation for network operators, and network operators choosing to upgrade routers to new hardware that can meet the CPU requirements needed by RPKI, and new software to actually provide the implementation.

    And then, even once those things are done, after all the money spent upgrading, it still remains for RPKI to be "turned on" and implemented.

    Who will go first? Seriously, this fix is not going to be widely deployed in January. Well, January 2020 maybe.

    After the pilot, this fix is a good 5 years off bare minimum, probably closer to 10.

  10. Re:Not the problem, not the solution! by ckdake · · Score: 3, Interesting

    Accepting a bad route from a peer and accepting a cryptographically signed bad route from a peer are the same thing.

  11. Re:RPKI FTW by mysidia · · Score: 3, Interesting

    More importantly, in the article it says the RIR's also finish their part so now we can start building filters which actually work ?

    No, that's still a few years off.

    The problem with RPKI is it's all well and good, until you realize there has to be a central authority, and that central authority is vulnerable to influence by governmental and corporate entities.

    For example, federal agents sending patriot act security letters demanding to have the encryption keys, needed to forge resource assignments to themselves, or demanding RIRs "cancel such and such resource"

    This could make the RIAA and MPAA very happy, as it could provide them an expeditious way of shutting down any network, with a much lighter burden than that required to get a court order.

  12. Re:Could we not just... by TheRaven64 · · Score: 2

    That won't prevent any attacks from China, it will just prevent you from being able to resolve any Chinese domains. You need to use your firewall to drop traffic from Chinese IP addresses to do that. Not sure that will actually help though - my ssh logs show that the IPs for the botnet(s?) that keeps trying to connect to my machine are pretty well distributed around the world.

    --
    I am TheRaven on Soylent News
  13. Re:Could we not just... by kasperd · · Score: 3, Informative

    Furthermore packets are something like 1.5k in size max with only something like 0.5k for actual application data

    With IPv4 the maximum is around 64KB. However it is not required for everybody to support that large packets. If you send a packet that is too large for the destination or a router on the way it will either be split or an error message is sent back to the sender (which of the two is decided by the sender setting a bit in the header). On of the most frequent mistakes in configuring the network is to throw away packets that are too large without telling the sender.

    There need to be some minimum where you are guaranteed that a packet under that size will reach the destination. For IPv4 that size is defined as 68 bytes for individual packets and 576 bytes for the full reassembled packet. Notice that 68 is ridiculously small by today's standards. I think most modern operating systems supports the full 64KB. The maximum size of the individual parts (known as the MTU) is typically 1500 bytes as that is the size supported by Ethernet.

    In most cases you want to avoid fragmentation of IP packets because if one part is lost by the network, then the remaining parts cannot be used for anything. Data larger than 1500 bytes is usually send using TCP, which does support retransmitting just the fragments that were lost.

    It is possible to let TCP segment the data stream and then let IP fragment each segment, but the only gain is that you don't have to to send TCP headers as frequently. If you have a 68 byte MTU, then the TCP header is a significant part of the MTU, and such fragmentation makes sense. In more typical cases with an MTU of 1KB or more, the 20 bytes for the TCP header are well spent, and you usually try to send packets exactly the size where they don't have to be fragmented further.

    A typical packet nowadays is a TCP packet with 20 bytes IPv4 header, 20 bytes TCP header, 12 bytes TCP options and up to 1448 bytes payload.

    With IPv6 the limits have been increased. The minimum MTU was increased from 68 bytes to 1280 bytes. The minimum reassembled packet was increased from 576 to 1500 bytes, and the IP header was increased from 20 to 40 bytes. (Even though the size of the addresses was quadrupled, the header size was only doubled because everything else in the header was simplified). With IPv6 the 1280 bytes is large enough that often it is a good idea to just stay within the 1280 bytes to avoid problems with routers that don't support larger packets. It is close enough to 1500 bytes to get good efficiency in most situations, and there is sufficient gap between 1280 and 1500 to allow for a few extra headers in case of tunnelling. That would mean a typical TCP packet has 40 bytes of IPv6 header, 20 bytes of TCP header, 12 bytes of TCP options, and up to 1208 bytes of payload.

    The bit in the header, which indicates if the packet should be split or bounced in case it is too large was eliminated with IPv6. In IPv6 the packets are always bounced if they are too large. That also means the header fields for reassembly were removed. The sender can decide to split the packet and include an IPv6 option header, but it still won't be split further by routers on the network.

    You can have an option header specifying which route you want the packet to take rather than just a destination. But many networks will just drop the packet if you try to.

    --

    Do you care about the security of your wireless mouse?
  14. Re:Not the problem, not the solution! by samson13 · · Score: 2

    I don't think most operators could do a better job. Every ISP I've dealt with has been pretty anal about what routes they accept from me.

    This incident happened at the large ISP level and currently they don't have the information required to do better filtering. In this case China Telecom might legitimately be the shortest path for some of this traffic some of the time and there is no way to tell otherwise.

    The PKI signed advertisements will provide trust that I have ownership of the resources and would probably solve most of the accidental routing incidents.. i.e. somebody fat fingers a route on some "core" router and it starts advertising it under its own AS. The rest of the Internet will ignore that route because that AS doesn't own it.

    What I don't see it solving is the malicious case were the attacker strips the AS path and re-advertises the route. i.e ME-A-B-C-D-BADGUY. Badguy just advertises ME-BADGUY so anybody closer will go their direction. Nobody can tell the difference cause I've signed the advertisment and they won't know that I'm not connected to BADGUY...

    unless I sign that my nexthop is A. A then signs that his next hop is B. I could imagine that getting very expensive in the middle. Where the level1 carriers have to sign every route multiple times for every one they connect to.. Ouch.