Hello, I am hereby posting a revised version of the *draft* minutes for the routing wg meeting at RIPE 49 last week. Many thanks go to the scribe, Henk Uijterwaal, of the RIPE NCC for a good and quick job. Comments are welcome, Joao Damas/(co)Chair routing-wg ISC Routing WG (Session 1) ====================== 1. Introduction/Joao Damas (16:00-16:03). ------------ Joao opens the meeting and deals with the administrative stuff. Henk Uijterwaal is appointed as scribe, the minutes from RIPE48 are approved, the agenda is approved. The group has no outstanding actions. Joao shows a slide with the dates of the upcoming IRR courses by the RIPE NCC. These dates will be published on the web shortly. 2. Securing a core network - discussion/Michael Behringer. (16:03-16:39) ------------------------------------ Slides on the web at: http://www.ripe.net/ripe/meetings/ripe-49/presentations/ripe49-routing- security-discussion.pdf Christian Panigl briefly summarised part 2 of Michael Behringer's talk from morning EOF session. In the morning, Michael Behringer presented some ideas to secure the core network, keeping operability in mind: - Transit ACL's - Use RFC1918 address space and no export (users cannot see the core and thus not attack it). - Use of a non IP-Control plane The chair then opened the floor for lively discussion: * Daniel Karrenberg: if you are protecting the core, make it transparent, the end user then sees it as 1 IP hop. The user should never see RFC1918 space. Also be consistent, that will save a lot of work. * Joao Damas: Wild idea: use a v6 block for your IX. * Randy Bush: What end user want is good service, does not want to run traceroute. End user needs to debug both paths. Opaque blob is not going to let anybody debug it. * Michael Behringer: This is an old discussion. Traceroute -g and source route were considered bad too, LG's solved the problem. While he agrees with Randy Bush' points, why not invent other tools? * Randy Bush: does not see benefit in using RFC1918 space to make core invisible. This hides the fact that it is an IP network, it is going to get you in trouble sooner or later. IP network should be open. * Daniel Karrenberg and Iljitsch van Beijnum agree with Randy Bush. * Pedro Marques states that you cannot prevent people from accessing your core routers without making things invisible. * Michael Behringer wants to see the discussion on an abstract level. * Pedro Marques: if you have daily DDoS attacks, filtering for network might be a good idea, not a choice, even if it breaks other things. Host-by-host protection does not work. * van Beijnum: hiding the core and making the core inaccessible aren't the same thing. The latter can be good. If you hide the core, debugging will be the same as debugging ethernet segments. Not funny. * Randy Bush DDoS problem of distributed source and target. Needs to be solved near the edge and source of DDoS. Refers to work by Bellovin et al on push-back * David Reader: try traceroute to 213.249.249.129. Lots of 1918 space, his customer cannot see the site, operator of 10/8 can. The core doesn't see the problem, their neighbours do. * Michael Behringer asked what if you get proper addresses back. Randy: now you know who to contact and what's wrong. * Pedro Marques: one can set-up things such that traceroute works, but ping doesn't. Michael concluded with: there are different views, no agreement on pros and cons. He plans to write this up and give the document away. People can then decide for themselves what to do. 3. IRR toolset handover/Shane Kerr (16:39-16:46) -------------------- Slides on the web at: http://www.ripe.net/ripe/meetings/ripe-49/presentations/ripe49-routing- irrtoolset-handover.pdf Shane explained that the RIPE NCC took over maintenance of the RAToolset from ISI in 2001. The current release contains fixes to all issues raised at RIPE49 and compiles under gcc 3.x.x. The maintenance of this toolset does not fit with the current software model at the RIPE NCC. The RIPE NCC has therefor agreed with ISC to move maintenance to them. The RIPE NCC has handed over the code and all documentation to ISC. The mailing list will be moved soon. Question from the floor: Randy Bush asks what licensing model will be used by ISC. Joao Damas responds that the current license is the BSD license and that will not be changed. 4. BGP Wedgies/Tim Griffin (16:39-17:07) ----------- Slides on the web at www.cambridge.intel-research.net/~tgriffin Tim introduced the concept of a BGP wedgie. A 3/4-wedgie is a situation where local routing policies make sense locally but interactions allow for multiple stable routes. A full wedgie is a situation where no set of operators can find out why a set of policies result in an unexpected route. Some examples were shown. Operators should be aware of this. An IETF draft (in the GROW-WG) is available. Comments: Geoff Huston: This would be easier if "depref me" was a transit property. Should it be? Tim: if we want this to work: yes. Pedro Marques: one way to fix it is to get eBGP to advertise best route and best route that does not come from peer I'm talking to. (2nd best route). This is in an old RFC. Juniper can support this. Tim: this makes it easier, but does not solve general case. Bill Norton: what tools do you have to figure out the current situation, what tools would be useful? Tim: needs common analysis by multiple AS, not a trivial thing to set up. Daniel Karrenberg: can this be avoided with pre-pending? Tim: no, folks prefer customers, it will not work. 5. Measurements on intra domain routing instability/Zhang Shu (17:07-17:24) ------------------------------------------------ Slides on the web at: http://www.ripe.net/ripe/meetings/ripe-49/presentations/ripe49-routing- instability-measurements.pdf Zhang showed statistics on intra domain routing changes in the WIDE network. Oscillations are often caused by: Congestion Link/IF failure Misconfiguration S/W bugs He then presented the RTANALY tool, a system to detect and visualise IGP changes. Release early October: http://rtanaly.koganei.wide.ad.jp/rtanaly An example was shown. Question from the floor: How do you get the data? Zhang: Record them with tcpdump. Routing WG/Session 2 ==================== 6. BGP network design/Pedro Marques (11:00-11:50) ------------------ Slides on the web at: http://www.ripe.net/ripe/meetings/ripe-49/presentations/ripe49-routing- bgp-design.pdf This presentation will focused on a set of frequently asked questions that network operators have regarding the logical design of BGP networks. These include topics such as route reflector placement on a network and BGP configuration trade-offs. More a set of topics to generate discussion based on discussion with potential customers. A. How much hierarchy Showed an example of a wrong design aimed at keeping traffic local. IBGP would have done the same. BGP for internal traffic is generally a bad idea, it was not designed for it. B. Where to place route reflectors? Goal: reduce routing information. Non-goals: configuration management, scaling #tcp sessions A lot of people use Route Reflectors as a configuration. management tool. Wrong tool for the job. Side effects of path selection are usually not understood. Should buy a provisioning system. Recommendations: - Keep it simple. Lowest cost solution that solves the problem - Avoid loosing information in the core - Avoid centralisation Cold potato: MED and what are the consequences. The speaker then ran out of time and briefly went through a number of slides: C. Can BGP advertise more than 1 path? Yes, you can. Showed config example in slides D. Unadvertised JunOS behaviour changes: 6.3 incoming interface check on eBGP session (drop packet from non peer) 7.0 TCP path MTU discovery no eBGP poison reverse to neighbour as Question from the floor; Rudiger Volk: objects against the statement that BGP can advertise more than 1 path. It doesn't. Prefix is the key. Pedro: 2547 augments the key to be a route discriminator plus prefix. So effectively it does for a number of applications. A discussion follows, no conclusion is reached and the discussion is taken off-line. Randy Bush showed a case where mixing routers from two different vendors led to huge numbers of message and slow convergence, introducing a min.router advert showed slower convergence, less messages though, not seen on data plane 7. Happy packets/Randy Bush (11:50-12:04) ------------- Slides on the web at: http://www.ripe.net/ripe/meetings/ripe-49/presentations/ripe49-routing- happy.pdf Randy noticed that there have been numerous publications about the control-plane (routing) instability. However, what matters is the quality and stability of the data plane: what counts is if the data reaches its destination. A huge number of BGP updates is not a problem as long as the routers can process them without falling over. He did an experiment with a BGP beacon and sites all over the world sending data to it. One plot showed the effect of an link cut while keeping an alternative path up. Packets continued to arrive from half the sources. The other half experienced a 30 second drop, even though BGP updates continued to float around in the system much longer. More examples were shown, bottom line was there is no correlation between BGP activity and data not arriving. On the IP level, some correlation can (arguably) be seen. 8. RIS status and plans/Matthew Williams (12:04-12:23) -------------------- Slides on the web at: http://www.ripe.net/ripe/meetings/ripe-49/presentations/ripe49-routing- ris.pdf Matthew gave an update of the RIS project at the RIPE NCC. Highlights are * The internal reorganisation announced at RIPE48 has been successfully completed. * A route collector is about to be installed in Moscow. RRC08 has been moved from MAE-WEST to the PAIX. * myASn v1.0 has been released. myASn is an alarm system for BGP available at http://www.ris.ripe.net/myasn.html. * The debogonising effort has been continued. For the new RIPE NCC block 85/8, it showed that initially 80% of the sites filtered the block, this was reduced to 17% after a few days. * Ongoing efforts: - IPv6 support. Some tools do support IPv6, others don't as the RIPE NCC ran out of time. New ETA is late November. Prototypes for unsupported tools are available at: http://www.ris.ripe.net/cgi-bin/ipv6/prefixquery.cgi - Looking at requirements for myASn v1.1 and 2.0. - Future IDR work - Secure routing - Collaborate with researchers - Your suggestion 9. Detecting anomalies/Olaf Maennel (12:23-12:37) ------------------- Slides not yet on the web. Olaf presented research aimed at finding the offending AS when an anomaly in BGP is detected. He uses 3 views: time, location and prefix. The method then detects the AS that is causing the problem (in about 93%) of the cases. The algorithm has been validated using simulations, RIS/Routeviews data (1100 feeds), formal methods. Olaf has also checked that the anomalies he detected are related to events seen in syslog files from real routes. Limitations of the method are the size of the candidate set. It is also possible that the offending AS is outside the set of processed AS's. Further work includes developing a Topology aware library to identify clusters and adding this algorithm to BGP alarm systems like myASn. Collaborators are Gert Doering and the RIPE NCC. 10. AOB? --- No other business.