Thoughts on Practical Declarative Network Management

Authors: Timothy Hinrichs, Natasha Gude, Martin Casado, John Mitchell, Scott Shenker

Published in: Workshop on Research in Enterprise Networks (WREN) 2009

Summary:
The authors designed, implemented, and tested a language for declarative network policies --- Flow Management Language (FML). The language has no ordering and is declarative. Conflicts in rules can arise and are handled by prioritizing keywords (e.g. deny has higher priority over allow). Because the language has no ordering the authors claim it is easier to write and reason about and is can accommodate multiple authors more easily. Application developers can have control over flows and can write rules themselves.

They implemented the FML engine over Nox and deployed it on two campuses. The implementation can process rules in linear time and can handle heavy loads. The implementation was done by using trees in order to evaluate rules. The deployment seems to be working, and they had the ability to introduce new keywords (HttpRedirect) into the language to handle complex cases.

The Good:
The paper makes it clear that FML is a flexible language that can be used to declare network policies nicely. But not only is it flexible, concise, and based on principals, it can be evaluated in linear time. The implementation and deployment provides good evaluation. The tree implementation for implementation is a very cute idea. I think I will be using it for my stuff :) I liked the fact that new keywords can be added, but is it easy to do?

The Bad:
The authors argue that ordering is a bad idea. Yet, they end up enforcing some form of ordering by making policies cascade. OK, so it's not ordered within a single cascade, but I'm not sure you would write rules without cascades. They did not make the case for lack of ordering well. I think it is really really difficult to reason about flows in the case of conflicts. I do not see how the combination of conflicts + keyword prioritization + cascades is simpler than a total ordering on all statements. The argument about making it easier for multiple authors does not really hold water because it seems that authors would have priority, and you don't want conflicts anywhere. In fact, I don't see how multiple authors can operate easily in FML, even with cascades!

Unfortunately, I don't see how application developers (or do they mean Nox applications?) can control their own flows. Is their an API? I thought FML was pre-compiled, how do users add their own stuff there?

The Ugly:
I really did not like the non-ordering, cascading, and keyword prioritization stuff. It seemed to make things much more complex. The fact that conflicts are allowed negates a whole bunch of things they had said about making it clearer to reason about things. I don't see its necessity, or maybe there is some necessity (such as to make it easier for implementation) but I don't recall it was mentioned in the paper.

Thoughts on SCADS: Scale-Independent Storage for Social Computing Applications

Authors: Michael Armburst, Armando Fox, David Patterson, Nick Lanham, Beth Trushkowsky, Jesse Trutna, Haruki Oh

