Russ

Author Archives: Russ

Security ‘net: Internet of Things and iPhones edition

One of my college professors has suggested that the question of whether or not Apple should help the FBI break the encryption on the iPhone used by a terrorist is an ideal diagnostic question for your view of all things privacy. There are, of course, gray area answers, like “Apple should help the FBI break the encryption in this case, but not others.” The problem is, of course, that this isn’t the simple answer it might seem. First, there are motives behind the apparent motives. Many people see Apple as just “doing what’s right to save the world.” I don’t see it that way at all. Given I’m a bit cynical (who would have guessed), I see two motives from Apple’s point of view.

First, Apple is trying to protect a marketing stance. They’ve as much as admitted this in court documents and the implied threat of suing the U.S. Government for loss of revenue if they’re forced to build a version of their O/S that will allow the FBI to break the encryption. Just Security notes—

There are other interests at stake here too. Apple has a liberty interest in not being dragooned into writing forensic Continue reading

Why you should care about complexity

If you look across a wide array of networking problems, you will see what is an apparently wide array of dissimilar and unrelated problems engineers deal with on a daily basis. For instance—

  • Should I split this flooding domain into multiple parts? If so, where should I divide it?
  • Which routing protocol should I use on this network topology, and to solve this set of problems?
  • How should I configure the Quality of Service parameters on this network?
  • Should I use MPLS on my data center fabric, or straight IP?

Over my years as a network engineer, I’ve always treated these as separate sorts of problems, each with their own tradeoffs, concepts, and models. In fact, I’ve been a kindof “collector of models” over the years, trying to find different models to address each situation. In the Art of Network Architecture, there’s an entire chapter on the models Denise and I have run in to over the years, where they seem to be useful, and where they seem to be limited. complexity-model

But keeping all of these models in my head didn’t help me generalize the problems I faced in building and troubleshooting networks. For instance, in the flooding domain instance Continue reading

Worth Reading: The myth of in-memory computing

These days when you talk to people in the tech industry, you will get the idea that in-memory computing solves everything. The story is that RAM has become so cheap that you can just stuff all your data in-memory and you won’t have to worry about speed any more. But it is just a myth. Companies that buy into this myth will almost certainly regret that choice in the near future. -via the next platform

LinkedInTwitterGoogle+FacebookPinterest

The post Worth Reading: The myth of in-memory computing appeared first on 'net work.

Security ‘net: Security by obscurity

This week I have two major themes to discuss on the topic of security, and one interesting bit of research. Let’s start with some further thoughts on security by obscurity.

First: Obscurity isn’t security

I’ve heard this at least a thousand times in my life as a network engineer, generally stated just about the time someone says, “well, we could hide this server…” Reality, of course, is far different; I still put curtains on my house even though they don’t increase the amount of time it takes a thief to break in. Whether or not we want to believe it, obscurity does play a positive role in security.

But there are two places where obscurity is a bad thing in the world of security. The first is the original reference of this common saying: algorithms and implementations. Hiding how you encrypt things doesn’t improve security; in fact, it decreases the overall security of the system. The second place? Communication between companies and security professionals about the types, frequency, and methods of attack. Imagine, for a moment, that you were commanding a unit on a battlefield. You hear the sounds of combat in the distance. Realizing a unit in your army is Continue reading

Worth Reading: IPv6 Paradigm Change

Link-Local Addresses (LLAs) have the rather obvious property of being linked locally. This means that a layer-3 route cannot route IP packets destined to a LLAs. Instead they can only be forwarded within a layer-2 domain. As such, LLAs have an interesting security property – they cannot be reached from outside of the layer-2 link as they are hidden and isolated. -via apnic

LinkedInTwitterGoogle+FacebookPinterest

The post Worth Reading: IPv6 Paradigm Change appeared first on 'net work.

Securing BGP: A Case Study (4)

In part 1 of this series, I looked at the general problem of securing BGP, and ended by asking three questions. In part 2 and part 3, I considered the third question: what can we actually prove in a packet switched network. For this section, I want to return to the first question:

Should we focus on a centralized solution to this problem, or a distributed one?

There are, as you might expect, actually two different problems within this problem:

  • Assuming we’re using some sort of encryption to secure the information used in path validation, where do the keys come from? Should each AS build its own private/public key pairs, have anyone they want to validate the keys, and then advertise them? Or should there be some central authority that countersigns keys, such as the Regional Internet Registries (RIRs) so everyone has a single trust root?
  • Should the information used to validate paths be distributed or stored in a somewhat centralized database? At the extreme ends of this answer are two possibilities: every eBGP speaker individually maintains a database of path validation information, just like they maintain reachability information; or there are a few servers (like the root DNS servers) Continue reading

