GA Tech: Internet's Mid-Layers Vulnerable To Attack
An anonymous reader writes "Evolution has ossified the middle layers of the Internet, leaving it vulnerable but security breaches could be countered by diversification of protocols, according to Georgia Tech, which recommends new middle layer protocols whose functionality does not overlap, thus preventing 'unnatural selection.' Extinction sucks, especially when it's my favorite protocols like FTP."
an article which discusses "the six [sic] layers..."
I understand that IP protocols predate the 7 layer ISO/OSI model, but that's what everything is mapped to in modern terms.
The article seems even more confused, when it reverses the layers, claiming that "at layers five and six, where Ethernet and other data-link protocols such as PPP (Point-to-Point Protocol) communicate..."
What are they teaching at GA Tech? This is networking 101.
"National Security is the chief cause of national insecurity." - Celine's First Law
Surely this article should be nodded "massive ignorance"! It's the simplicity of the middle layers that enables the development of the upper and lower levels. It also makes the middle layer much more immune to security issues.
The real "Libtards" are the Libertarians!
Well, I know for myself a good swift "attack" on my "middle layer" does cause me to fall to the ground and writhe around for a while, so I guess the internet and I do have a lot in common, really vulnerable mid-sections.
Monstar L
Not only did they combine the presentation and application layers from the OSI model they completely misunderstand WHY that the transport layer is less diverse in number of protocols.
They propose that we should create new transport protocols that do not overlap with existing ones.... The reason we only have a handful of them is because of the fact that there are not many ways to differentiate a transport protocol.
There seems to be the unstated(but vital to the conclusion asserted) assumption that competition actually makes protocols more secure and that competition must occur at the protocol level, rather than the implementation level. Without those assumptions holding, all this article really says is that people use TCP and UDP a lot. Yup. That they do.
This seems like it might be true in the (not necessarily all that common) case of a protocol whose security is fucked-by-design competing with a protocol that isn't fundamentally flawed, in a marketplace with buyers who place a premium on security, rather than price, features, time-to-market, etc.
Outside of that, though, much of the competition and security polishing seems to be at the level of competing implementations of the same protocols(and, particularly in the case of very complex ones, the de-facto modification of the protocol by abandonment of its weirder historical features). It also often seems to be the case that(unless you are in the very small formally-proven-systems-written-in-Ada market, or something of that sort) v1.0 of snazzynewprotocol is a bit of a clusterfuck, and is available in only a single implementation, also highly dubious, while the old standbys have been polished considerably and have a number of implementations available...
It's the very first Google hit, is still on a public server, and doesn't obviously distort the conclusions like TFSA in an effort to get more clicks. A+ for poorly crafted summaries, Slashdot.
http://www.cc.gatech.edu/~sakhshab/evoarch.pdf
security breaches could be countered by diversification of protocols, according to Georgia Tech, which recommends new middle layer protocols whose functionality does not overlap, thus preventing 'unnatural selection.'
Let's have a lot of protocols right, but to prevent too much diversity (that is, stuff that doesn't work) we'll need to make sure these comply with one or two protocols that everyone will use...
Hmmm, "Middle layer protocols whose functionality does not overlap"... does that mean that we prune the vast abundance of current protocols with sometimes overlapping functionality? I guess we could call that "diversification" though at this level of semantic mismatch, we could call it "Frank" with equal justification.
I guess I'm not quite sold on the argument presented here.
Evolution at the middle layers is also hampered by the proliferation of middleboxes: monkeying with packet headers for policy-enforcement and profit. It's also pretty well de rigueur for IT departments to configure both middleboxes and "smart" switches to drop any unrecognized middle layer packets.
...when you're writing a game...tweak the difficulty of "Easy" to something [your mother] can cope with. -- onion2k
Let FTP die already. Clear text passwords suck.
How do clear text passwords suck for anonymous FTP?
No - the figurative sense of ossified is correct and common. Petrified is usually used figuratively to mean something like "scared stiff". Ossified, in common figurative use, means that something has become stiff and inflexible (often through disuse or rot) - like tissue that has become bone.
If you check a reasonable dictionary (eg. http://dictionary.cambridge.org/dictionary/british/ossify_1?q=ossified) you'll find this definition.
Let's not stir that bag of worms...
There are plenty of those already. NetBIOS is an example of a non-TCP/IP peer-to-peer filesharing protocol (I'm talking LANMAN style NetBIOS, not NetBIOS over TCP/IP). It doesn't route outside your local network though. There's the good ol' IPX/SPX, which can actually be routed if your router supports them - while not filesharing protocols in themselves, they do support some very well-established filesharing protocols. You could probably adapt bittorrent to work on IPX/SPX.
The problem is we can't even get IPv6 routed on the internet, much less some obscure non-IP protocol. Hell, we never even really got all of IPv4 - multicast would have been great for streaming video if anyone had bothered to set up their routers for it.
That being said, you don't need to use TCP and UDP. You can create new protocols to run over IP, and the internet will generally pass them (your local firewall might be a different story). They'll stick out like a sore thumb to anyone searching for them, though.
Those who can't do, teach. Those who can't teach either, do tech support.
ARPANET predates the OSI model, and the current Internet Protocols came after the definition of the OSI stuff. (That's a little hard to see in the current wikipedia articles, but it's there.) The IETF in fact deliberately chose to combine two of the OSI layers.
The article does have some issues. I'm not sure if the author actually doesn't understand the paper he or she is trying to summarize. Maybe the intent was to make it easier for the lay person to understand. But there is some creativity going on, and parts of the summary don't really reflect the paper.
The paper itself is offering a framework of analysis of the evolution of the Internet Protocols. It might have been interesting to see a bit more analysis of ARPANET and some of the other protocols the IP protocols eventually replaced. It might have been interesting to see them address the OSI model a bit more, but the OSI model never was really implemented fully, and might be considered not part of the evolution.
I see that the take IPv6 up as a competitor of IPv4 instead of the heir apparent, which is probably a useful thing to do, if we want to understand why so many IT managers are still failing to move in a timely manner.
I'm not sure I understand their work well enough to either agree or disagree, but I think it offers food for thought, including the idea that IPv4/6 doesn't actually have to be the only protocol existing at that layer.
Computer memory is just fancy paper, CPUs just fancy pens with fancy erasers; the 'net is just a fancy backyard fence.
why should they, they have it installed on YOUR mainframe
Snowden and Manning are heroes.