GA Tech: Internet's Mid-Layers Vulnerable To Attack 166
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."
Really? Why not link to the original paper? (Score:5, Informative)
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 [gatech.edu]
Re:ossified? (Score:5, Informative)
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 [cambridge.org]) you'll find this definition.
Re:What we need is a P2P (Score:4, Informative)
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.
What are you talking about? (Score:4, Informative)
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.
Re:It's hard to take seriously... (Score:4, Informative)
I've never really been a fan of the OSI model. The idea of the hierarchy is great; sandwiching it into discrete layers seems problematic.
Wikipedia's definition of the OSI model [wikipedia.org] states that "there are seven layers, each generically known as an N layer. An N+1 entity requests services from the layer N entity." Makes sense. So, why are both ICMP and IP considered to be in layer 3? ICMP is built on top of IP, so it should be in the layer above IP, but it doesn't actually provide transport (or at least, isn't meant to). HTTP is in layer 7, but it can be sent directly on top of TCP, which is in layer 4, skipping over two layers. (Or it can be tunnelled over SSL, but still skipping layer 5.)
I prefer to think of the IP stack being a directed acyclic graph of technologies, each depending on another, rather than an explicit linear division into layers.
Re:It's hard to take seriously... (Score:5, Informative)
Well, you can imagine a "null" layer that does nothing, just passes the data unmodified to the next layer.
For example, HTTPS would be HTTP over SSL, SSL wouls be level 6 (presentation). If you use HTTP without SSL then level 6 is empty or uses the "null" protocol.
ICMP is part of IP, while you could say that the ICMP packet is inside an IP packet it is easier to imagine ICMP as just a part of IP, because it is used that way (for example, to signal that some other packet could not be delivered).
Just because I can send the HTTP packet inside an Ethernet frame (without IP or TCP), does not mean that the model is broken, it's just that "null" is a valid protocol.
Re:It's hard to take seriously... (Score:5, Informative)
So, why are both ICMP and IP considered to be in layer 3?
Because the Internet protocols are not in fact part of the OSI model, despite lots of teaching materials claiming this. The neat little OSI layer diagrams you see with all the layers filled in are mostly retcons invented long after OSI was dead.
The actual Internet protocol suite is not part of the OSI model but the 4-layer Internet model [wikipedia.org] (Link, Internet, Transport, Application). Link is like OSI layers 1 and 2, Internet is like OSI Layer 3, Transport is like OSI Layer 4, Application is like OSI Layer 7, but there is no actual Internet equivalent of OSI's layers 5 and 6. Pretty much everything above 4 runs at Layer 7.
In the Internet model, it makes perfect sense for DHCP, IP and ICMP and routing protocols like RIP and OSPF to be at the Internetworking level because they are both protocols dealing with datagram transmission between interconnecting disparate packet-switched services, while TCP and UDP are in the Transport layer because they make dealing with raw datagrams somewhat more pleasant.
It would perhaps be sensible to invent a whole new layer model now that we have a lot more protocols. HTTP, for instance, should be a layer of its own, since so many things are now tunnelled over it. That would be sensible, though, so good luck.
Re:It's hard to take seriously... (Score:5, Informative)
It would perhaps be sensible to invent a whole new layer model now that we have a lot more protocols. HTTP, for instance, should be a layer of its own, since so many things are now tunnelled over it. That would be sensible, though, so good luck.
Thinking of a fixed set of layers stops being useful as soon as you get moderately complex network setups because these days encapsulations tend to happen at all sorts of layers. Modern networks can probably be thought of more as a stack of protocols with the link layer at the bottom, application at the top and chopped up repetitive bits of the stack in the middle.
e.g. take for example a modern connection to a website and we probably see this kind of stack:
HTTP
SSL
TCP
IP
PPP
PPPoE
Ethernet
ATM VC-Mux
ATM
G.922.5 data link layer
Physical ADSL
And that's just for a plain home ADSL connection. In more complex networks it is common to encapsulate stuff further, for example using GRE tunnels or IPSEC tunnels, and it isn't uncommon to see something more like:
HTTP
SSL
TCP
IP
IPSEC ESP
IPSEC AH
IP
Ethernet
GRE
IP
GRE
IP
PPP
PPPoE
Ethernet
ATM VC-Mux
ATM
G.922.5 data link layer
Physical ADSL
And you can keep adding encapsulation layers at pretty much any point in the stack.
Re:It's hard to take seriously... (Score:5, Informative)
FTP (and FTPS) uses two ports: one fixed port number and the other random. You also have passive mode and "active" mode for FTP (but everyone these days uses passive, except one particularly backward vendor I had to deal with).
This causes firewall headaches because now the packet filter must understand FTP and selectively punch holes in the firewall for the data connection, and close them when the data connection finishes. Either the packet filter in the OS kernel must understand FTP, or you must use an FTP proxy that can dynamically modify your packet filter rules.
SFTP requires none of this. It works on a single port and this port doesn't change with each file you want to transfer or directory listing you want to see. You can also use the scp command which is much cleaner for scripting than writing FTP scripts. SFTP is a *lot* easier and cleaner to support, and the encryption is built right into the protocol, not added ad-hoc some time later.