Fix To Chinese Internet Traffic Hijack Due In Jan. 92
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."
Re:What... (Score:5, 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.
Re:Could we not just... (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.
HOSTS use won't work vs. BGP (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 [wikipedia.org]
That URL's where you can read up more on BGP...
and
ARP READ:
http://en.wikipedia.org/wiki/Address_Resolution_Protocol [wikipedia.org]
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
Re:Adding a fix? (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.
Re:Could we not just... (Score:4, Informative)
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.
Re:This Is Different, the Chinese Stealed Our Net! (Score:4, Informative)
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.