on the "Analysis of the Increase and Decrease Algorithms for Congestion Avoidance in Computer Networks[1]"

The paper presented a mathematical analysis of increase/decrease algorithms for congestion avoidance in computer networks. Congestion avoidance algorithms allow a network to operate at an optimal level of low delay and high throughput. The authors evaluated the set of increase/decrease algorithms based on the following criteria:

1. the algorithm should allow the communication system to operate at a level of optimal resource utilization (high efficiency).

2. the algorithm not only ensures efficient utilization of shared network resources, but see to it that there is fairness in the allocation of such resources among the users of the system.

3. the algorithm should be distributed to make the tasks of the system and the users simple as possible.

4. the algorithm, starting from an arbitrary initial state, should achieve goal 1 and 2 as fast as possible.

They focused their analysis to a set of increase/decrease algorithms which uses linear controls as control functions. A control function is used by a user of the system in increasing or decreasing its load utilization.

Their analysis used graphical vector representation of the different control combinations to identify the configurations of feasible linear controls that would allow the system to reach the goal of optimal resource utilization and fairness resource allocation as fast as possible. Using this approach, they found out that a simple linear control with an additive increase and multiplicative decrease components is enough for the system to achieve high efficiency and fairness.

Ref:

[1] D.-M. Chiu and R. Jain, "Analysis of the Increase and Decrease Algorithms for Congestion Avoidance in Computer Networks", Computer Networks and ISDN Systems, Vol. 17, 1989, pp. 1-14.

on the 'Rethinking the design of the Internet: 2 The end to end arguments vs. the brave new world'

The author of the paper reiterates the design principles that have been guiding the development of the Internet up to the present, called end-to-end arguments. End to end arguments in the context of the Internet, follow the notion of making the functions of the lower layers of the Internet infrastructure as simple as possible. Any application-specific features should be pulled out of the core infrastructure and should be implemented at the end systems instead. It proceeds by arguing that these design principles have been the key driving factor of the advances and innovations that the Internet has been experiencing since its early days. This position paper was written in the face of increasing interests of third parties i.e. private entities, governments, demanding the inclusion of new features which would allow more “better” mechanisms for providing security, privacy, accountability, etc. The paper cited a situation wherein implementing “eavesdropping” mechanism at the lower level of the infrastructure would still proved useless, after the fact, that end to end points of the communication are free to apply any available mechanism i.e. encryption, etc., to the messages being exchanged. Instead of providing the benefits one expected from it, it would only add complexity to the core network which in turn would increase the cost of deploying new applications to the Internet.

on the 'The Design Philosophy of the DARPA Internet Protocols'

The paper enumerated and described the various goals behind the DARPA Internet Project which gave birth to what we know now as the Internet; at the same time discussed their relations to the mechanisms which were chose to achieve those goals. The Internet started out as a military funded research project under the Defence Advanced Research Projects (DARPA) of the DoD of the USA.

The main goal of its inception was to provide a way for multiplexed internetwork communications among existing heterogeneous and disparate network infrastructures. Packet switching was chose as the technique for multiplexing since most of the existing networks employ packet switches.

Several second level goals were considered in its design, which proved to have great effects to what have become of it now. Survivability which relates to service availability and continuity tops among the second level goals of the design of the Internet. For example, any interruptions in some part of the network should not disrupt the usability of the whole infrastructure. Also interruptions at the lower layers of the infrastructure should be hidden or abstracted from the application level. Support for multiple services came second. So the designers of the Internet wanted to bring as many services to the Internet as possible. If we remember, reliability was the critical design requirement of the TCP. For some services i.e. real-time applications, the reliability of the TCP comes with a cost, performance degradation. The decision to formally define the boundary (layering) between TCP and IP was made, and another transport layer protocol was created, which is the User Datagram Protocol. UDP provides application a low level interface in performing their needs of internetwork communications, resulting to better control, flexibility and performance. Also, they wanted that the Internet will be able to accommodate various types of networks. Other goals which set at the bottom of the Internet priority list where (4) a mechanism for distributed management of its resources should be provided, (5) it must be cost effective, (6) host attachment must be easy, (7) resources in the Internet must be accountable. Interestingly, (7) has not been fully realized until now.

