Thursday, September 27, 2007

Public vs. Private Firewall Policies

One of the mantras in the security world that has perplexed me is the notion that firewall policies should always be kept hidden from everyone else. The rationale of course is that if the rules are hidden, it will make it that much harder to the attacker to gain entry into the system.

However, I am not sure I completely buy that rationale. Is it really that much effort to probe for open ports on guarded systems? Does it really take that long or is itjust a few more minutes while one of the countless botsin the botnet does the remote scanning? Moreover, does the detection of said port scan do any good either withthe sheer volume of typical port scanning going on in a day to day sense?

From a distributed systems vantage point, the silent failure modes of firewalls can be painful to debug. Sure, if the firewall sends an ICMP Port Not Available, that would be great but most simply sink traffic off into /dev/nullleaving the application to slowly time out, often with abysmal service properties. At what point does the benefit of faster debugging outweigh the "security" benefit of hidden firewall rules? I'm guessing the threshold is much lower than what is typically employed. Debugging a normal system is hard, make the system distributed and itturns quickly into a nightmare.

To be fair, there are cases where I think hiding rules is appropriate, specifically when access is constrained to asubset of hosts. The important information to hide is notnecessarily what ports are exposed but to whom access is granted. One could argue that the hiding of this information does significantly impede the progress of the attack as scanning from an arbitrary host gives imprecise information, sort of a Byzantine-esque (I use this term loosely, not precisely) quality to information gathering. Then again,there are likely levels also in this case as well. A simple 'restrict to the local network' policy (aka the local subnet) really doesn't buy that much time or defense but a 'restrict to an obscure host or bank of admin hosts' would potentially improve defenses.

Perhaps should there be a notional ICMP Firewall Denied message to assist with debugging? Likely too problematic for security purposes(reflection DoS attacks) but interesting from a debugging standpoint. The increased tamping down of ICMP messaging (our campus blocks inbound) also likely makes this a non-starter. Perhaps something in TCP? A can of worms but maybe a nominal TCP options field? Something truly crazy would be the ability to query any host for its firewall ruleset. Crazy indeed.

Monday, September 17, 2007

NC State, IEEE BroadNets

Back to the Midwest after my week long foray to North Carolina.

On Monday, I had a chance to visit Vince Freeh and a few folks at NC State in the Electrical/Computer Engineering and Computer Science departments. Their new building is simply amazing I must say. I gave a seminar on our ScaleBox work which had a wonderful attendance despite competing against a speaker on video games who had given a talk earlier that day. Fortunately, it is early in the semester but I was quite impressed by the sheer number of students we packed into the seminar room. The slides should be posted shortly to the NetScale wiki sometime tomorrow (Tuesday).

Tuesday through Thursday was the IEEE BroadNets conference, a nice smaller conference that had evolved out of the former Opticomm with three tracks on general Internet networking, wireless networking, and optical networking. I mixed quite a bit between the Internet symposium and the wireless networking symposium and unfortunately missed a few good talks here and there. There was a paper on Layer 3 Rogue Wireless Access Point detection that I missed and did not have a chance to catch the authors to get a bit more information.

Some of the highlights I thought were:
  • TCP acceleration for low-bandwidth links: The paper that received the best paper award for the Internet symposium focused on neat tricks for improving the perceived performance for bandwidth-limited mobile devices. Neat tricks that are certainly timely in today's current Internet.
  • eMIST testbed: The testbed was a collection of Java test tools for profiling of Internet connectivity on cell phones out of Kevin Almeroth's group at UCSB. Very neat suite of tools that showed some of the pitfalls when trying to design real-time / delay-sensitive applications (primarily games) for mobile devices.
  • TCP Quick Start: A paper by Scharf analyzed the performance of the Experimental TCP Quick Start RFC. Interesting in that Quick Start seems to share some of the properties of the work in the recent DARPA Control Plane effort led by Tim Gibson as the DARPA PM. While the paper focused exclusively on performance, the core protocol is especially interesting in light of our accelerated admission control schemes. In short, Quick Start probes for capacity via IP Options and then ramps up CWND without probing. Of course, the use of IP Options are a non-starter for any real deployment but a gateway or hybrid setup could have quite a bit of promise.
  • PoMo: Interesting work by Griffeon, Calvert of University of Kentucky and Bhatterjee (sp?) of Maryland. The work is sponsored by FIND and makes a good faith effort at separating routing from addressing. Plenty of work to be done as the work is still in its infancy but something to keep an eye on.
  • Ethernet vs. IP in the MAN/WAN: Thanks to my adviser, Arun Somani (the chair at ISU - my alma mater), and Gigi Karmous-Edwards I got roped into serving on a panel discussing the previous topic of a panel consisting of Adel Saleh (DARPA PM), K. K. Ramikrishan (AT&T), and David Allen (Nortel). I learned quite a bit but unfortunately had to follow David Allen who certainly is at the forefront of pushing out Ethernet farther. I highly encourage people to track down both David Allen's slides and K. K. Ramakrishnan's slides as they had interesting perspectives from the ISP and vendor sides. The RFCs governing MACinMAC and PBB-TE are on my list for late night reading when I have a chance. Also neat is that IS-IS is the preferred link state of choice due to its independence of addressing. Research-wise, Adel Saleh's slides are perhaps the most thought provoking as they look at what different permutations might emerge and ask more questions than providing answers. Needless to say I was but a humble assistant professor in the group but I certainly thank Dr. Karmous-Edwards for the wonderful opportunity to be up with the group. You can catch my slides on my musings on what the last-mile is bringing on the NetScale wiki.
