Author Archives: Russ
Author Archives: Russ
In this edition of the Network Collective, Eyvonne, Jordan, and I talk about where the ‘cast has been, and share some thoughts on where it is going. While we like technology as much as anyone else, the NC is really all about community.
In particular, we discuss the upcoming subscription service. We have a lot of new, exciting, material being recorded around the skills needed to be a better engineer exclusively for the subscription service. For instance, we’ve started a series on communication that does not take the standard line, but looks at how to communicate from the perspective of our experience in living on every possible side of the network engineering world, and developing and delivering every possible kind of content. And we have our first Q&A guest lined up, as well as a lot of fantastic material from Rachel Traylor already being recorded. This is going to be fantastic material, designed to push your career forward in a way that includes technology, but goes beyond technical skills, as well.
While the network engineering world tends to use the word resilience to describe a system that will support rapid change in the real world, another word often used in computer science is robustness. What makes a system robust or resilient? If you ask a network engineer this question, the most likely answer you will get is something like there is no single point of failure. This common answer, however, does not go “far enough” in describing resilience. For instance, it is at least sometimes the case that adding more redundancy into a network can actually harm MTTR. A simple example: adding more links in parallel can cause the control plane to converge more slowly; at some point, the time to converge can be reduced enough to offset the higher path availability.
In other cases, automating the response to a change in the network can harm MTTR. For instance, we often nail a static route up and redistribute that, rather than redistributing live routing information between protocols. Experience shows that sometimes not reacting automatically is better than reacting automatically.
This post will look at a paper that examines robustness more deeply, Robustness in Complexity Systems,” by Steven Gribble. While this Continue reading
Exploitation of Rowhammer attack just got easier. Dubbed ‘Throwhammer,’ the newly discovered technique could allow attackers to launch Rowhammer attack on the targeted systems just by sending specially crafted packets to the vulnerable network cards over the local area network. Known since 2012, Rowhammer is a severe issue with recent generation dynamic random access memory (DRAM) chips in which repeatedly accessing a row of memory Continue reading
Way back in the old days, the unit I worked at in the US Air Force had a room with a lot of equipment used for processing classified information. Among this equipment was a Zenith Z-250 with an odd sort of keyboard and a very low resolution screen. A fine metal mesh embedded in a semi-clear substrate was glued to the surface of the monitor. This was our TEMPEST rated computer, on which we could type up classified memos, read classified email, and the like. We normally connected it to the STU-3 through a modem (remember those) to send and receive various kinds of classified information.
Elovici, Mordechai Guri, Yuval. “Bridgeware: The Air-Gap Malware.” Accessed May 13, 2018. https://cacm.acm.org/magazines/2018/4/226377-bridgeware/abstract.
The idea of TEMPEST begins way back in 1985, when a Dutch researcher demonstrated “reading” the screen of a computer using some relatively cheap, and easy to assemble, equipment, from several feet away. The paper I’m looking at today provides a good overview of the many ways which have been discovered since this initial demonstration to transfer data from one computer to another across what should be an “air gap.” For instance, the TEMPEST rated computer described Continue reading
Despite this renewed rhetoric, most experts continue to agree that exceptional access, no matter how you implement it, weakens security. The terminology might have changed, but the essential question has not: should technology companies be forced to develop a system that inherently harms their users? The answer hasn’t changed either: Continue reading