Surprisingly, there was no explicit mention of security in the original design of the Internet. Survivability was there, but I believe its notion relates more on the physical aspect of the infrastructure. The inclusion of the idea of a datagram as a building block element I think is one of the great realizations of the designers of the Internet. It gives developers better control and flexibility in meeting the networking aspects of the applications that they develop. Fate-sharing is another design decision that has proved to be critical in the development of the Internet. The notion of maintaining state information of communications at the end points only, enabled hosts to be less dependent on the performance of intermediary points in the networks. This provides service continuity on cases when some disruption happens at subset of the network.

on the 'A Protocol for Packet Network Intercommunication'

It was 37 years ago when Turing awardees Vinton Cerf and Robert E. Khan published the seminal paper describing TCP (with implicit mention of IP) which eventually led to the development of the Internet.

The paper proposed a protocol which would allow internetwork communications between processes on hosts residing in different packet switching networks. The paper stated the issue of how would such protocol handles communications between existing and planned packet switching network infrastructure, which would likely be different from one another. So it was here that the idea of having a standard protocol, which is as simple and reliable as possible, for inter process and network communications came in. Since reliability is one of the top concerns of the protocol, a mechanism for detection of ‘lost’ packets and their retransmissions was also included. A sender TCP will wait first for the receiver TCP to acknowledge bytes of messages it previously sent. If it does not receive such acknowledgment within a defined timeout, it re-transmits the unacknowledged bytes. State information of the connection between two communicating processes are kept only at both ends of the communication link, thus making the tasks of intermediary points as simple as possible i.e. only handles forwarding of packets and fragmentation if needed. Provisions for flow control was also included which is based on a window strategy. With this flow control mechanism, the receiver TCP will be able to advertise the number of bytes of data (the window) it can handle to the sender TCP, hence controlling the amount of data that flows between the receiver and sender TCP. One should really appreciate the completeness of the mechanisms or features of the protocol suggested in this paper, considering that most of them were given entirely in their pure theoretical sense. Amazing!

On “Finding Security Vulnerabilities in Java Applications using Static Analysis”

Security in applications is important especially on web applications which handle confidential customer information and financial transactions like banking and e-commerce websites. A simple programming mistake can cause vulnerabilities in application which when exploited can caused irreparable damage to the company and its stakeholders [1].

The most common vulnerabilities in web applications nowadays exploit weak input validation implemented on applications. Attackers can enter specially crafted inputs to the application, making it perform actions which can caused breach of confidential information stored in back-end servers, bring down applications causing denial of service to legitimate users, reveal user credentials to attackers, etc. Examples of attacks are SQL injection and Cross-site Scripting, which belongs to the OWASP top 10 web applications security risks [2].

The paper describes a tool which could be used in probing Java applications for security vulnerabilities stemming from not properly validated input from the user, which they called tainted propagation problems. The tool performs a static analysis on the applications’ byte-code. It tries to determine possible sources of vulnerabilities within the application based on a detailed specification crafted using PQL, a program query language. Because their tool uses improved object naming scheme and more precise context-sensitive pointer analysis, it produces more accurate results, with less false-positives.

One of the strengths of the tool is that, it can be used by developers during the actual development cycle, which in a way cut costs of the development, because it minimizes costs coming from activities like code reviews. The authors also suggested that their approach can be used to implement the same static analysis tool for other byte-code based languages like C#.

REFERENCES

[1] V. Benjamin Livshits and Monica S. Lam. Finding Security Vulnerabilities in Java Applications using Static Analysis.
[2] OWASP Top 10 – 2010: The Ten Most Critical Web Applications Security Risks. The Open Web Security Project. At [www.owasp.org]

On “Why Cryptosystems Fail” and “Father Guido Five Minute University”

In the context of computer security, or security in general, I think that the saying, “A system’s security is as strong as the weakest link”, summarized the relationship of the video “Father Guido Five Minute University” to the gist of the article “Why Cryptosystems Fail”.

