Sunday, February 12, 2006
Topic/Presenter |
---|
Full AbstractWelcome! If you're new to NANOG, or if you're an experienced attendee and just feel like hanging out, this orientation session and reception are for you. Join us to meet other newcomers as well as members of the NANOG Steering Committee, Program Committee, and List-admin team. We'll demystify the goings-on at NANOG, and also tell you a bit about the birth of the organization way back in the mists of time. We'll meet from 3:30-5:00 p.m. on Sunday, June 5. Light refreshments will be served—and be sure to join us immediately after the reception for the Community Meeting at 5:00 p.m. Speakers |
RecordingsFull AbstractSpeakers |
Full AbstractThis tutorial covers common problems ISPs have when deploying BGP within their network. It looks at problems with peer establishment, missing routes, inconsistent route selection, and convergence issues. It also looks at real-world examples of common errors which are made when deploying BGP, both as iBGP and eBGP, in service provider networks. Speakers |
Full AbstractThis tutorial covers topics ranging from daily DDOS mitigation to:
Speakers |
Monday, February 13, 2006
Topic/Presenter |
---|
Full AbstractSpeakers |
Full AbstractSpeakers |
Full AbstractWith the increased convergence of multi-services at the edge of the provider network, there is a greater need for effective bandwidth management and service differentiation essentially achieved through IP Quality of Service. In order to provide end-to-end scalable IP services, MPLS backbones are being used to achieve this. This has led to a wider deployment of MPLS-based backbones, enabling providers to have the capability to extend service differentiation using MPLS Diffserv techniques. This ability to provide traffic categorization along with traffic engineering and bandwidth management techniques, available through MPLS Traffic Engineering (TE) and Diffserv-Aware Traffic Engineering (DS-TE), allows the service provider an array of choices for end-to-end implementation of Quality of Service. The five key components of QoS include delay, jitter, latency, bandwidth and fairness. Any QoS deployment requires attention to these components. This would be achieved at the edge by initially classifying traffic streams appropriately, then metering them towards providing service-level guarantees and, if needed, marking the streams as per-policy definitions. Subsequently, for effective bandwidth management, congestion avoidance and management techniques need to be implemented for better utilization of the links and for improved distribution of the available resources.
Speakers |
RecordingsFull AbstractSpeakers |
Full AbstractIn response to reports of DNS cache poisoning early in 2005, we performed a number of surveys of authoritative DNS servers. Our survey looks for sources of DNS cache poisoning. We found about 170 potential sources of "poison." Based on what we can determine about the organizations related to and responsible for the poisoning, we try to infer whether they have malicious intentions or are being stupid and lazy. Speakers |
RecordingsFull AbstractCurrent major operating systems that support IPv6 send AAAA queries for any name resolution prior to resolving A records, which doubles the number of queries and increases user response time. Because Windows Vista, which will be released in 2006, enables IPv6 by default, operators of DNS cache servers should prepare for this increase. In addition, many OSes may send multiple queries for single name resolution when the record is not found, by completing local domain names. While the completion is useful, it increases the load of DNS cache servers. We show how the combination of AAAA query and domain name completion increases the number of queries. We will also discuss the effects of this increase on cache server operation and user response time, and explain how to decrease the needless queries. Speakers Tsuyoshi Toyono, NTT Labs |
RecordingsFull AbstractThe domain name system, without which most Internet applications don't work, depends on reliable access to DNS information. Failure scenarios therefore exist where two Internet hosts may have connectivity to each other, but can't communicate because they lack a path to a DNS server in another location. A talk at last year's APRICOT touched on this problem in the general case. This talk will look at the DNS in greater detail, and how the placement of DNS servers for various top level domains affects their reliability in different parts of the world. Speakers |
|
Full AbstractDiscussion of IPv6 seems to be increasing in industry forums and publications. The US Federal Government has recently thrown its weight behind an IPv4-to-IPv6 transition. Some claim that our reserves of IPv4 address space are dwindling rapidly. Is it time to roll out IPv6 in service provider networks and start offering services to consumers and enterprises? Is there really a demand? Is this just OSI networking all over again, or is there something more substantial here? IPv6 supporters from the IPv6 Business Council come together with IPv6 skeptics from Service Providers to clear the air on what may be an unneeded and massively disruptive transition or an amazingly enabling technological evolution—or both. Speakers Panelist - Wes George, Sprint Panelist - Jared Mauch, NTT America. Fred Wettling, Bechtel |
|
Full AbstractInitially, Virtual Private Networks were built using leased lines. Service providers were offering VPNs based on point-to-point data link layer connectivity, using ATM or Frame Relay virtual circuits. Customers built their own Layer 3 networks to accommodate IP traffic. As a result, separate networks exist for Layer 2 and Layer 3 traffic, but maintaining separate networks for Layer 2 VPNs, Layer 3 VPNs and Internet traffic is difficult and very costly.
Speakers Muhammad Waris Sagheer, Cisco Systems |
Full AbstractI have been working with the Peering Coordinator Community to identify emerging peering and ISP cooperation issues that should be aired and discussed for the good of the community. Here is a draft list of issues the community has volunteered so far: Paid Peering as an Adjunct to Settlement Free Interconnect (15 min). As a perennial topic over the last ten years or so, the topic of settlement-based peering has come up as a solution for peering partners who do not meet the Settlement Free Interconnect (SFI) requirements. This paid peering approach, however, has not been widely adopted for a variety of reasons that we would like to discuss and understand. Speaker: TBD AS7018 & AS7132 Discussion (15 min). With the merger of two of the largest peering companies in the U.S. Peering Ecosystem there are questions in the Peering Community about the near and medium term impacts. The speaker (TBD) will share insights into the migration and schedule for integration, along with any peering changes that might ensue. Emerging Content Provider Peering Approach (15 min). Two competing forces are driving the peering debate at content companies: 1) lower transit prices and the ability to leverage marquee brand names make it difficult for content companies to justify the business case for peering, and 2) at the same time, the next generation content (video streaming, IPTV, IP for populating caches with 40G video files, etc.) is expected to increase the value of peering by at least a factor of 10. The more traffic that a content company can peer, the greater the benefits of peering to the entire peering community. Greater control over the end-user experience is a powerful motivation for the content company but needs to be balanced with the cost and overhead of running a backbone, managing spikes and transit commits. A leading content company will share its experience, its business motivations for peering, and provide lessons learned for other content companies looking to peering to distribute their content. Speaker: TBD Peering Contact Database (peeringdb.com) Update (10 min). This shared database provides contact info for the community, so we'll have a brief statistical update on the usage and some words to encourage continued population of community information into the DB. Speaker: TBD The Great Peering Debate (30 min). "The Utility of MEDs" will be the title of the Great Peering Debate. "From a Practical Perspective, are MEDs useful for distributing the peering traffic load?" is the question; "MEDs are not a useful tool for Peering" will be defended by Richard Steenbergen; and "MEDs are a useful tool for Peering" will be defended by Patrick Gilmore. The Peering Contact Debate will be presented by the peeringDB Admin Team. Other Topics. We expect that between now and February there will be a variety of emerging issues so we will use the flexibility of the BOF format to include late breaking topics of interest to the community. Speakers |
Tuesday, February 14, 2006
Topic/Presenter |
---|
Full AbstractSpeakers |
Full AbstractSpeakers |
Full AbstractArbinet |
Full AbstractIRR Power Tools is a useful new utility developed by the author for ISPs. Its capabilities include:
Speakers |
Full AbstractIn this presentation we describe a set of visualization techniques that can help the task of operating and managing a network by representing network traffic information in a concise and intuitive manner. Our client/server tool is called Flamingo. The Flamingo server is responsible for receiving raw NetFlow feeds from devices in the network that can sample traffic, and then sending processed information to the client for display. The Flamingo client receives data from the server and provides concise intuitive data visualizations, 3D space navigation, as well as filtering capabilities that can help the operator to extract or monitor specific information of interest. We illustrate, with the help of simple examples, how Flamingo can be used to perform network monitoring tasks as well as network security-related data forensics. Speakers |
Full AbstractWe present two NetFlows visualization tools, (1) NVisionIP and (2) VisFlowConnect-IP. Both of these tools have been developed based on system administrator requirements, their design peer-reviewed in security research forums, and usability testing is in process. These tools both present large volume complex data transparently to system administrators in simple intuitive visual interfaces that support human cognitive processes. NVisionIP visually represents the state of all IP addresses on large networks on a single screen window (we use a Class B address space as the default) with capabilities to filter and drill down to subnets and individual machines for details-on-demand. VisFlowConnect-IP visually represents flows between internal network IP hosts and the Internet, showing who is connecting with whom, with capabilities to filter and drill down to subnets and individual machines for details-on-demand. NVisionIP and VisFlowConnect-IP can be used individually or in unison for correlating events. This work is distinguished from others in that these are the first Internet security visualization tools to be freely available on the Internet and deployed in large production environments. Speakers |
Full AbstractPersistent forwarding loops can be exploited by flooding attacks in the Internet. This happens because persistent forwarding loops may share one or more links with forwarding paths to reachable addresses. An attacker can exploit persistent forwarding loops to overload the shared links to disrupt Internet connectivity to those reachable addresses. To understand the extent of this vulnerability, we perform extensive measurements to systematically study persistent forwarding loops and the number of network addresses that can be affected. We find that persistent forwarding loops do exist in the current Internet. About 2.47% of routable addresses experience persistent forwarding loops and 0.78% of routable addresses can be attacked by exploiting persistent forwarding loops. In addition, 81.8% of the persistent forwarding loops appear within destination domains and they can be observed from various locations, which makes it possible to launch attacks from many vantage points. We also find that most persistent forwarding loops are just two hops long, which enables an attacker to amplify traffic to persistent forwarding loops significantly. The possible causes of persistent forwarding loops could be misconfiguration of the common usages of default routes and static routes. In this talk, we show an example in whcih a network administrator neglects to configure a "pull-up route" at a border router to his/her upstream provider, which leads to persistent forwarding loop. The complete paper is available at http://rio.ecs.umass.edu/mnilpub/papers/jxia-imc05.pdf">http://rio.ecs.umass.edu/mnilpub/papers/jxia-imc05.pdf Speakers |
Full AbstractWe have monitored BGP announcements for one particular month, and then tried to automatically extract hijacking information. By the date of NANOG 36, we hope to have the whole process automated and to have completed a study spanning many months instead of just one. We'd also like feedback as to whether a biweekly hijacking report would be useful to the community at large. Speakers |
Full AbstractOpenBGPD is a new, multi-feature BGP-implentation that runs on OpenBSD. A novel approach to implementing BGP, the code is being mostly developed by Henning Brauer of the OpenBGPD/OpenBSD-Team. One aspect of the presentation will be the implementation of OpenBGPD as a route-server at the DE-CIX, a project currently in development. Speakers |
Full AbstractSpeakers |
Wednesday, February 15, 2006
Topic/Presenter |
---|
|
RecordingsFull AbstractIPv6 is now available for major types of equipment, OSes, and applications, and is also deployed in major ISP backbones. However, there are a small number of erroneous implementations that do not work in IPv4/IPv6 dual-stack environments. When an IPv6 user encounters a problem, a frustrated user often hastily concludes that the problem lies with IPv6. We are concerned that such situations could lead to agitation among IPv6 users. The IPv6-fix project aims to identify and document issues and pitfalls in IPv6 deployment. Such problems are often found at boundaries of specifications, implementations, and operation. The project covers a wide range of real-world topics, including on-link assumptions, DNS servers and resolvers, TCP connection establishment, quality of the IPv6 Internet, and firewalls. In this talk, we will describe IPv6-fix activities, illustrate issues by examples, and introduce our tools and measurement results. Speakers Ruri Hiromi, WIDE Project/Intec NetCore |
Full AbstractHurricane Katrina wreaked havoc on a three-state telecommunications infrastructure, leaving 3 million users without dial tone and taking thirty eight 9-1-1 Centers out of operation as well as 1,000 cell phone towers in the most widespread natural disaster to hit the U.S. This session focuses on the crisis management and emergency preparedness for the city of New Orleans in case study format, details the telecom infrastructure impacts/outages, and highlights how telecom operators such as ISPs, landline, wireless, and cable all teamed up to aggressively and creatively restore service to mission critical telecom infrastructure. Specific examples in retail, healthcare, and an ISP will be highlighted. The presentation will provide insight into how the public Internet successfully served first responders such as the Police and Fire Departments as well as businesses and residents. The Internet provided the lifeline for tracking relatives, locating dispersed employees, submitting emergency claims to FEMA, and publicizing much-needed weather and recovery details with 100 broadcast stations initially off the air. Recent actions and proposals by the FCC and Department of Homeland Security will be shared. An assessment and vendor-neutral recommendation will be provided along with resources and references. Speakers |
RecordingsFull AbstractSpeakers |
|
Full AbstractWe propose an isolation layer—a shim—between inter-domain routing and packet forwarding. The job of this layer is to coordinate between Autonomous Systems on when and how to modify the forwarding state as to ensure inter-domain routing loops do not cause forwarding loops. The benefits of a consistency layer are two-fold. First, it prevents the creation of transient inter-domain forwarding loops and the resulting packet loss, high latency, and connection failures. Second, by taking the burden of forwarding consistency off the inter-domain routing protocol, it enables inter-domain routing protocols with more complex convergence characteristics than BGP, such as protocols that optimize route selection based on performance. We show that inter-domain routing loops cause real performance problems, and we offer two possible designs for the consistency layer. We prove that both designs are free of forwarding loops and show they are easy to deploy in the current Internet. Speakers |
RecordingsFull AbstractSpeakers |
RecordingsFull AbstractSpeakers |
Full AbstractSpeakers |
RecordingsFull AbstractSpeakers |
RecordingsFull AbstractSpeakers |
Full AbstractSpeakers |
Full AbstractSpeakers |
RecordingsFull AbstractSpeakers |