Allison Mankin

Observation and analysis of BGP behavior under stress

Despite BGPs 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 BGPs 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 BGPs 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 BGPs 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.

An analysis of BGP multiple origin AS (MOAS) conflicts

This paper presents a detailed study of BGP Multiple Origin AS (MOAS) conflicts observed in the Internet. A MOAS conflict occurs when a particular prefix appears to originate from more than one AS. We analyzed data from archived BGP routing tables over 1279 days. Most of the conflicts were short-lived, lasting only a small number of days. The potential causes for the MOAS conflicts and impact on BGP fault-tolerance are discussed in detail.

Detection of invalid routing announcement in the Internet

Network measurement has shown that a specific IP address prefix may be announced by more than one autonomous system (AS), a phenomenon commonly referred to as Multiple Origin AS, or MOAS. MOAS can be due to either operational need to support multi-homing, or false route announcements due to configuration or implementation errors, or even by intentional attacks. Packets following such bogus routes will be either dropped or in the case of an intentional attack, delivered to a machine of the attackers choosing. The paper presents a protocol enhancement to BGP which enables BGP to detect bogus route announcements from false origins. Rather than imposing cryptography-based authentication and encryption to secure routing message exchanges, our solution makes use of the rich connectivity among ASs that exists in the Internet. Simulation results show that this simple solution can effectively detect false routing announcements even in the presence of multiple compromised routers, become more robust in larger topologies, and can substantially reduce the impact of false routing announcements even with a partial deployment.

Protecting BGP routes to top level DNS servers

The Domain Name System (DNS) is an essential part of the Internet infrastructure and provides fundamental services, such as translating host names into IP addresses for Internet communication. The DNS is vulnerable to a number of potential faults and attacks. In particular, false routing announcements can deny access to the DNS service or redirect DNS queries to a malicious impostor Due to the hierarchical DNS design, a single fault or attack against the routes to any of the top level DNS servers can disrupt Internet services to millions of users. In this paper we propose a path-filtering approach to protect the routes to the critical top level DNS servers. Our approach exploits the high degree of redundancy in top level DNS servers and also exploits the observation that popular destinations, including top level DNS servers, are well connected via stable routes. Our path-filter restricts the potential top level DNS server route changes to be within a set of established paths. Heuristics derived from routing operations are used to adjust the potential routes overtime. We tested our path-filtering design against BGP routing logs and the results show that the design can effectively ensure correct routes to top level DNS servers without impacting DNS service availability.

Connection-Oriented DNS to Improve Privacy and Security

The Domain Name System (DNS) seems ideal for connectionless UDP, yet this choice results in challenges of eavesdropping that compromises privacy, source-address spoofing that simplifies denial-of-service (DoS) attacks on the server and third parties, injection attacks that exploit fragmentation, and reply-size limits that constrain key sizes and policy choices. We propose T-DNS to address these problems. It uses TCP to smoothly support large payloads and to mitigate spoofing and amplification for DoS. T-DNS uses transport-layer security (TLS) to provide privacy from users to their DNS resolvers and optionally to authoritative servers. TCP and TLS are hardly novel, and expectations about DNS suggest connections will balloon client latency and overwhelm server with state. Our contribution is to show that T-DNS significantly improves security and privacy: TCP prevents denial-of-service (DoS) amplification against others, reduces the effects of DoS on the server, and simplifies policy choices about key size. TLS protects against eavesdroppers to the recursive resolver. Our second contribution is to show that with careful implementation choices, these benefits come at only modest cost: end-to-end latency from TLS to the recursive resolver is only about 9% slower when UDP is used to the authoritative server, and 22% slower with TCP to the authoritative. With diverse traces we show that connection reuse can be frequent (60 -- 95% for stub and recursive resolvers, although half that for authoritative servers), and after connection establishment, experiments show that TCP and TLS latency is equivalent to UDP. With conservative timeouts (20 s at authoritative servers and 60 s elsewhere) and estimated per-connection memory, we show that server memory requirements match current hardware: a large recursive resolver may have 24k active connections requiring about 3.6 GB additional RAM. Good performance requires key design and implementation decisions we identify: query pipelining, out-of-order responses, TCP fast-open and TLS connection resumption, and plausible timeouts.