The point of Father Guido in his idea of a Five Minute University is that the value of education we get over the years of our stay in a learning institution is relevant to their usability in dealing with the realities we face in the outside world. He says that we usually remember just the things that are actually of use to us (in our job for example), and tend to forget everything else.

In the same manner, the quote above implicitly states the real value/strength of any security system how complex or simple it may be. It’s very common to implement multi-level security system these days. And the value of these security systems is just as good as the weakest component in the chain. A single hole is enough to enable attackers to break into the whole system. In the article, it was stated that most of the attacks on cryptosystems do not exploit their technical weakness, but rather directed to other aspects of the system i.e. physical implementation, poor management, quality control.

So the author suggested a shift in the way we think, in our evaluation of the strength of computer security systems. He said that efforts should be diverted on strengthening the competence of the people involved in implementing other aspects of a security system.


References:

[1] Anderson, Ross. Why Cryptosystems Fail.
[2] _____. Father Guido Sarducci Five Minute University. @[youtube.com]

On "Setuid Demystified" and "Understanding Android Security"

The article entitled “Setuid Demystified” tried to demystify the inner workings of the uid-setting system calls, which are inherent and commonly used on Unix-based operating systems.

The first paper, as its name implies, tried to unravel the way uid-setting systems calls in Unix-based operating systems work. What are these uid-system calls anyway? Well, it’s a sort of an API which one could use/call in Unix-based systems to set or to drop, temporarily or permanently, the privileges i.e. resources, a program can access. For example, when you want a program to run with root privileges, then you’ll probably call one of the functions within this API.

One of the key issues that the researches tried to address on their study is the inconsistencies of the behaviour of these system calls on several Unix-based operating systems. The researchers attributed this to the “ambiguous” or lack thereof, of a specification documenting what these system calls do and how should they do it i.e. the rules or invariants that concern each function. This could possibly lead to some serious security and portability issues on applications developed for such systems as described in the article.

On their study, the researches first tried to determine the behaviour of these system calls across several implementations by examining their actual source files. After trying such approach, they eventually realized the impracticality of what they’re doing, and then they decided to build a more formal methodology. They have implemented a Finite State Automaton (FSA) that covers the different possible states of a particular process altered by the uid-system calls made within it [1]. They tried to automate the process of building such FSA model for each uid-system calls through simulation. Their simulator allowed them to create FSA models faster and less tedious. This in turn enabled them to easily compare the differences of the different FSA model generated from each uid-system call implementation. This lead to a much faster detection of the inconsistencies present in several implementations of each uid-system calls. Moreover, their formal method makes the automation of such detection mechanism possible. The formal method also led to the discovery of some security vulnerabilities in some implementation of the uid-system calls.

The one thing that caught my interest in this paper is the way by which the researchers developed a formal method for an activity that is rather tedious if done manually. Of course they being successful in their study clearly intensifies the possibility of developing formal models for things that may appear so complex at times. Development of such formal methods also enables a deeper understanding of what’s happening “inside” albeit some necessary abstractions are employed.

The other article, “Understanding Android Security”, discussed the core security mechanisms employ on Android, a mobile operating system.

They discussed the mechanism by which Android manage the privileges of the different application running in it. The security framework employed by Android developers follows a permission labeling scheme. An Android developer assigns permission labels to his application by explicitly specifying them on an XML manifest file [2]. These permission labels specify how this particular application handles accesses made by other application to its components. This manifest file is use to set an application’s permission labels during installation and stays permanent until a new installation is made.

Although such security framework is inherent on the Android platform, programming errors made by security-unaware developers are still the major concerns which influenced the existence of security vulnerabilities on Android applications. In this regard, the researchers developed a tool, called Kirin, which automates the verification of consistency of the set of permissions defined in an application.
Automation seems everything, isn’t it?

References:
[1] H. Chen, D. Wagner, and D. Dean. “Setuid Demystified”.

[2] W. Enck, M. Ongtang, and P. McDaniel, “Understanding Android Security”. IEEE Security and Privacy. 2009, pp. 50-57