The Internet- Locator/ID separation protocol?
The Internet is facing problems.
There has been exponential growth with Internet usage and the scalability of today’s Internet routing system is now a concern. There has been a major drive in routing table growth and its met with the limitations and constraints of router technology and current Internet addressing architectures. If we look at the core Internet protocols that comprise the Internet, we have not experienced any significant change in more than a decade. There has been radical change to the physical-layer mechanisms that underlie the Internet but there has been only a small number tweaks to BGP and its transport protocol TCP. Mechanism such as MPLS were introduced to provide a workaround to the limitations of IP within the ISP but essentially there has been no substantial change at Layer 3 or Layer 4 for over a decade.
Default Free Zone ( DFZ )
The first large-scale packet switching network was called ARPAnet – the predecessor of the modern Internet. It used a simplex protocol called Network Control Program ( NCP ). NCP combined addressing and transport into a single protocol. Many applications were built on top of NCP and it was very successful for its time. However, it lacked flexibility. As a result, reliability was separated from addressing and packet transfer in the design of the Internet Protocol suite, with IP being separated from TCP. On the 1st January, 1983 ARPAnet officially rendered NCP and moved to a more flexible and powerful protocol suite – TCP/IP. The transition from NCP to TCP/IP was known as “flag day” and it was easily done with only 400 nodes to recompute.
Today, a similar flag day is not possible due to the sheer size and scale of the Internet backbone. The requirement to change anything on the Internet is driven by necessity and its usually slow to make any changes to such as vast network. For example, inserting an additional header into the protocol would impact IP fragmentation processing and congestion mechanism or changing the semantics of IP addressing is hard as the IP address has been used as an identifier to higher level protocols and encoded in the application.
There are many factors driving the growth of the Default Free Zone ( DFZ ). These mainly include the use of multi-homing, traffic engineering and policy routing. The Internet Architecture Board ( IAB ) met on October 18-19th in 2006 and their key finding was that they need to devise a scalable routing and addressing system. Such an addressing system must be able to meet the current challenges of multi-homing and traffic engineering requirements.
Locator/ID separation protocol ( LISP )
There has been some progress with the development of Locator/ID separation protocol ( LISP ). LISP is a routing architecture that redesigns the current addressing architecture. Traditional addressing architecture uses a single names, the IP address, to express two functions about a device. The first function is its identity i.e who and the second function is its location i.e where.
LISP separates IP addresses into two namespace: Endpoint Identifiers ( EIDs ), which are non routable addresses assigned to hosts, and Routing Locators ( RLOCs), routable addresses assigned to routers that make up the global routing system.
Separating these functions offers numerous benefits within a single protocol, one of which attempts to address the scalability of the Default Free Zone. LISP is a network-based implementation with most of the deployment at the network edges. As a result LISP integrates well into the current network infrastructure and requires no changes to the end host stack.
BGPs role on the DFZ
BGP is the protocol used to exchange NLRI between devices on the Internet and is the most critical piece of Internet architecture. It is used to interconnect Autonomous systems on the Internet and it holds the entire network together. Routes are exchanged between BGP speakers with UPDATE messages. The BGP routing table ( RIB ) now stands at over 520,000 routes.
Although some of this growth is organic, a large proportion of the growth driven by prefix de-aggregation. Prefix de-aggregation leads to an increased number of BGP UPDATE messages injected into the DFZ. UPDATE messages require protocol activity between routing nodes that result in additional processing required to maintain the state for the longer prefixes. Excess churn exposes the core of the network to the dynamic nature of the edges. This has a detrimental impact on routing convergence, since UPDATES need to be recomputed and download from the RIB to the FIB. It is commonly viewed that the Internet is never fully converged.
Security in the DFZ
Security is probably the biggest problem facing the Internet and there is no magic bullet. There is an arms race under way, as techniques used by attackers and defenders co-evolve. The Internet was designed to move packets from A to B as fast as possible, irrespective of whether B wants any of those packets.
In 1997, a misconfigured AS7007 router flooded the entire Internet with /24 BGP routes. Routing was globally disrupted for more than 1 hour as the more specific prefixes took precedence over the aggregated routes. More specific routes advertised from AS7007 into AS1239 attracted traffic from all over the Internet into AS1239, saturating its links and causing router crashes. There are automatic measures to combat prefix hijacking but they are not widely used or compulsory. The essence of BGP design allows you to advertise whatever NLRI you want and its up to the connecting service provide to have the appropriate filtering in place.
BGP’s main drawbacks concerning security is that it does not hide policy information and by default it doesn’t validate the source. However, as BGPv4 runs over TCP it is not as insecure as many like to think. A remote intrusion into BGP would require guessing the correct TCP numbers to insert data and most TCP/IP stacks have hard-to-predict TCP sequence numbers. In order to compromise BGP routing, a common method is to insert a rogue router that must be explicitly configured in the target’s BGP configuration as a neighbor statement.