At the inter-domain level, the Internet topology can be represented by a graph with Autonomous Systems (ASes) as nodes and AS peerings as links. This AS-level topology graph has been widely used in a variety of research efforts. Conventionally this topology graph is derived from routing tables collected by RouteViews or RIPE RIS. In this work, we assemble the most complete AS-level topology by extending the conventional method along two dimensions. First, in addition to using data from RouteViews and RIPE RIS, we also collect data from many other sources, including route servers, looking glasses, and routing registries. Second, in addition to using routing tables, we also accumulate topological information from routing updates over time. The resulting topology graph on a recent day contains 44% more links and 3% more nodes than that from using RouteViews routing tables alone. Our data collection and topology generation process have been automated, and we publish the latest topology on the web on a daily basis.

IONSince late 1999, DDoS (Distributed Denial of Service) [1,2,3] attack has drawn many attentions from both research and industry communities. Many potential solutions (e.g., ingress filtering [6,7], packet marking [5,8,9,10,11] or tracing [4], and aggregate-based congestion control or rate limiting) have been proposed to handle this network bandwidth consumption attack. Among them, "ICMP traceback (iTrace)" is currently being considered as an industry standard by IETF (Internet Engineering Task Force). While the idea of iTrace is very clever, efficient, reasonably secure and practical, it suffers a serious statistic problem such that the chance for "useful" and "valuable" iTrace messages can be extremely small against various types of DDoS attacks. This implies that most of the network resources spent on generating and utilizing iTrace messages will be wasted. Therefore, we propose a simple enhancement called "Intention-Driven" iTrace, which conceptually introduces an extra bit in the routing and forwarding process. With the new "intention-bit", it is shown that, through our simulation study, the performance of iTrace improves dramatically. This work has been proposed to IETF's ICMP Trace-Back working group.

Abstractm Despite BGP's critical importance as the de-facto Internet inter-domain routing protocol, there is little understanding of how BGP actually performs under stressful conditions when dependable routing is most needed. In this paper, we examine BGP's behavior during one stressful period, the Code Red/Nimda attack on September 18, 2001. The attack was correlated with a 30-fold increase in the BGP update messages at a monitoring point which peers with a number of Internet service providers. Our examination of BGP's behavior during the event concludes that BGP exhibited no significant abnormality, and that over 40% of the observed updates can be attributed to the monitoring artifact in current BGP measurement settings. Our analysis, however, does reveal several weak points in both the protocol and its implementation, such as BGP's sensitivity to the transport session reliability, its inability to avoid the global propagation of small local changes, and its certain implementation features whose otherwise benign effects only get amplified under stressful conditions. We also identify areas for improvement in the current network measurement and monitoring effort.

During the past twenty years the Domain Name System (DNS) has sustained phenomenal growth while maintaining satisfactory performance. However, the original design focused mainly on system robustness against physical failures, and neglected the impact of operational errors such as misconfigurations. Our recent measurement effort revealed three specific types of misconfigurations in DNS today: lame delegation, diminished server redundancy, and cyclic zone dependency. Zones with configuration errors suffer from reduced availability and increased query delays up to an order of magnitude. Furthermore, while the original DNS design assumed that redundant DNS servers fail independently, our measurements show that operational choices made at individual zones can severely affect the availability of other zones. We found that, left unchecked, DNS configuration errors are widespread, with lame delegation affecting 15% of the DNS zones, diminished server redundancy being even more prevalent, and cyclic dependency appearing in 2% of the zones. We also noted that the degrees of misconfiguration vary from zone to zone, with most popular zones having the lowest percentage of errors. Our results indicate that DNS, as well as any other truly robust large-scale system, must include systematic checking mechanisms to cope with operational errors.

Measurements have shown evidences of inter-domain packet forwarding loops in the Internet, but the exact cause of these loops remains unclear. As one of the efforts in identifying the causes, this paper examines how transient loops can be created at the inter-domain level via BGP, and what are the major factors that contribute to duration of the routing loops. As a path-vector routing protocol, BGP messages list the entire AS path to each destination and the path information enables each node to detect, thus break, arbitrarily long routing loops involving itself. However, delays due to physical constrains and protocol mechanisms slow down routing updates propagation and the routing information inconsistencies among the nodes lead to loop formation during convergence. We show that the duration of transient BGP loops match closely to BGP's routing convergence time and the looping duration is linearly proportional to BGP's Minimum Route Advertisement Interval Timer (MRAI) value. We also examine four BGP routing convergence enhancements and show that two enhancements effective in speeding up routing convergence are also effective in reducing routing loops.