BibTeX:
@proceedings { citation185,
title = {{SCADS}: Scale-independent storage for social computing applications},
year = {2009},
month = {01/2009},
booktitle={Conference on Innovative Data Systems Research {(CIDR)}}
URL = {http://www-db.cs.wisc.edu/cidr/cidr2009/Paper_86.pdf},
author = {Michael Armbrust and Armando Fox and David Patterson and Nick Lanham and Haruki Oh and Beth Trushkowsky and Jesse Trutna}
}

Summary:
The authors are working on a framework that allows developers to scale up as well as scale down easily. There are three main parts to this: A query language that does not compromise performance with scale, a declarative policy that allows developers to specify performance levels that the framework should achieve, and machine learning algorithms to rapidly scale up and down. One of the main points is that consistency can be traded for performance.

The Good:
The system looks cool. It would be nice to have the performance of memcached with a flexible query language. It's nice to throw all the load on some machine learning algorithm to scale up and down.

The Bad:
System is still preliminary.

The Ugly:
This seems a huge amount of work. I wonder if it will ever work.

Thoughts on Efficient Instantiations of Tweakable Block Ciphers and Refinements to Modes OCB and PMAC

Author: Phillip Rogaway

Summary:
Tweakable block ciphers are ciphers that take three inputs (key, tweak, block) instead of the usual two (key, block) such that different tweaks can create different permutations that are all still secure. This eliminates the need for changing keys if we want to have a different block cipher. The paper describes how efficient tweakable block ciphers can be constructed from regular block ciphers such that tweaks can be incremented cheaply, while keeping the tweaked cipher secure.

The paper then describes changes to OCB and PMAC that make the two algorithms easier to understand and their security simpler to prove.

The Good:
I'm not a cryptographer, so the fact that I understood most of the paper is very significant. The paper is well written, and somewhat easy to understand. I didn't go through the proofs, so I can't say anything about them. It's a good introduction to tweakable block ciphers, and what can be done with them. The constructions they use for making tweakable block ciphers easy and efficient to construct are nice and seem to be quite useful.

The Bad:
I didn't really get what else I can do using these tweakable block ciphers and the instantiations Rogaway came up with. I wish he explained more plainly what these can be used for other than improving OCB and PMAC.

The Ugly:
The notation was a little annoying. It was difficult to keep track of what the tildas and bars meant. While consistent, the notation was difficult to follow because there were too many symbols introduced or used in place of others "to simplify the notation".

Thoughts on Hurry Down Sunshine

Author: Michael Greenberg

Summary:
The author relates the story of when his daughter had her first manic attack, i.e. went mad. She was hospitalized, and then released. Her mania was kept a secret. Sally herself appears to be a very smart and poetic kid. The author was living in a state of frustration and confusion for the summer. The book has a significant number of anecdotes on other famous people and their dealings with mania like James Joyce with his daughter. The author also relates the stories of other members of his family.

The Good:
The book was a wonderful read. It was simple to understand, easy to read, and very captivating. I found it difficult to put the book down. The book offered some very interesting insights into mania and how it affects the victim and her family. The book also has some intersting facts on mania to teach.

The Bad:
None really.

The Ugly:
None really.

Thoughts on The Omnivore's Dilemma

Author: Michael Pollan

Summary:
The author tries to follow four food chains: the industrial, the industrial organic, the pastoral, and the forest.

Industrial: Corn -> Cattle -> processing -> supermarket -> McDonald's -> Humans
Industrial Organic: Corn -> Cattle/Chicken -> supermarket -> Humans
Pastoral: Grass -> Animals -> Humans
Forest: Hunt/gather -> humans

The book describes origins of corn and its history, how food became cheap, and so on. It talks about each piece in the food chains above in details and talks about their history. The last part about hunting and gathering was particularly entertaining.

The Good:
The book inspired me to start my own garden. I've learned a load of interesting trivia and information. It is very entertaining and eye-opening.

The Bad:
At times the author is a little too judgmental and biased. But this is not too bad.

The Ugly:
None really.

Thoughts on Pathlet Routing

Authors: P. Brighten Godfrey, Igor Ganichev, Scott Shenker, Ion Stoica

Summary:
The paper presents a solution to the multipath routing and scalalability problems in the current Internet that uses BGP. The new solution solves these problems while allowing all BGP policies, exposing a large set of paths, making it possible to know what paths would be used, giving senders the choice in path selection, and reducing the size of the forwarding information base (FIB). The dataplane works as follows:

• Each network will label its routers and end-hosts with one or more vnodes.
• Each network exposes a vnode to its neighbors. When packets arrive from that neighbor, they will arrive to the exposed vnode.
• Each network constructs a set of paths it allows using its vnodes and the neighbor's vnodes. These paths are called pathlets.
• Each pathlet is labeled with a forwarding identifier (FID), and each (first hop vnode, FID) pair is globally unique. The first hop vnode is the first vnode in a pathlet identified by its FID.
  
• Pathlets are disseminated through the network (this is the control plane's job).
• A network can then proceed to construct more general pathlets that start at a vnode in the network but can contain vnodes in other non-neighboring networks.
• These "general" pathlets are of the form v1, FID1, ..., FIDn
  
• A sender constructs a path by finding a number of pathlets that together connect the sender to the receiver. The path looks like the following: v1, F1, ..., Fn where the Fi are FIDs.
  
• When the packet arrives at the router labeled v1 in the sender's provider, the router checks that v1 is the start of the pathlet identified with F1, and drops it if not.
• Otherwise, there are two choices. 1) If the FID1 is a "base" case FID that only connects local vnodes with neighboring vnodes, the router pops v1 and F1 from the path and replaces them with the vnode v2 at the end of the pathlet. 2) Otherwise if F1 is a "generalized" pathlet, then is replaces v1 and F1 with v2, FID2, ..., FIDm. So the packet now has path: v2, FID2, ..., FIDm, F2, ..., Fn.
• Each (vnode, FID) pair at the beginning of the path is either replaced with one vnode or with a vnode and a list of other FIDs, until the destination is reached.

Note that a sender cannot cheat because only allowed paths will have valid FIDs, and packets wanting to use FIDs must arrive at the correct vnode.