Measuring DANE TLSA Deployment

The DANE (DNS-based Authentication of Named Entities) framework uses DNSSEC to provide a source of trust, and with TLSA it can serve as a root of trust for TLS certificates. This serves to complement traditional certificate authentication methods, which is important given the risks inherent in trusting hundreds of organizations—risks already demonstrated with multiple compromises. The TLSA protocol was published in 2012, and this paper presents the first systematic study of its deployment. We studied TLSA usage, developing a tool that actively probes all signed zones in .com and .net for TLSA records. We find the TLSA use is early: in our latest measurement, of the 485k signed zones, we find only 997 TLSA names. We characterize how it is being used so far, and find that around 7–13 % of TLSA records are invalid. We find 33 % of TLSA responses are larger than 1500 Bytes and will very likely be fragmented.

Public key validation for the DNS security extensions

The deployment of DNS Security (DNSSEC) can only succeed if there is an effective mechanism for DNS public key validation. This paper compares three potential approaches to DNS key validation. A tree based approach utilizes the existing structure of the DNS tree to form highly structured key signing rules. This makes following chains of trust simple, but it allows no flexibility for individual zones and makes incremental deployment impossible. A pure web of trust based approach imposes no structure what so ever on the key signing process. This lack of structure provides a high degree of local control, but also makes it difficult to find trusted chains or specify security policies. The third approach is a new proposal based on a the concept of a fault-tolerant mesh of trust. The mesh approach utilizes some structured elements from the tree-based approach while maintaining the local flexibility found in the web of trust. Our analysis shows the hybrid mesh approach has the best chance of succeeding in the Internet.

Effectiveness of congestion avoidance: a measurement study

The authors describe the implementation of the binary feedback congestion avoidance (CA) policies and report measurements of the CA scheme in an OSI testbed at MITRE. The goal is to experiment with network configurations and traffic loads varied and complex enough to allow realistic performance evaluation of CA. These measurement experiments present evidence that the congestion avoidance policy operates effectively with a variety of traffic loads and configurations. The conditions used for the measurement experiments with CA include the coexistence of traffic participating in the CA scheme with intermittent traffic that does not participate in CA; and use of CA with realistic traffic such as bulk data file transfer type traffic and remote login traffic. These results show that there is a dramatic reduction in the mean and standard deviation of the response time as well as the number of retransmissions for all classes of traffic, even when some of the sources of traffic do not participate in the CA policy. The behavior of the CA policies with bidirectional traffic was also studied.<<ETX>>

NDNS: A DNS-Like Name Service for NDN

DNS provides a global-scale distributed lookup service to retrieve data of all types for a given name, be it IP addresses, service records, or cryptographic keys. This service has proven essential in todays operational Internet. Our experience with the design and development of Named Data Networking (NDN) suggests the need for a similar always-on lookup service. To fulfill this need we have designed the NDNS (NDN DNS) protocol, and learned several interesting lessons through the process. Although DNSs request-response operations seem closely resembling NDNs Interest-Data packet exchanges, they operate at different layers in the protocol stack. Comparing DNSs implementations over IP protocol stack with NDNSs implementation over NDN reveals several fundamental differences between applications designs for host-centric IP architecture and data-centric NDN architecture.

Design and evaluation of a protocol for automated hierarchical address assignment

One way to attack the problem of growing routing tables in networks is hierarchical addressing. When addresses are distributed manually by the network administrator, maintaining a good hierarchical address allocation can be difficult, especially if the domain is large. This paper presents a protocol to self-organize a routing domain with hierarchical addresses that are closely matched to the underlying network topology. Once the protocol assigns addresses, we examine the shortest-path routing tables for every router. Our studies indicate that 95% of the routing tables calculated are within one entry of optimal, where an optimal routing table is defined as one entry per next-hop router. In addition, these results are robust across networks of various sizes and in networks with various numbers of cycles. The protocols address allocation is efficient, with minimal waste of address space. Furthermore, our experiments indicate that the choice of which router initiates the protocol does not significantly affect the quality of the resulting routing tables nor the efficiency of the address allocation.