Russ

Author Archives: Russ

IPv6, DHCP, and Unintended Consequences

I ran into an interesting paper on the wide variety of options for assigning addresses, and providing DNS information, in IPv6, over at ERNW. As always, with this sort of thing, it started me thinking about the power of unintended consequences, particularly in the world of standardization. The authors of this paper noticed there are a lot of different options available in the realm of assigning addresses, and providing DNS information, through IPv6.

Alongside these various options, there are a number of different flags that are supposed to tell the host which of these options should, and which shouldn’t, be used, prioritized, etc. The problem is, of course, that many of these flags, and many of the options, are, well, optional, which means they may or may not be implemented across different versions of code and vendor products. Hence, combining various flags with various bits of information can have a seemingly random impact on the IPv6 addresses and DNS information different hosts actually use. Perhaps the most illustrative chart is this one—

Each operating system tested seems to act somewhat differently when presented with all possible flags, and all possible sources of information. As the paper notes, this can cause Continue reading

snaproute Go BGP Code Dive (14): First Steps in Processing an Update

In the last post on this topic, we found the tail of the update chain. The actual event appears to be processed here—

case BGPEventUpdateMsg:
  st.fsm.StartHoldTimer()
  bgpMsg := data.(*packet.BGPMessage)
  st.fsm.ProcessUpdateMessage(bgpMsg)

—which is found around line 734 of fsm.go. The second line of code in this snippet is interesting; it’s a little difficult to understand what it’s actually doing. There are three crucial elements to figuring out what is going on here—

:=, in go, is a way of appending the information in a data structure with more information. So, for instance, if you do something like this—


a-string = "this is a"
a-string := " string"

The result, in a-string, is this is a string. Whatever else this snippet is doing, then, it is taking something out of the data structure, and appending it to the bgpMsg structure. What, precisely, is it taking from the data structure?

The * (asterisk) is a way to reference a pointer within a structure. We’ve not talked about pointers before, so it’s worth spending just a moment with them. The illustration below will help a bit.

Each letter in the string “this is a string” Continue reading

Worth Reading: Hyper Moore’s Law

Over the last year in particular, we have documented the merger between high performance computing and deep learning and its various shared hardware and software ties. This next year promises far more on both horizons and while GPU maker Nvidia might not have seen it coming to this extent when it was outfitting its first GPUs on the former top “Titan” supercomputer, the company sensed a mesh on the horizon when the first hyperscale deep learning shops were deploying CUDA and GPUs to train neural networks. —The Next Platform

LinkedInTwitterGoogle+Facebook

The post Worth Reading: Hyper Moore’s Law appeared first on 'net work.

Reaction: Openflow and Software Based Switching

Over at the Networking Nerd, Tom has an interesting post up about openflow—this pair of sentences, in particular, caught my eye—

The side effect of OpenFlow is that it proved that networking could be done in software just as easily as it could be done in hardware. Things that we thought we historically needed ASICs and FPGAs to do could be done by a software construct.

I don’t think this is quite right, actually… When I first started working in network engineering (wheels were square then, and dirt hadn’t yet been invented—but we did have solar flares that caused bit flips in memory), we had all software based switching. The Cisco 7200, I think, was the ultimate software based switching box, although the little 2ru 4500 (get your head out of the modern router line, think really old stuff here!) had a really fast processor, and hence could process packets really quickly. These were our two favorite lab boxes, in fact. But in the early 1990’s, the SSE was introduced, soldered on to an SSP blade that slid into a 7500 chassis.

The rest, as they say, is history. The networking world went to chips designed to switch Continue reading

Traffic Pattern Attacks: A Real Threat

Assume, for a moment, that you have a configuration something like this—

db-key-traffic-attack

Some host, A, is sending queries to, and receiving responses from, a database at C. An observer, B, has access to the packets on the wire, but neither the host nor the server. All the information between the host and the server is encrypted. There is nothing the observer, B, can learn about the information being carried between the client and the server? Given the traffic is encrypted, you might think… “not very much.”

A recent research paper published at CCS ’16 in Vienna argues the observer could know a lot more. In fact, based on just the patterns of traffic between the server and the client, given the database uses atomic operations and encrypts each record separately, it’s possible to infer the key used to query the database (not the cryptographic key). The paper can be found here. Specifically:

We then develop generic reconstruction attacks on any system supporting range queries where either access pattern or communication volume is leaked. These attacks are in a rather weak passive adversarial model, where the untrusted server knows only the underlying query distribution. In particular, to perform our attack Continue reading