Pathlet dissemination uses a path vector algorithm.

For a particular class of transit policies the authors call local transit (LT) policies, forwarding tables in the switches can be very small. These LT policies construct only "base" case pathlets that only have local vnodes or neighboring vnodes. Unfortunately, these policies cannot depend on a route's destination such as in BGP.

They come up with the notion of "policy emulation" to compare their architecture to others. They define "policy emulation" as: protocol P can emulate protocol Q if P can produce every outcome that Q can produce while using a similar amount of overhead. By their admission, this definition is limited since it has no notion of security or cost.

Pathlet routing can emulate BGP and IP strict routing with no modifications. To emulate MIRO and NIRA, the authors needed to extend the pathlet routing dissemination protocol to allow a router to pull pathlets from a non-neighboring vnode. On the other hand, pathlet routing cannot emulate "generalized" NIRA or Feedback Based Routing (FBR) because they use a packet's previous hops. In addition, FBR has both blacklisting and whitelisting that can represent some policies much more efficiently than pathlets. Pathlet rouing cannot emulate routing deflections and path splicing since they would require a large amount of control traffic to the senders.

The evaluation was alright. They cite a much smaller number for average AS-level path length than we expected (3.77) using CAIDA as-rank.caida.org. The maximum header size they use is 10 bytes which is very reasonable. I didn't look too deeply at the eval, and nothing popped out as weird or extraordinary.

The Good:
They describe a really cute way to do source routing while adhering to transit network policies. They do this while still not requiring a large overhead. While hinted at in the paper, pathlets and vnodes can be used for various network level services such as QoS. They also came up with the interesting notion protocol emulation.

The Bad:
There is a practicality side that has been completely overlooked: how do you actually put this in the real world. First, I don't know how to build such a thing easily in hardware. Also, the packet size changes between hops; how does this affect feasibility? What about security? Can the vnodes be attached to the neighbors?
[edit] Actually I don't really think the above is so important (after much more thinking). What's more important is the following:

1. It is difficult (if not impossible) to create policies that depend on prefixes of the path
2. The ASes can screw with a source by using a different path
3. The receiver has no idea what path was followed (Can it even tell what sender sent something?)

The Ugly:
I really did not like the fact that they needed an "extension" to the dissemination protocol. This seemed like a hack in order to allow pathlet routing to emulate NIRA and MIRO. Then again, they could probably come up with a nicer and more efficient dissemination protocol.

Thoughts on Why Cryptosystems Fail

Authors: Ross Anderson

BibTeX:

@inproceedings{168615,
author = {Anderson,, Ross},
title = {Why cryptosystems fail},
booktitle = {CCS '93: Proceedings of the 1st
ACM conference on Computer and communications security},
year = {1993},
isbn = {0-89791-629-8},
pages = {215--227},
location = {Fairfax, Virginia, United States},
doi = {http://doi.acm.org/10.1145/168588.168615},
publisher = {ACM},
address = {New York, NY, USA},
}

Summary:
The author uses automated teller machines (ATMs) as a driving example through the paper. He explains how ATMs work, and how various attackers have or could have managed to defraud banks by attacking ATMs. These attacks are allowed due to human error, negligence, or malignance, lack of quality control, lack of a feedback loop, incomplete standards, ... Mainly, it is not due to the weaknesses usually studied formally in universities or companies such as cryptanalysis. The author maintains that security systems should be treated similar to safety critical systems. Security systems should have certification levels that take a whole security system into account from the cryptography at its lowest levels to the training of employees to the treatment of a wide array of threats.

The Good:
The paper presents a strong point well, mainly that security systems should be studied by looking at the environment where it will be used. The paper includes many interesting examples from the banking industry and the analogy between secure systems and safety critical systems such as avionics helps drive the point home.

The Bad:
The author says that the right paradigm is to make a security officer's job less mechanical by following the aviation industry's paradigm: a properly trained crew is the first line of defense. I'm not sure what he means by that point, but it is difficult to train people well, and even then it is difficult to do quality control over their work. It seems we would want to build systems that have been designed keeping in mind that individual components themselves are probably insecure but when put together make the whole system secure. Perhaps this is what he meant.

The Ugly:
There were way too many examples. I would have much preferred that the author elaborated on the paradigm developed and how it applies to some examples, than just list the examples for a few pages. Many things are obvious too, but that's probably because this is an older paper and we now know more.