Worth Reading: In the Trenches with OpenStack

In a sense, and oversimplifying a bit, OpenStack is an automation framework for Linux that just happens to allow Windows instances to run on KVM, just like the Azure cloud and Azure Stack are similar extensions to Windows Server that just so happen to also support Linux instances on Hyper-V. There have been a dozen releases of OpenStack since that time, on a six-month cadence of April and October launches that, interestingly enough, have also regularized the pattern for Linux operating system launches, too. -via the next platform

The post Worth Reading: In the Trenches with OpenStack appeared first on 'net work.

Research ‘net: Dirt jumper -smart

Distributed Denial of Service (DDoS) attacks are often used to hold companies—particularly wealthy companies, like financial institutions—to ransom. Given the number of botnets in the world which can be purchased by the hour, and the relative ease with which new systems can be infected (especially given the rise of the Internet of Things), it’s important to find new and innovative ways to protect against such attacks. Dirt Jumper is a common DDoS platform based on the original Dirt, widely used to initiate such attacks. Probably the most effective protection against DDoS attacks, particularly if you can’t pin down the botnet and block it on a per-IP-address basis (try that one some time) is to construct a tar pit that will consume the attacker’s resources at a rate faster than your server’s are consumed.

The paper linked here describes one such tar pit, and even goes into detail around a defect in the Dirt Jumper platform, and how the defenders exploited the defect. This is not only instructive in terms of understanding and countering DDoS attacks, it’s also instructive from another angle. If you think software is going to eat the world, remember that even hacking software has defects that Continue reading

Worth Reading: Leave Your Gas Can at Home

There seems to be a trend in IT, where everyone likes to play follow the leader. Everyone uses the same vendor for the same things, and they try to use the same cookie cutter pattern. If you have any decent exposure to various organizations, you’ll know that’s just not the case. Trying to shove a square peg in a round hole, never works out well. -via Packet Pushers

The post Worth Reading: Leave Your Gas Can at Home appeared first on 'net work.

Should Technology Mirror Business?

The essence of SDN is to create a software model of the current data network business. This quantitative model is based on volumes of data: what ‘bandwidth’ resources do I have (i.e. supply), and how can I give different quantities of this ‘bandwidth’ to different users and uses (i.e. demand)? -via circleid

I’ve been in information technology since the early 1990’s, and it’s always been like this: business tells IT what to do, and IT does it. In other words, we make technology mirror business. Which is a fine formula for success, so long as you think business is the engine of innovation. The problem is innovation doesn’t come from one department or place. In fact, innovation most often comes from the intersection of two or more things. Think about it.

When did cars first start being innovative? When they combined the technology that existed in the latest horse drawn carriages with the latest in industrial technology, including internal combustion engines and assembly line production. All three of these came from someplace else—many people don’t know the idea of interchangeable parts came out of the firearms world, rather than the automotive industry. When did innovation come into the Continue reading

Worth Watching: The Economics of the Internet

Old economics explains the new economy well. When we buy something, we spend time and money searching for it, comparing it with other products, negotiating a price, and ensuring that we get what we paid for. This is what economists call ‘transaction costs.’ The internet dramatically reduces these costs, making it cheaper for people, businesses and governments to do business. -via the World Bank

The post Worth Watching: The Economics of the Internet appeared first on 'net work.

Securing BGP: A Case Study (3)

To recap (or rather, as they used to say in old television shows, “last time on ‘net Work…”), this series is looking at BGP security as an exercise (or case study) in understanding how to approach engineering problems. We started this series by asking three questions, the third of which was:

What is it we can actually prove in a packet switched network?

From there, in part 2 of this series, we looked at this question more deeply, asking three “sub questions” that are designed to help us tease out the answer this third question. Asking the right questions is a subtle, but crucial, part of learning how to deal with engineering problems of all sorts. Those questions can be summed up as:

  • Is the path through this peer going to pass through someone I don’t want it to pass through?
  • Is the path this peer is advertising a valid route to the destination?

Let’s quickly look at the first of these two to see why it’s not provable in the context of a packet switched network, using the network diagram below.

bgp-sec-02

When working with BGP at Internet scale, we tend to think of an autonomous system as one “thing”—we Continue reading

1 … 136 137 138 139 140 … 162