Saturday, February 8, 2003
Topic/Presenter |
---|
Full AbstractThis tutorial will give participants a structured approach to tracking down and fixing interdomain multicast problems. The talk will break the troubleshooting process down into four main stages:
This is an intermediate-to-advanced talk; participants should have a basic knowledge of the protocols (IGMP, PIM, MBGP, MSDP) and terminology (RP, DR, (S,G), (*,G), RPF, SPT, etc.) and be supporting multicast in their network. Participation in previous NANOG tutorials "Introduction to IP Multicast Practice" (May 2001) or "Deploying IP Multicast (Feb 2002)" would also be helpful. Speakers |
Full AbstractThis tutorial introduces service providers to some advanced BGP features and techniques to aid with operating their networks within the Internet. After a brief recap of iBGP, eBGP, and common attributes, the tutorial will look at the various scaling techniques available, when to use BGP instead of an IGP, and examine policy options available through the use of local preference, MED, and communities. The tutorial will finish by briefly covering some basic multihoming techniques. Speakers |
Sunday, February 9, 2003
Topic/Presenter |
---|
Full AbstractSpeakers |
Full AbstractThis tutorial introduces network engineers and service providers to advanced BGP features and techniques available within the JUNOS software to assist them in operating their networks. We will examine common configuration errors on a Juniper router - how to spot them and resolve them. The tutorial will then look at how to originate and filter routes using the JUNOS software policy language. The process of selecting the best BGP route is discussed, as well as methods available to modify the various BGP attributes. Examples of command syntax, router output, and troubleshooting aids using a Juniper router are provided throughout the tutorial. Speakers |
|
Full AbstractAs a follow-up to the NANOG26 IPv6 tutorial, this session will describe some of the common network environments and their requirements for a deployment of IPv6. We will then go into detail about the transition tools appropriate for use in each of those environments. Speakers |
Full AbstractThis talk examines current peering trends, from a brief review of peering history to changes in the ways that networks will interconnect in the future. Topics to be covered include:
Speakers |
Full AbstractSpeakers |
RecordingsFull AbstractTwo years ago, the European IXPs decided there could be further co-operation between their organisations, beyond that achievable through the RIPE EIX-WG and many existing close collaborations. As a result, Euro-IX was formed to provide an operating umbrella for shared projects and representation for its member organisations, plus a portal for potential IXP clients to help them with their expansion into the peering world. Speakers |
Full AbstractService providers often analyze the utilization statistics available from SNMP-enabled devices to make informed engineering decisions, diagnose faults, and perform billing. Despite being "simple," collecting and efficiently storing large amounts of time-series data quickly, without impacting network or device performance, is challenging in very large network installations. This talk identifies several key areas of a service provider SNMP statistical solution and introduces a new tool, RTG, that addresses these issues. RTG is designed to serve as a foundation for a variety of services, including billing, capacity planning, monitoring and customer portals. We present the architecture, compare it with other freely available solutions, and show graphs and reports unique to RTG. Speakers |
Full AbstractRecent research publications have noted the possibility that plain-old IGP metric manipulations may be as effective as the overlay-style traffic engineering made possible by ATM or MPLS. Adherents of either approach have pointed to specific topologies for which metric manipulation does extremely well or extremely poorly. Here, we present the results of a study comparing metric-based shortest-path routing with the theoretically optimal routing. We looked at six real networks under normal and single-circuit failures and found that, despite its limitations, metric-based routing was able to minimize maximum link utilizations about as well as the theoretical maximum. We present cases that illustrate the limitations of metric-based routing and speculate that these cases do not affect performance on existing networks because operators design networks with shortest-path routing limitations in mind. Speakers |
Monday, February 10, 2003
Topic/Presenter |
---|
Full AbstractBGP is vulnerable to both accidental failures and malicious attacks. We propose a new protocol that works in concert with BGP, which ASs will use to help detect and mitigate accidentally or maliciously introduced faulty routing information. The protocol differs from previous efforts at securing BGP in that it is receiver-driven, meaning that there is a mechanism for recipients of BGP UPDATE messages to corroborate the information they receive and to provide feedback. We argue that our new protocol can be adopted incrementally, and we show that there is incentive for network operators to do so. We also describe our prototype implementation. Speakers |
Research Forum: Achieving Near-Optimal Traffic Engineering Solutions for Current OSPF/IS-IS NetworksRecordingsFull AbstractTraffic engineering is aimed at distributing traffic so as to "optimize" a given performance criterion. The ability to carry out such an optimal distribution depends on the routing protocol and the forwarding mechanisms in use in the network. In IP networks running the OSPF or IS-IS protocols, routing is along shortest paths, and forwarding mechanisms are constrained to distributing traffic uniformly over equal cost shortest paths. These constraints often make achieving an optimal distribution of traffic impossible. In this talk, we seek operational feedback on an approach that is capable of realizing near optimal traffic distribution without any change to existing routing protocols and forwarding mechanisms. We also explore the trade-off that exists between performance and the overhead associated with the additional configuration steps that our solution requires. The presentations's contributions are in formulating and evaluating an approach to traffic engineering for existing IP networks that achieves performance levels comparable to that offered when deploying other forwarding technologies such as MPLS. Speakers Roch Guerin, University of Pennsylvania Ashwin Sridharan, University of Pennsylvania |
|
Full AbstractSecurity incidents are a daily event for Internet Service Providers. Attacks on an ISP's customers, attacks from an ISP's customer, and attacks on the ISP's infrastructure are now one of many "security" NOC tickets through out the day. This increase in the volume and intensity of attacks has forced ISP's to spend constrained resources to mitigate the effects of these attacks on their operations and services. This investment has helped minimize the effects of the attacks, but it has not helped stop them at the source. Stopping attacks at their source requires rapid and effective inter-ISP cooperation. The spirit of inter-ISP cooperation exists in the ISP Security ranks, but the problem is that ISP Security Teams from one ISP cannot find their colleagues amongst their peers. This second ISP Security BOF models itself on the NANOG Peering BOFs, focusing on building the human Internet of ISP Security Engineers. We solicit ISP Security/NOC Teams (before the meeting), asking them to characterize their security tools and policies in general ways ("always help customers under attack" or "will trace the attack to the source" or "will work with law enforcement" or "black hole violators" or "implement common tools" etc.). From the answers, we will select a set of ISP Security Engineers to present a 5-to-10-minute description of their network, security tools, policies, how they would like to interact with other ISP Security Teams, and the identification/mitigation problems ISPs have had with existing technology/techniques. This presentation puts a face with the e-mail address at the ISP's Security/NOC Team. At the end of the BOF, representatives will have time to speak with ISP Security Engineers at ISPs with which they seek to deepen their interaction and cooperation. The expectation is that these interactions will lead to an effective, Internet-wide security incidence response --- plugging the attacks at their source and perhaps apprehending the perpetrators (using law enforcement to put a dent in the problem). Speakers |
RecordingsFull AbstractSpeakers |
RecordingsFull AbstractWe have completed our preliminary analysis of the spread of the Sapphire/Slammer SQL worm. This worm required rougly 5 minutes to spread worldwide, making it by far the fastest worm to date. In the early stages the worm doubled in size every 8.5 seconds. At its peak, achieved approximately 3 minutes after it was released, Sapphire scanned the net at over 55 million IP addresses per second. It infected at least 75,000 victims and probably considerably more. This remarkable speed, nearly two orders of magnitude faster than Code Red, was the result of a bandwidth-limited scanner. Since Sapphire didn't need to wait for responses, each copy could scan at the maximum rate that the processor and network bandwidth could support. There were also two noteworthy bugs in the pseudo-random number generator which complicated our analysis and limited our ability to estimate the total infection but did not slow the spread of the worm. Speakers |
Full AbstractAt the beginning of 2002, Allegiance Telecom acquired the AS2548 backbone from WorldCom. AS2548, once Digex, then Intermedia Business Internet, was at that time a nationwide OC-48 backbone running Cisco hardware. Simultaniously, Allegiance had built a brand new OC-48 nationwide backbone of their own to replace their aging DS3 IP network (AS11466.) The new network, with a Juniper core, was built independently of the old backbone, which was running a mix of vendors, but, like AS2548, was predominantly Cisco. Historically, acquired networks have been left alone in large mergers such as this one, because merging networks is difficult. But maintaining two separate Autonomous Systems would double the maintenance workload and split the product set in two. Thus, Allegiance was faced with combining three networks, two with active traffic, into one. To make matters more complicated, it was decided that the existing policy on either network was not sufficient for the new, combined network. So a new routing policy, capable of supporting all the existing customers on the old networks, would need to be implemented as part of the merger. Careful planning was the main requirement for success. With over 500 routers to modify, there was very little space for error. Configurations were tested in the lab, a script was written to translate from old configurations to new ones, test runs were made, and plans were probed for holes. The network was divided between 8 techs over two nights, one for AS2548, one for AS11466. On each night, the new policy would be pushed out, and the logical connections to the Juniper core activated. While AS2548 had more routers, AS11466 was actually undergoing an ASN change, and the difference in policy was greater, so the work load was relatively even. Back-out points were defined, and staff assigned to clean up issues as they arose. Still, there were problems, mainly because of the scale of the new, combined network. A lot of tough lessons were learned, but in the end the merger was a success. Speakers Dave Israel, Allegiance Telecom |
Full AbstractNow more than ever, Internet Service Providers are focusing on ways to increase the resiliency of their networks and, if at all possible, reduce their operating costs at the same time. Past research (Internet Service Providers and Peering, presented at NANOG 19, and A Business Case for Peering) demonstrates the economic tradeoffs of peering and highlight the simple but challenging first step: How to know who to talk with at an ISP to get peering set up This Peering BOF focuses on this first step using "Peering Personals." We solicit Peering Coordinators (before the meeting), asking them to characterize their networks and peering policies in general ways ("content heavy" or "access (eyeball) -heavy," "Multiple Points Required" or "Will Peer anywhere," "Peering with Content OK," etc.). From the answers we will select a set of ISP Peering Coordinators to present a 2-3 minute description of their network, what they look for in a peer, etc., allowing the audience to put a face with the name of the ISP. At the end of the Peering BOF, Peering Coordinators will have time to speak with Peering Coordinators of ISPs they seek to interconnect with. The expectation is that these interactions will lead to the Peering Negotiations stage, the first step towards a more fully meshed and therefore resilient Internet. Speakers |
Full AbstractMany network operators and researchers have been concerned about the alarming rates of BGP updates and their potential to destabilize the Internet routing infrastructure. Within a single AS, BGP updates may trigger routing reconvergence resulting in packet delay variations or losses. In addition, a high volume of BGP updates may cause shifts in traffic patterns across a network backbone when the next-hop BGP attribute changes. Such shifts are undesirable for two reasons. First, a flow that shifts back and forth between different paths may experience delay fluctuations, and multimedia applications such as Voice-over-IP may be adversely affected. Secondly, if such shifts occur frequently for flows that carry large volumes of traffic, the traffic patterns within the network may become volatile and unpredictable, making it difficult to perform capacity planning or traffic engineering. In this talk, we will present a quantitative evaluation of how BGP dynamics affect intra-domain traffic patterns within the Sprint IP backbone. We have captured packet header traces from several ingress links within the Sprint network. We then obtained the traffic fan-out from each ingress link by determining the egress PoP out of the Sprint network for the destinations of these packet flows. Finally, we correlated the packet flows with BGP updates collected at several routers within Sprint and analyzed the impact of BGP dynamics on intra-domain traffic. Our results show that that there is continuous BGP "noise" (100-20 updates/minute) interspersed with periods of high activity (5000 updates/minute). Despite this continuous activity, BGP routing updates mostly cause less than 1% of traffic to shift between egress PoPs. In a few cases, we observed that the shift was several percent, but it affected a very small number of multihomed destination prefixes. This limited impact of BGP updates on data traffic is mainly due to the relative stability of BGP prefixes that carry the majority of traffic -- we found that as little as 6% of the updates affect BGP prefixes that carry 80% of this ingress traffic. Recent results from other tier-1 ISPs have also shown that BGP prefixes that carry the majority of traffic are stable. This implies that traffic engineering and capacity planning within the Sprint network can be performed without serious concerns about the impact of BGP updates received from the rest of the Internet. Speakers Supratik Bhattacharyya, Sprint Chen-Nee Chuah, Sprint Christophe Diot, Sprint |
RecordingsFull AbstractConfiguration, operation, reliability, scalability and security problems with BGP have all grown as the Internet has grown. Based on detailed analysis of EBGP data from RIPE RIS and IBGP data from collaborations with several tier one ISPs, we believe that many of the most serious problems with BGP are not in the BGP protocol but are instead due to BGP's use of point-to-point TCP connections for its transport. Transport problems are much easier to fix than protocol problems since a new, parallel transport stack can be added to existing BGP implementations in an incrementally deployable, evolutionary fashion without having any impact on configuration or route selection behavior. Using the insights gained from our IGP and BGP measurement studies (reported at NANOG and elsewhere) and our experience developing different styles of transport protocols (such as SRM and ALF) we set about designing and implementing a new BGP transport. We call the result BST (BGP Scalable Transport). We will describe the implementation and discuss the issues underlying the most significant aspects of the design. We will show how it solves many of the existing problems with BGP and how, with a few small additions, it can form the basis of new BGP implementations that are extremely easy to configure yet highly reliable, scalable and secure. Speakers |
|
Full AbstractRecent years have seen large-scale (though generally single-network) outages caused by misconfiguration, such as route redistribution, and/or software bugs. There is also concern that "properly" architected worm/virus attacks could create networks of hundreds of thousands or millions of devices that could be turned against the router infrastructure. We will review some vulnerabilties that have been exposed in recent years, primarily relating to router CPU protection; route redistribution; router control/logging systems; the DNS infrastrucutre; and the robustness of interconnection between networks. The presentation will review some common-knowledge fixes, and will discuss some interesting applications of network architecture and design that can help to mitigate serious vulnerabilities. Speakers |
Full AbstractJust as fine grained peering helps keep local traffic local, so it is that massive scale anycast can help keep local attacks local. F-root is going worldwide, which means you'll be able to peer with ISC (the Internet Software Consortium) in a lot of new and even exotic places, but in most such places you'll only hear one route from us. In this presentation, Suzanne Woolf of ISC will explain what we're doing, why we're doing it, and what you can do about it. Speakers |
Full AbstractSpeakers |
Full AbstractBased on experience at iptel.org, we review current issues related to operation of SIP services on the public Internet. The issues include operational challenges such as NAT traversal, service reliability, scalability, and deployability. We show current practices and identify gaps that still need to be addressed by manafacturers.
Speakers |
RecordingsFull AbstractThere's been quite a bit of change in the 802.17 RPR standard proposal over the past couple of years. This discussion will provide a status update on where the 802.17 standard is, as well as an update on some of the differences between the 802.17 standard and SRP/DPT. A possible timeline for RPR product rollout based on a current view of the 802.17 standards progress will also be discussed. Speakers |
RecordingsFull AbstractSpeakers |
Tuesday, February 11, 2003
Topic/Presenter |
---|
|
RecordingsFull AbstractThe University of Tennessee at Knoxville was an early adopter of massive WLAN deployment. From January 2000 to July 2001, 1200 access points were installed across 15 million square feet, making this the largest 802.11b deployment in academia ... in the shortest time. All academic and administrative buildings are covered. The installation involved local contractors for handwork, and University expertise for network and wireless engineering. The design included 100% usage of power-over-ethernet, with the vendor selection carefully studied in order to support upcoming standards such as 802.11A and 802.11G. The original plan included RADIUS authentication and encryption, but lack of compatibility (support of Linux and PDA mostly) made us change the firmware on all 1200 devices ... completely scripted with SNMP! We now run a semi-open WLAN, with DHCP registration authenticated on LDAP and silent monitoring of MAC addresses in the background. Many new challenges have been encountered, and will be described further at NANOG. Speakers |
RecordingsFull AbstractA high density wireless deployment presents unique infrastructure logistics and monitoring problems. To support 500-2000 wireless users in a single room or space requires a combination of different approaches to ensure a functional network. This presentation draws on my experience in support of wireless deployment for IETF and NANOG meetings. Speakers |
RecordingsFull AbstractThis talk presents an up to date, comprehensive summary of all IPv4, IPv6, and Autonomous System Number statistics from the four Regional Internet Registries: http://www.arin.net">ARIN, http://www.ripe.net">RIPE, http://www.apnic.net">APNIC, and http://www.lacnic.net">LACNIC. Speakers |
Full AbstractIs the growth of the global Internet route table all about growth? Or is there a certain amount of laziness, cluelessness, and insensitivity factored into the growth? Over the past two years we've used e-mail and the top 20 CIDR list (now at http://www.cidr-report.org">http://www.cidr-report.org) to contact ISPs and multihomed enterprises. This volunteer effort draws attention to the impact their announcements are having on the global Internet table. We endeavor to make a difference by pointing out the problem, highlighting available resources, and offering free technical BGP assistance. In addition, over the past year we have encountered many RFC1918 and RFC1930 (private ASN) announcements leaking into the global routing tables. Speakers |
|
Full AbstractIP addresses are allocated to ISPs by four Regional Internet Registries (RIRs); in turn, the ISPs further assign addresses to end users. To understand the relationship, if any, between address allocation and global routing table growth, we present a quantitative analysis of the IPv4 address allocation and the growth of the global BGP routing table over the last four-and-one-half years. Our findings show that:
Speakers |
RecordingsFull AbstractIn recent weeks and months, we have been seeing a large number of DoS attacks directed against port 179 (BGP). These attacks are enabled in part by the facts that (i). the TCP 4 tuple is easy to discover, and (ii). the attack doesn't require knowledge of the TCP sequence number. As a result, you don't have to directly compromise ("own") the attacked router to disable BGP processing. The BGP TTL Security Hack (BTSH) is designed to protect the BGP (RFC1771) infrastructure from CPU-utilization based attacks. While BTSH is most effective in protecting directly connected BGP peers, it can also provide a lower level of protection to multi-hop sessions. Draft authors: Vijay Gill, John Heasly, and Dave Meyer Speakers |
Full AbstractThis talk details certain hardware features that are important for the hardening of routers and other network infrastructure. These features are hard to retrofit after the fact. Any changes at this level will involve software rewrites and may require board level changes; therefore the earlier these requirements are communicated to vendors, the better. Speakers |