All in all, the conference was a very nice small setting where people had excellent opportunities to interact rather than being one among the horde of other attendees (thanks Dr. Rouskas). Next year's BroadNets will be in the UK which should up the European participation significantly and I am guessing will also likely follow the three track formula.

Tuesday, September 11, 2007

Google Talk to iChat

I'm out traveling to IEEE BroadNets for the week and attempting unsuccessfully to connect up to folks using iChat. I'm traveling with my Lenovo tablet as it makes working much easier on the plane (amen to rotating screens and the stylus for doing work).

The use of my tablet of course means that I'm stuck using Windows. While there is an iTunes version for Windows, there is as of yet, no version of iChat for Windows. Hence, I go with option number two, Google Talk which in the past has worked alright. During the winter, it became the stand in for a Ph. D defense at Western Michigan due to inclement weather. Not great but not too bad either.

Anyway, iChat has been positively wonderful on my Mac at work. I can add Google Talk users quite easily and chat without any major issues. Being naive, I assumed the reverse would be true with Google Talk. Perhaps someone can enlighten as to why Google Talk despite using the open Jabber standard insists that I invite users to get a Google Talk account before I can chat with them? The core Jabber protocol isn't terribly difficult and one would think that Google Talk could intermesh nicely with. The whole point of the IETF Jabber effort was to try to standardize these things to get rid of counter-intuitive interactions like this. Near as I could tell, the only way one could chat is with the iChat user initiating the conversation, not the Google Talk user.

More later in the day (or tomorrow) regarding my visit to NC State and the first day of the conference...

Wednesday, September 5, 2007

Batch scheduling - grid computing

One of the recent problems we have been looking at is how to correctly schedule batches of tasks in grid computing where the batches consist of multiple synchronization barriers. For instance, REM (Replica Exchange Management) from the field of bio-complexity sends out a set of N tasks that are synchronized X times (the replica exchange) over the course of the simulation. In short at each synchronization point, all N replicas must finish their respective computation and then a small subset of the data is then exchange to help drive the next set of simulations. Loss tolerance in an m,k sense (m out of k must finish) varies depending upon the application but our current bio-complexity group does not allow for it in their batches.

Currently, the state of the art seems to be employing a catchup cluster of extremely fast machines that notice lagging execution hosts and then migrate the sub-task to the faster catchup cluster. At first glance, this appears to be a rather brute force mechanism for improving performance. While it is hard to argue that it does not have a benefit (who wouldn't benefit from having an idle cluster of fast machines?), there is some interesting theory and tradeoffs to be examined in what the optimal schedule would be and what sort of missed opportunity comes from dedicating the catchup cluster. Moreover, there are certainly practical tradeoffs with regards to job migration (network transfer time) that are also of concern for capturing the tradeoffs correctly. Toss in heterogeneous job execution length (due to parameters), heterogeneous processing capacity of the grid, and possibly the potential for job failure (eviction, node crashing, etc.) and it all gets complicated fairly quickly.

A fascinating problem as it has roots in both grid computing and real-time computing / scheduling (my initial graduate school work). Most interesting is that I think it can draw from some of the properties of the multi-processor EDF (Earliest Deadline First) bound estimation work and may or may not need to employ heuristic-based schemes ala the original Spring kernel scheduling approach. Comments are of course welcome if anyone has any work of note in this particular area.