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."
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.
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.
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
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.
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.
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
"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
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.
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.
Accepting a bad route from a peer and accepting a cryptographically signed bad route from a peer are the same thing.
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.
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
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?
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.