[ Review #6 ] Bumps Along The Way

Week 2 | Review of Understanding BGP Misconfiguration by Ratul Mahajan, David Wetherall, and Tom Anderson

Any system intended for good use can cause disruption when misconfigured or not used properly and with care. The Border Gateway Protocol (BGP) is no exception. The paper Understanding BGP Misconfiguration looks at misconfiguration errors with BGP and aims to determine how frequent they happen, what the usual causes are, how big their impact is, and how could they be lessened.

The paper’s quantitative nature (it claims to be the first quantitative study on BGP misconfigurations) is evident through the paper with the inclusion of tables and graphs which made analysis and comparison with the numbers easier. Misconfigurations are often times not reported (and even not detected as they don’t always result to connectivity issues) except for a few that landed in news articles due to the widespread outage and/or network disruption they have caused. With this challenge, the paper have thoroughly documented the methodology and data used. Historical data on a 3-week period from 23 different vantage points were used to observe traffic and determine abnormalities. They have contacted the ISPs involved to verify if the abnormality was in fact a misconfiguration. Due to the staleness of the data, 30% of the emails bounced or got accepted by the wrong person (no longer connected to the company or not connected at all). Nevertheless, for the responses, the paper have reported that even with limited data, the answers of the limited correspondents still converged to the same things.

The paper looks at BGP misconfiguration problems and mainly classified them into 2 (import and export) and further subdivided them into 2: slips and mistakes. Slips were defined to be an error in execution of a correct plan while mistakes, on the other hand, are errors that have originated early in the planning and even if the plan was executed correctly, errors would still exists.

For most of the instances, it was human error that caused a huge chunk of misconfigurations. TO address these, several solutions were proposed to aid the human operator in making less mistakes. This included the proposition of a more friendly interface, the ability to set up configurations automatically, an easier way to detect if configuration errors have gone wrong, etc.

Aggressive error reporting and detection was also one of the proposed solutions. As what the paper has always reiterated, most errors are left undetected (since they just fail silently or erroneous packets are just dropped) unless a connectivity error arises or network administrators turn off filters in special scenarios.

Overall, the paper provided a comprehensive view of BGP misconfigurations, its types and classifications, usual causes, and possible preventive solutions. There was a part in the paper though that I felt loss in differentiating exports and import misconfigurations (maybe that was just me though). Maybe a thorough introduction and explanation on imports and exports and a concrete example of these types of misconfigurations before diving in the actual numbers and comparison would be more helpful. The succeeding examples, tables, graphs, and actual measurements were very helpful in analyzing how the different errors compare and how one is more frequent or more disruptive than another. The paper has also described very well the methodology used and how results were obtained, as well as its scope and limitations.

Advertisements

Eventful August weeks!

So hello there! Hope you’re having a wonderful weekend so far!!!

This post may come as a surprise in the middle of lengthy paper reviews hehe. This post would also be my first personal not-so-technical post in this blog but I’ll make it as interesting as it could be. 🙂

So the past weeks have really been eventful – so many things I had been looking forward to, things I have been really busy with (but also enjoy at the same time), and things that I can’t help but smile about. SO here they are in chronological order:

    • Readings! My graduate class for the sem, CS 255, is reading-heavy! But it was okay, I actually loved it! The papers assigned are very interesting and I think these are essential knowledge that every CS student should know and I’m glad that we’re exposed to these kinds of technical readings. Oh and after reading our assigned papers, we are also assigned to do blog posts about them (that explains the many review posts recently hihi). Indeed Sir Festin was right, one’s reading would be different and a lot more deeper if it was intended to be relayed after.Screen Shot 2015-08-21 at 7.10.54 PM
    • Good coffee and matcha! The past few weeks were also much loaded with caffeine – both from coffee and green tea! Readings are best paired with a Venti-size Hot Green Tea Cream Latte in the morning and even in the evening. ❤ And thank you so much to the kind barista who generously make people smile all the time.Screen Shot 2015-08-21 at 7.20.19 PM
    • WebGeek Devcup 2015: Wootwoot! Probably one of the highlights of my August! This was my first time to join a official hackathon and the sleepless night was truly worth it! It was a weekend to be remembered, so much learning!!! #mostproductiveweekendeverrrr #flink #thankyouelijahandkiefer #codesteak5everrrrrScreen Shot 2015-08-21 at 7.23.08 PM
      Screen Shot 2015-08-22 at 7.02.07 PM
  • AWS August Meetup! So legit! Great speakers for the night, learned so many new things :’D
  1. IMG_1121

    Josh with “Making the Most Out of AWS”

That’s my photo series for this post! 🙂 ‘Til my next adventure post!

[ Review #5 ] Around the World in A Millisecond

Week 2 | Review on Interdomain Internet Routing by Hari Balakrishnan

The internet is such a vast architecture whose view of its internal workings have already been simplified to us, users. For example, as you are reading this, dear reader, hundreds of packets are travelling hundreds of miles around the world, passing through routers and getting carried through by links. The paper Interdomain Internet Routing discusses what’s happening behind the scenes of the internet – how your requested content from the other side of the world arrives to you in a split second!

This paper is a really nice read after having read the past 4 papers* that discussed how distributed (rather than a single centralized) administration was one of the original goals of the internet and is fortunately still being preserved through the years. Distributed management allows administrative borders possible between networks which then allows these networks to have their own rules and policies governing their respective spaces. This division also calls for a system with a set of rules and protocols to manage the exchange of messages between each network.

This paper discussed a lot about addresses and how they allow delivery of messages to their intended destinations. The paper also described topological addressing (use of prefixing such that addresses could be chopped to segments to determine to which intermediary router it should be sent first) which allowed communication and routing between millions and billions of network possible.

It was also interesting to know that there exists a “competitive cooperation” between different domains (a.ka. Autonomous Systems) in the pursuit of profit and interconnection. Despite competition, there is still the need to cooperate and communicate which forced them to make compromises and still find a way to become profitable.

Two kinds of relationships that exist between networks were then discussed. These are transit and peering. It’s just notable that terms have actually developed to describe these kinds of relationships which just shows that there was great necessity to define these relationships especially in contracts and financial settlements. With these relationships, the paper have also expounded on the different instances by which ISPs would prefer to prioritize one request over another in the pursuit of making money, saving money, and pursuing their own benefit.

The Border Gateway Protocol (BGP), which allows interconnection between different autonomous systems, were also widely discussed. It is interesting to also know that there actually exists two types, eBGP (external) and iBGP (internal). The paper made a good point to clear out that iBGP is not the same with Internal Gateway Protocols (protocols which are responsible for path metrics inside the same network). And these two types of BGP (whether internal or external) are still the ones responsible in knowing the addresses of the external domains they’ll be connecting on. Different attributes such as NEXT HOP, A SPATH, LOCAL PREF, and MULTIPLE-EXIT DISCRIMINATOR, were also discussed to give a view on how networks prioritize and determine as to which router it will route the message next.

Overall, the paper provided a great overview on how different domains allow routing to and from them and the many factors that affect their prioritization and willingness to do so. The paper also never failed to give an insight to the current situation and scenario, the problems that have arose and the solutions applied. Mistakes and intentional attacks are not foreign in the Interne such as the real life example of Youtube being inaccessible to consumers due to a single person’s error and the lack of control and checks in succeeding entities where the error got passed on. This just emphasises the fact that at the end of the day, we are still interconnected and one’s error and wrongdoing could affect the whole world.

Because at the end of the day, our actions are still interconnected to one another wherever domain we belong.

On a one last note, the line “… good technical research can be be shaped and challenged by commercial realities” hit me the most and made me realize that each domain in the network (and even in life) have their own motives and agendas and these affect their decisions in different scenarios. As what the past papers* said, investment and funding affect the direction as to which network development is going.

P.S. I just remembered that this paper could also be related with the current Internet scene here in the Philippines – in the news, many groups have already expressed concern regarding our Internet connectivity which is super slow and whose service quality is below par yet but whose prices are already skyrocketing.

ASEAN Internet Speed

Based on the ASEAN Internet Speed Survey of 2014, the Philippines have the slowest Internet in Southeast Asia, and the 2nd in whole Asia.

Photo from ASEAN DNA.

Some people have attributed this problem with ISP monopoly where, according to them, many ISPs are actually owned by only 3-4 business conglomerates. Despite these, it is still heartwarming to know that there are efforts in making the Internet available to everyone here in the country, such as WifiNation and Internet.org’s launch here in the Philippines.

Another P.S. (Aug 22, 2015, 12:01 AM): Just came across a Youtube link to the live streaming (c/o Rappler) of the Senate Hearing on PH Internet speed last August 18, 2015.

[ Paper Review #4 ] Casting the Net into the Wider Ocean

A Paper Review for “Rethinking the design of the Internet: The end to end arguments vs. the brave new world” by David D. Clark

David D. Clark’s Rethinking the design of the Internet: The end to end arguments vs. the brave new world  looks at the internet’s evolution through the years which has gone from being a military tool to something that is now commercial and more consumer oriented. This evolution is vastly influenced by a growing user base with varying motivations and purposes in using the internet.

The desire of the rising third parties (i.e. government, ISPs, organizations, etc)  to be involved so as to manage and control the internet has also pulled the internet evolution into many different ways as well.

The end to end argument, one of the major design philosophies behind the original internet structure, was the paper’s main backbone in showing the reader how the internet has evolved and how it continues to evolve. The end to end argument states that the responsibility for additional features should be handled via the end hosts and only minimal extra work should be done by the network core though different needs and wants of the different sectors of the society today (i.e. need for protection – anonymity and accountability, need for accommodation of more advanced applications, need for ISP service differentiation, need and want of third-parties to get involved) gear the Internet away from the end to end argument and shift its development to a design where most of the work is done by the network core and less is done by the end-users.

Instances of the the internet’s misuse and abuse has also lead to users’ erosion of trust, the most fundamental change that is evident today. Many users are now more conscious of their security and privacy, desiring for anonymity but at the same time, also of accountability. Consumers have also been vigilant that it is not only the network that could be dangerous but also the hardware and software that they own.

The rise of third parties also had a great gravity on where the internet is heading. Governments wanting to track citizen activities for security, taxation, and surveillance purposes, organizations claiming their right for transmitted data (i.e. copyright, fee, collection, etc), and ISPs being our gateways and determinants of what kind and type of service is accessible just show the rich objectives of the society and the various, but sometimes contradicting, values they employ.

On a positive note, the use of third parties can also address the need for security by verifying the communication between two parties (i.e. with the use of public key certificates, etc). But with this solutions comes another dilemma, how could end users be sure that it is really the third party verifying the communication?

The effect and importance of laws for the cyberspace have also been thoroughly discussed as a possible major tool in protecting users of the internet (i.e. laws that impose strict compliance of data labelling rules) and as a driving force to lessen (if not fully eliminate) its misuse and abuse.

The paper concluded with an assessment of where we are right now and a suggestion that we don’t need to drift completely away from the end-to-end argument but instead we can build a set of principles that interoperate with the end-to-end argument as well as new principles to address the current situation and community the Int.

The paper has thoroughly discussed the current situation in the Internet today and was able to compare how it was before to how it performs now and if it still aligns with the basic guiding principles and design approaches of the initial creators. This comparison is helpful to the reader in seeing the different factors that shaped the Internet. Citing real life examples and scenarios was also helpful in helping the reader relate to the paper. 

Indeed, there exists a tug of war between the different key players in the Internet (users, government, ISP, organizations, investors, etc) in influencing one’s experience with the Internet. There are those who impose rules and there are those who evade them, there are those who want to be anonymous, and there are those who want accountability disclosed. With these driving forces, it is exciting to see where the Internet will be 10 years from now, scary to think of the possible abuses people can do with it, but also hopeful to think of the possible defences and benefits it could give its users in the future.

[ Paper Review #3 ] Expanding the Net

A Paper Review for “Architectural Principles of the Internet (RFC 1958) “

The paper presents the general architectural principles of the internet including guiding questions and tenets that were observed and have worked in the past and could be useful in present and future evaluations and innovations in the internet. Guidelines when integrating algorithms, patented mechanisms, and security features were also presented.

It has effectively acknowledged different changes that happened through the years especially the possibility of the internet being used worldwide (i.e. the internet requiring support for localization).  With this, readers could see how the internet has evolved from being something deeply motivated solely for military purposes to something that the whole world can now use for interconnectivity. Even with this huge leap, the paper was still successful in presenting that the present state of the internet is still aligned with the original work’s ultimate goal of connectivity with the internet protocol as the tool and with responsibility residing end to end (fate-sharing). It was also a good point to mention that there is still absence of a central administration that could turn off the internet at any time which was one of the things that the creators have also avoided in designing the system as it is also one of the reasons why interconnected networks were motivated in the first place.

The paper also fairly states what the expectations and ideal scenarios in the network are and compare them with practical reality. For example, ideally there should only be one protocol governing the internet but practically there are various reasons as to why multiple protocols need to coexists (i.e. gradual migration to a different IP version and multiple need-specific protocols).

Given all these, the paper was very successful in providing readers an insight as to how the internet incrementally evolved (i.e. small steps rather than complete overhauls). It gives the readers an idea of the changes that happened through the years and an indirect assessment of whether these are still aligned with the original goals and principles.

It is also worth noting that given the guidelines presented, there is a sense that the internet really have further developed and the lower level priorities, as described in “The Design Philosophy of the DARPA Internet Protocols” by David D. Clark, that are yet tot be achieved in the past is already in the process of being achieved in the present. These include the consideration and importance given to cost, performance, accountability and even security which became necessary with the evolution of a larger user base.

[ Paper Review #2 ] Analyzing the Net

A Paper Review for “The Design Philosophy of the DARPA Internet Protocols” by David D. Clark.

The paper comprehensively looks into the motivation, reasoning, and set of priorities upon which the internet protocol suite was built. An understanding of the guiding principles helps provide context and alignment to developers of future extensions.

The most fundamental goal upon which the internet came about was an effective way to multiplex utilization of existing networks which also came from the original mother goal of connecting the ARPANET with ARPA packet radio networks to provide packet radio users access to larger machines.

An alternative to this fundamental goal was to have a unified network system thus removing the need to further incorporate a variety of networks. But with this solution, incorporating existing interconnected networks will still be necessary. Having a unified system may also fade away the administrative boundaries of control that are present in separate interconnected networks.

To further elaborate the most fundamental goal stated above, the paper discusses key sub-goals that help define what is expected by the main goal especially on describing how “effectivity” could be achieved. These subgoals include survivability even with loss of connectivity, ability of handling different kinds of services and different varieties of network, distributed network management, cost-effectivity, and accountability.

It is worth noting that survivability, support for multi-services and network types came on top of the list. Accountability and cost effectivity, on the other hand, were some of the goals that appeared later in the list. The paper makes a good point to remind the reader that this is so because the original purpose was for military use and that the priorities were listed in the order which the initial purpose need the most.

Survivability was of primary importance as connection in the military field may be intermittent and error in network connection may be frequent. Communication must be restored (i.e. handled at the backend to appear smoothly in the application’s perspective) at the state where it was interrupted once connection is back. The fate-sharing concept was introduced which gave the responsibility of tracking connection states to end hosts (rather than on the network) so that the only time these states could be lost is when the entity, too, is destroyed.

Support for different services came in next and was achieved by the datagram’s flexibility as a building block upon which additional services can be built on top (i.e. to to make it reliable, fast even if not reliable, etc) depending on the need. Though it was also acknowledged that for most networks already built with a given assumption and service, its behaviour will be the same all throughout and features can’t be turned off anytime.

Next came multi-network flexibility and was provided by having assumptions that networks can send reasonably-sized packets within a reasonable amount of time within a network equipped with an addressing scheme. Features outside these assumptions (low delay, high reliability, etc) are more likely to be done at the transport layer and not on the network as to prevent the need of re-implementing the feature for every single network of the host.

It was also mentioned that preceding top sub-goals were achieved but the ones at the bottom of the list are yet to be fully achieved such as distributed management which is somewhat already achieved as different networks and interfaces are already managed by different control centers.

Cost, on the other hand, is not yet fully realized with 40 byte packet headers consuming a huge overhead for 1 byte messages. Retransmission would also add cost especially when retransmitted packets pass by the same interfaces where it has already been successful prior to network loss.

One of the paper’s resounding opinion on the things that could be improved and one of the reasons as to why the lower level goals are yet to be achieved is the lack of tools during that time. Tools for the purposes of distributed resources management and network evaluation would help answer the guiding questions in developing an effective network such as expected bandwith and identification of necessary redundancies to allow alternative paths in case one breaks.

Tools like protocol verifier exists to check the logical correctness of a given protocol but as the paper argues this is not enough as a network could be logically correct but could suffer from poor performance. This is aggravated by the fact network that performance can’t be formalized (i.e. due to lack of tools and structure’s inclination for variability and flexibility) but should appear in contracts so contractors are required to perform and meet them. But since these can’t be handled by the system, it is the end hosts’ responsibility to ensure them and procurer’s obligation to include them in the contracts.

Implementation details and design decisions (i.e. packets vs byte regulation) were also thoroughly discussed together with their current implications, and future potential possibilities.

The paper was effective in showing that there are definitely priorities and motivation behind every design decisions done in building the internet structure and those are the reasons why it was moulded that way. Even if only most of the top priorities were achieved and the others are yet to be achieved in full, it is remarkable that these priorities have already been recognized and been identified as important. In achieving this, the paper first gave context of the goals importance, how it was achieved, what was done, problems encountered during implementation, solutions applied, and possible extensions and improvements. The details of the solution also included an expectation vs reality perspective as well as a proposal vs implementation comparison. This style provides the reader an involvement in the problem solving and solution discovery processes.

It is also evident that during the time of writing that even if the internet structure was already one amazing working structure, there are still things that are visibly lacking such as tools for assessment and design guidance. But it is worth noting that the authors were aware of the need for it and that they were not entirely blind spots.

Present assumptions and notions about the internet (i.e. datagrams were thought to be provided because those are what the system exactly needs but actually it was provided as a building block on which additional services could be built depending on need) were also challenged and this was successful in making the reader take part in a mental debate.

It is also worthy to acknowledge that the paper came in a neutral tone with no bias. Advantages and disadvantages were fairly discussed, as well as suggestions and recommendations. It is also aware of the scope and limitation at which its subject operates (i.e. TCP not being for XNET and digitized speech).

The paper could be more comprehensive if it also discussed the present state of network security during the time of writing. Security and its many possibilities with network were briefly discussed in the paper of Cerf and Kahn and is probably one of the features that readers would also be looking out for in this assessment.

[ Paper Review #1 ] Weaving the Net

A Paper Review for “A Protocol for Packet Network Intercommunication” by Vinton G. Cerf and Robert E. Kahn.

During the time when the paper was written, packet switching networks are being widely studied and researched for the purpose of sharing computer resources within the same network. To communicate, a common set of protocols has been agreed upon between two endpoints. However, these existing protocols only address communication within the same network.

The paper describes and discusses a protocol design that would allow communication between computers in two different networks. Protocols exist in typical packet switched networks but differ from network to network. Different networks may also have different addressing schemes, maximum sizes accepted, timings, and fault detection mechanisms, and restoration mechanisms. Thus, to allow for internetwork communication, these differences should be addressed and be standardized (ie. uniform addressing format, ability to separate data into smaller chunks, and end-to-end coordination and communication).

First, the term gateway was used to introduce an interface between networks and the one who’ll be responsible for routing data to their destinations based on addresses. To achieve this, addresses, which will then be stored in internetwork packet headers, should come in a standard format and should uniquely identify a host in the network.

Since data is not universally restricted to be small, various data sizes should be handled by chunking data into smaller bits or fragments. But this fragmentation should still allow re-assembling of data at the destination.

With these differences, it may be natural to think that gateways should be the one responsible to compensate for this but the authors are suggested that only minimal work should be done at the interface because this could cause timing delays and even deadlocks due to the operations’ complexity.

With the gateway not being responsible for this, it is also noted that interconnection should not affect the internal working of a system and that as much as possible the need for central external administration and control among networks should be avoided.

To achieve this, the paper suggests the existence of a transmission control program (TCP) that transmits and receives messages in behalf of the many processes of the system. It is also the one responsible in breaking up outgoing packets to smaller bits and re-assembling incoming packets for delivery to their destination processes (determined through their process headers).

To reassemble fragmented pieces of data, it is important to have a sense of their original sequence. And this is was done through sequence numbers which are unique to each source-destination port and would allow proper placement of the particular fragment even if the whole packet is not yet complete.

Acknowledging that no transmission can be 100% reliable, the authors also proposed retransmission for recovering unreceived bits, and as a consequence, the need for duplicate detection. For this purpose, both sender and receiver are equipped with a window system to allow them to synchronize – know which packets to send and know which to receive. Acknowledgments are also sent by the receiver upon receipt of packet, and at the absence of none after a certain timeout, the sender resends the packet.

Queueing, discarding, and fault detection were also discussed along with several solution mechanisms such as checksums and flags.

With the concept being new at the time of writing and with the describing nature of the paper, the illustrations and graphs were very helpful to visualize the protocol being described. In example, Figure 3 makes it easier to picture out gateways as interfaces between networks and where networks could connect to eventually be connected to another. This is especially helpful in their time when computers are just usually connected to the same network the idea of a interconnected network is still fairly new.

FIgure 2 and 3 from "A Protocol For Packet Network Intercommunication"

FIgure 2 and 3 from “A Protocol For Packet Network Intercommunication”

 

In describing the different aspects of the protocol being discussed (i.e. addressing,  fragmentation, responsibility ownership, etc), the scenario and problems were presented first followed by the initial solution/natural inclination which will then be discussed with its pros and cons. And then a suggested solution/authors’ inclination is presented and thoroughly discussed. This manner of writing is helpful to a reader as there is much greater appreciation of the solution as an omniscient view of the situation is given. There is also collective involvement, together with the reader, in arriving at a mutual opinion. The explanation of the authors’ positions were also more of the suggestive type, not imposing but effectively persuading.

The paper is a truly comprehensive description of the protocol being discussed and multiple aspects were explored. It is also worth noting that the paper is also aware of the limitations and future improvements of the protocol being described. Edge cases, fault detection, security possibilities were also not overlooked and are actually thoroughly discussed. The paper also did not come off as intimidating even if it was new technology at that time. It is also amazing that security possibilities and points for improvement  were briefly described even if they were not part of the main priorities of the system.