This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/ripe-list@ripe.net/
Program for EOF @ RIPE-48
- Previous message (by thread): New IPv4 blocks allocated to RIPE NCC
- Next message (by thread): RIPE 48: Updated Agenda Available
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Daniel Karrenberg
daniel.karrenberg at ripe.net
Wed Apr 7 11:55:23 CEST 2004
** The EOF will start only after Lunch. ** There will be *no* morning sessions on Monday! Watch http://www.ripe.net/ripe/meetings/ripe-48/eof.html for possible updates. Monday, May 3rd 2004 1400 - 1530 Tutorial: Practical Strategies for IP Traffic Engineering and Enhancing Core network Availability Presenters: John Evans (Cisco), Arman Maghbouleh (Cariden) 1530 - 1600 C o f f e e 1600 - 1730 Tutorial Part 2 Tuesday, May 4th 2004 0900 - 1030 Applications of Bidirectional Forwarding Detection (BFD) Presenter: Rahul Aggarwal (Juniper) Nemecis: A tool to analyze the IRR registries Presenter: Georgos Siganos (UC Riverside) To be Announced NN 1030 - 1100 C o f f e e 1100 - 1230 Address Space Hijacking How Operators Can Protect Themselves & Their Customers Presenters: Leslie Nobile (ARIN), Leo Vegoda (RIPE NCC) Rob Thomas (Team Cymru/Cisco) (Tentative) ---- "Practical Strategies for IP Traffic Engineering and Enhancing Core network Availability" John Evans (Cisco) Arman Maghbouleh (Cariden) MPLS traffic engineering (TE) is often considered as synonymous with making more efficient use of network bandwidth and/or improving network availability via the capabilities of TE Fast Re-route (FRR). This session considers the theory behind traffic engineering in general, together with the benefits, limitations, and deployment considerations of MPLS TE in the context of IP traffic engineering and engineering core network availability. Consideration is also given to alternative technologies such as IGP metric based traffic engineering and IGP fast convergence, and to how quatitive decisions can be made on the relative benefits of the different approaches. http://www.cariden.com/apricot/TE_Beyond_MPLS_apricot_04.pdf ------ "Applications of Bidirectional Forwarding Detection (BFD)" Rahul Aggarwal (Juniper) This presentation describes various applications of BFD in service provider networks. BFD is emerging as a widely applicable forwarding detection tool. It can be used to reduce failure detection times, improve convergence and aid operations. Several service providers are looking at deploying it. BFD makes it possible to support SLAs of applications such as voice over IP, by allowing end to end sub-second failure detection. It is an ubiquitous OAM tool and can be used for IGP adjacencies, static IP routes, E-BGP peers, MPLS LSPs and IP/GRE tunnels. The talk will start with an overview of BFD to establish the context of the presentation. The application of BFD in the access network will be stressed as a means to achieve edge availability. Particularly BFD between a router and a host will be discussed as a means to fill the last mile failure detection void. Usage of BFD for IGP fast convergence will be described, where its particularly useful on ethernet links. The relevance of BFD for static IP routes and E-BGP peers will be described. This is relevant between a router and hosts eg. web servers and VoIP media gateways. BFD over ethernet will be introduced for fault detection between a router and a switch. BFD can also be used as an OAM tool on IP/GRE tunnels and for MPLS LSPs. The relevant mechanisms for this will be discussed. Voice over IP will be used as a case study to describe how BFD can be used to achieve end to end sub-second failure detection. - Bidirectional Forwarding Detection, D. Katz, D. Ward, draft-katz-ward-bfd-00.txt - BFD for MPLS LSPs: Rahul Aggarwal and Kireeti Kompella draft-raggarwa-mpls-bfd-00.txt - BFD for IPv4 and IPv6 (Single Hop), D. Katz, D. Ward, draft-katz-ward-bfd-v4v6-1hop-00.txt ----- "Nemecis: A tool to analyze the IRR registries" Georgos Siganos (University of California Riverside) In this talk, we will present a brief analysis on the IRR and the quality of information they contain. The IRR effort provides a voluntary detailed repository of BGP policy information that has not reached its full potential for three reasons: a) ISPs have limited incentives to maintain their policy, b) extracting useful information is far from trivial, and c) the accuracy of the data is uncertain. Using our tool Nemecis we try to address the last two issues. First, we can check the registered policies for correctness and then for freshness against BGP routing tables. We found that even though RIPE is the most accurate registry, only 34% (for June 22 2003) of the ASes pass all our tests. Our tool consists of two parts: first we have an easy to query relational database, where the policies are stored in tables and not as simple text. Second, we have a web based front end so that ISPs can easily check the result of our analysis. A demo of the tool exists at the following location: http://ira.cs.ucr.edu:8080/Nemecis http://www.nanog.org/mtg-0402/pdf/siganos.pdf http://www.cs.ucr.edu/~siganos/papers/Nemecis.pdf ----- "Address Space and AS Number Hijacking How Operators Can Protect Themselves & Their Customers " Leslie Nobile (ARIN) Leo Vegoda (RIPE NCC) Rob Thomas (Team Cymru/Cisco) (Tentative) 1. Definition and scope of the hijacking problem: Over the last year to 18 months we have seen the rise of address space hijacking. Addresses are re-registered from their legitimate users to third parties without proper authority. The networks are often used to send spam and host pornography. All four RIRs have "ask and ye shall receive" like policies. However, the groups hijacking address space rarely want to use them because their activities are unpopular. The address space they use is quickly placed on blacklists by network administrators. Consequently, the need a regular supply of fresh address space. 3. Historical perspective: An explanation of the "Cheers" legacy. The world has changed since the early days of the Internet. The networking community has grown and people no longer know everyone's name or nic-hdl. Instead, they rely on the registration information published in the RIR databases and various Routing Registries. However, one legacy of the early days is the 'bitty' security on many early registrations. 4. Examples of recent hijackings (in the RIPE NCC region) We might describe some tuypical examples from 2004. We can show the kind of modus operandi used by hijackers. 5. Actions taken by the RIRs to combat this problem We'll describe changes in ARIN and RIPE NCC procedures. We'll also describe new roles people can contact and registration hints they can watch for e.g. whois -ipn RR-RIPE Network operators need to be aware of recent changes in database security mechanisms, such as the deprecation of NONE in the APNIC and RIPE databases, the introduction of the more secure MD5-PW and the introduction of X.509 as an auth scheme for the RIPE database. They also need to know about the introduction of "Org" objects in the RIPE database and how these "Org" objects can be used when accepting new customers and their routes. 6. Actions that the operator community could take to protect themselves and their customers' registrations and networks A look at how the miscreants make use of the addresses and AS Numbers they hijack in the registry databases.
- Previous message (by thread): New IPv4 blocks allocated to RIPE NCC
- Next message (by thread): RIPE 48: Updated Agenda Available
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]