Good news, bad news, weird news – it's the week in networking Ciena gets to lead this week's networking roundup, courtesy of financial results that saw its share price jump nearly 13 per cent. The investors were responding to the company's Q3 2018 results, headlined by revenue rising 12.4 per cent year-on-year to $819m, even though net income fell nearly $10 million to $50.8 million. …
"What could possibly go wrong."
Terry 6, if you want an answer to your question, I suggest you read Eurocae ED-228A. The simple answer is "an awful lot can go wrong". ED-228A provides a hazard analysis listing out in all its glory all the possible nasty things that can happen. It also identifies the requirements that the implementations must satisfy to ensure that there is a safe outcome to each hazard when and if it occurs.
If only Banks, etc. took a similar approach.
Interesting. When I was writing software for the audio part of an air traffic control system, we had backup channels on each communications card, backup communications cards, backup racks and two generators. Four things would have had to go wrong at the same time for the air traffic controllers to even notice there was a problem.
And that is why our aircraft crisscross the world with so little accidents. If air traffic was controlled like Paris controls its périphérique, we'd be reading about a plane crash every hour.
Air traffic is the very last bastion of actual redundancy requirement, even NASA has trouble doing as well (not a good sign).
I remember that one time when a Swiss ATC was responsible for a plane crash. It shocked the world because everyone thought that Switzerland was the last place beancounters would have been able to interfere, but that's what it was.
Beancounters and safety do not go together.
That was an issue of instructions given by the controller being exactly the opposite of those of the TCAS system The Russian pilot was trained to obey to ATC, the cargo pilot to obey the TCAS, so they went the same direction. The controller was latter murdered by the father of one of the Russian plane victims for revenge.
AFAIK, one of the aim of the new system is to reduce voice communications, and give controllers and pilots better awareness of what's happening nearby.
From the article: "...IPv6 to replace the truly ancient OSI protocol stack..."
Umm... although IPv6 is 'newer' than the OSI stack it is just part of the Internet Protocol Suite, which actually predates the OSI stack: if they're moving from a 'truly ancient' stack then it's to something even older.
That's not for letting you access cats video while flying as a passenger - it's to replace or augment the actual ATN network (used for many services like air traffic control, etc.) which uses its own non TCP/IP protocols, with an IPv6-based one.
Anyway I was wrong, it wasn't looking for a new job, he already found a new one - still, LinkedIn looks totally out of place... you have to hope pilots don't change job mid-flight, or spend time updating their LinkedIn profile....
Does anyone remember that the original ARPANET was designed to be a resilient communications network for the military? (The NSA spied on it very early in its development though.) A private internet for traffic control should be pretty good.
But why, then, would they need all of the address space of IPV6? There might be connectivity issues.
Putting it on the public internet using IPV6 doesn't seem like a good idea though.
No, it would just be very costly. And replicating the resilience of the global web is very hard on a tiny replica, so public internet it is.
But I don't like the idea that some state-sponsored hackers (NSA no more than anyone else) are going to be able to play merry mayhem with ATC data.
@Pascal >>>No, it would just be very costly. And replicating the resilience of the global web is very hard on a tiny replica, so public internet it is.<<<
I agree, Beancounters will take the simplistic view that using the public internet is safe for ATC communications until solid proof appears to prove otherwise - hopefully not a youtube demo of two airliners trying to be in the same place at the same time.
AFAIK only a small subset of the IPv6 address space has been allocated. There should be space to allocate a subset to ATN operations.
Security considerations are not irrelevant though, their RFC just name IPSec and TLS, but that's only to protect message contents. What about BGP hijacking? BGP itself shown it's really not a very secure protocol.
Well, why not? The internet was designed to provide redundancy in the event of nuclear war, so provided an additional route for non-essential data traffic seems to be an ideal use case.
Datalink communications are still in their infancy for civil air transport. They only cover 40% of Europe (of which the UK is still more-or-less on a trial basis); there are two competing standards; half the time the aircraft just refuses to log on; the other half ATC don't notice and continue to issue voice instructions. Latency isn't an issue unless we're getting on for 30 seconds or so.
It does cut out of the verbal to-and-fro-ing that is a PITA across Rhein and Maastricht, and it's particularly useful for oceanic routing as it means that position reports are sent automatically, but it's worth noting that the datalink connection over oceans is via satellite.
I think the risks are minimal. It's not like VHF datalink communications are encrypted or secured in any way so a bigger threat is probably someone sat on their roof with a VHF transmitter, a laptop, and an evil plan.
Even worse, the end-to-end network that leads from ATC centre to VHF uplink to aircraft has no end to end error detection. Individual links, yes, but no way to spot corruption in the routers. I'm glad to see the IETF process being used here; less likely that that sort of networking 101 error will get through.
BanburyBill - fake news is the only response to your post.
If you care to glance at the ICAO standard (ICAO Doc 9880 makes for good bedtime reading), you will note that CPDLC (controller to pilot data link communication) includes a high quality 32-bit end-to-end checksum to ensure that any corruption is detected on receipt. The Safety Case for the operational deployments demands that corrupt messages are always discarded and that extensive testing and software assurance is used to certify that the systems really do not work and meet the safety requirements.
Perhaps the most interesting question is why did the journalist pick on this internet draft and not draft-haindl-lisp-gb-atn-01 - which is an alternative proposal for the same thing.
The truth is that there are several competing candidates for the next generation of ATS communications services and various authors are keen to get something published as part of a very competitive process. The IETF documents need to be read as early drafts staking out a territory rather than as final solutions.
The 25 year old ATN/OSI is in day-to-day use and delivering ATC benefits. It delivers high availability and data integrity but only to the level required by routine ATC messaging.
However, there are new applications that need to be deployed in the foreseeable future if we are to continue to both grow the number of air movements and to make air travel even safer. These applications demand communication services with a very high availability - which means a very high probability of successful packet delivery with no corruption, and that this has to be demonstrated by both testing and software assurance. You are looking at 99.99% and better. And yes, it has to be demonstrably secure given that DoS attacks would reduce the achieved level of availability.
To achieve this requires a re-engineering of the communications service. There is nothing that you can really say that is intrinsically better about IPv6 when comparing IPv6 with the CLNP used in the ATN/OSI. It's just when you are re-engineering a system, it is good practice to bring it up-to-date with current practice.
As for the public internet! Commercially delivered VPNs maybe, IPsec overlays possibly - but that's the limit.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
