The one-day event covered routing security topics including:
- A morning session on the Routing Registry and RIPE Database.
- After lunch, sessions on the Routing Policy Specification Language (RPSL) and exercises to describe routing policies.
- An afternoon session covered more advanced RPSL topics like route sets, MEDs, and AS path prepending.
Peer-A (AS1) establishes multi-lateral peering with other peers through a route server at an IXP. Peer-A wishes to selectively announce its prefixes to only AS2 and AS3. It tags BGP communities and large communities to achieve this. Large communities are needed to support selective announcements involving 4-byte ASNs. The document describes how large communities are encoded and provides examples of using them at an IXP to control route distribution and path attributes. Operational considerations for supporting large communities are also discussed.
APNIC Training Delivery Manager presents an analysis on Thailand's RPKI status at ThaiNOG Day 2021, held with the BKNIX Peering Forum 2021 from 13 to 14 May 2021.
This document provides an overview and agenda for deploying MPLS traffic engineering. It discusses:
- The motivation for traffic engineering to increase bandwidth efficiency and ensure appropriate paths
- How MPLS traffic engineering uses CSPF to calculate paths based on constraints and tunnels traffic along engineered paths
- The components of traffic engineering including distributing link information, path calculation and setup using RSVP, trunk admission control, and forwarding traffic onto tunnels
- The document discusses the transition from 16-bit autonomous system numbers (ASNs) to 32-bit ASNs. The pool of 16-bit ASNs is nearing exhaustion and will be replaced by 32-bit ASNs.
- 32-bit ASNs are represented in BGP in a backward compatible way using new BGP attributes. 16-bit BGP speakers will see 32-bit ASNs represented using AS23456, while 32-bit speakers will see the actual 32-bit ASNs.
- Regional Internet Registries have policies in place for the transition. By 2010, all new ASN assignments will be made from the 32-bit pool even if a network only supports 16-bit AS
Peer-A (AS1) establishes multi-lateral peering with other peers through a route server at an IXP. Peer-A wishes to selectively announce its prefixes to only AS2 and AS3. It tags BGP communities and large communities to achieve this. Large communities are needed to support selective announcements involving 4-byte ASNs. The document describes how large communities are encoded and provides examples of using them at an IXP to control route distribution and path attributes. Operational considerations for supporting large communities are also discussed.
APNIC Training Delivery Manager presents an analysis on Thailand's RPKI status at ThaiNOG Day 2021, held with the BKNIX Peering Forum 2021 from 13 to 14 May 2021.
This document provides an overview and agenda for deploying MPLS traffic engineering. It discusses:
- The motivation for traffic engineering to increase bandwidth efficiency and ensure appropriate paths
- How MPLS traffic engineering uses CSPF to calculate paths based on constraints and tunnels traffic along engineered paths
- The components of traffic engineering including distributing link information, path calculation and setup using RSVP, trunk admission control, and forwarding traffic onto tunnels
- The document discusses the transition from 16-bit autonomous system numbers (ASNs) to 32-bit ASNs. The pool of 16-bit ASNs is nearing exhaustion and will be replaced by 32-bit ASNs.
- 32-bit ASNs are represented in BGP in a backward compatible way using new BGP attributes. 16-bit BGP speakers will see 32-bit ASNs represented using AS23456, while 32-bit speakers will see the actual 32-bit ASNs.
- Regional Internet Registries have policies in place for the transition. By 2010, all new ASN assignments will be made from the 32-bit pool even if a network only supports 16-bit AS
Segment Routing (SR) is a tunneling and traffic engineering technology that allows routers to steer traffic along an SR path that may differ from the normal shortest path. An SR path is divided into segments that connect points within the SR domain. Segments are represented by Segment Identifiers (SIDs) that can identify single hops or multiple hops. The SR header or MPLS label stack enumerates the segments in the path to forward packets. SR supports various segment types including adjacency, prefix, anycast, and binding segments. SR provides traffic engineering capabilities and flexibility in path selection within the domain.
- R1 tracks its OSPF metric to R3's loopback interface using a track object, which adjusts R1's HSRP priority when the metric exceeds thresholds.
- When R1's link to R3 fails, the track object detects the increased OSPF metric and lowers R1's HSRP priority, making R2 the active router.
- R2 also tracks its OSPF metric to R4's loopback, dividing the metric to fit the 1-255 threshold range. This allows R1 to regain active status if its path to R4 improves.
The document provides an overview of IPv6 addressing and subnetting. It discusses IPv6 address representation and structure, including that addresses are 128 bits long and represented in hexadecimal. The addressing hierarchy from ISP to customer site to individual devices is covered. Different address types like link-local and global unicast are defined. IPv6 autoconfiguration and how devices generate interface IDs are summarized. The document concludes with an example of how to subnet a provider's IPv6 block and allocate /48 prefixes to multiple customers.
Internet Protocol version 6 (IPv6) is the most recent version of the Internet Protocol (IP), the communications protocol that provides an identification and location system for computers on networks and routes traffic across the Internet. IPv6 was developed by the Internet Engineering Task Force (IETF) to deal with the long-anticipated problem of IPv4 address exhaustion. IPv6 is intended to replace IPv4. Watch more: http://telecomacadmey.com/What-is-Ipv6/ ============================================================================================================ Join us on Site: http://telecomacadmey.com/ Join us on Facebook: https://www.facebook.com/Telecom-Acad... Join us on Twitter: https://twitter.com/TelecomAcad Join us on tumblr: https://www.tumblr.com/blog/telecomac... Join us on Quora: https://www.quora.com/profile/Telecom... Join us on Google +: https://plus.google.com/u/0/104392545... Join us on Instagram: https://www.instagram.com/telecomacad/ Join us on pinterest: https://www.pinterest.com/hamzathenet...
The document describes migrating from OSPF to IS-IS as an IGP. It begins by discussing the preparation needed, such as verifying OSPF configuration, deploying IS-IS across the entire backbone, and setting OSPF's administrative distance higher than IS-IS. Next, it details removing any remaining OSPF configuration and confirming IS-IS is operating correctly before fully removing OSPF. The goal is a smooth migration to using a single IGP of IS-IS for both IPv4 and IPv6 routing.
- By default, EIGRP has auto summarization enabled which summarizes routes to classful boundaries, but this can cause issues, so EIGRP allows manual summarization at arbitrary boundaries using the ip summary-address command.
- Manual summarization can be configured on any router or interface in an EIGRP domain. A summary route will exist as long as there is at least one more specific route; if the last specific route disappears, the summary will also disappear.
- The document provides an example configuration of EIGRP routing between four routers (R1, R2, R3, R4) with the configuration of manual summarization on R2's S0/0 interface to summarize routes
This document summarizes a chapter about EIGRP and OSPF routing protocols. It discusses key aspects of configuring and verifying EIGRP like using the router eigrp command to enable EIGRP on interfaces, and show commands to view EIGRP neighbor relationships and routing tables. It also covers fundamental OSPF concepts like using network statements to assign interfaces to areas, and show commands to verify the OSPF configuration and neighbor adjacencies. The document provides configuration examples and explains OSPF terminology regarding neighbors, designated routers, and using wildcards in network statements.
This document provides guidance on IPv6 address planning. It discusses how to obtain IPv6 address space from regional internet registries or upstream ISPs. It recommends allocating address space for infrastructure, point-to-point links, LANs, and customers. Specific allocation sizes are suggested, such as a /48 for infrastructure and a /48 or smaller for customers depending on their needs. The document also discusses nibble boundaries and examples of IPv6 address plans including for ISP infrastructure, point-to-point links to customers, and allocating to customers.
The document discusses redistributing routes between routing protocols. It provides configuration examples of redistributing OSPF routes into EIGRP on router R1. The key command for redistribution is "redistribute" in router configuration mode. Metrics are also configured on R1 using the "default-metric" command to redistribute OSPF routes into EIGRP.
An experiment was conducted using stateless NAT64 to connect an IPv6-only network to an IPv4-only network at a conference with 350 attendees and 550 devices. TAYGA, an open-source stateless NAT64 implementation, was used to provide one-to-one mapping between IPv6 hosts and IPv4 addresses. DNS64 was also implemented to provide synthetic DNS responses. The results showed no noticeable performance degradation compared to the dual-stack network, and popular applications like Skype and Dropbox worked successfully, demonstrating stateless NAT64 can be a viable solution.
The document provides an overview of 6RD (IPv6 Rapid Deployment), describing how it was developed from 6to4 to allow ISPs to deliver IPv6 connectivity to customers over their existing IPv4 networks using a stateless encapsulation method, and details the key components and configuration parameters needed for implementing 6RD including the 6RD prefix, IPv4 common bits, and border relay address.
Internet Routing Registry and RPKI Tutorial, by Nurul Islam Roman [APNIC 38]APNIC
The document provides an introduction to Internet routing registries (IRRs) and the APNIC Routing Registry. It explains key concepts such as autonomous systems (AS), routing policies, and the Routing Policy Specification Language (RPSL) used to define routing objects and policies in IRRs. The document also outlines the benefits of using the APNIC Routing Registry to define routing policies and filtering requirements between networks and autonomous systems.
Internet Routing Registry Tutorial, by Nurul Islam Roman [APRICOT 2015]APNIC
The document provides an introduction to the APNIC Routing Registry and Routing Policy Specification Language (RPSL). It discusses (1) the objectives of explaining concepts of the global Internet Routing Registry (IRR), outlining benefits of APNIC's registry, and discussing RPSL; (2) an overview of what an IRR is, how routing policies are represented, and how objects in the APNIC database are related and protected; and (3) how routing information is integrated into the APNIC database and distributed through the global IRR system.
This 3-day routing workshop covers key routing concepts including IP routing, routing protocols, IPv6 addressing, and hands-on exercises. Participants will learn about interior routing protocols like OSPF, exterior routing protocols like BGP, routing attributes, path selection, and scaling techniques. Hands-on labs will provide experience with router configuration, OSPF, iBGP, eBGP, route reflectors, and Internet exchange policies. The goal is to give attendees a solid foundation in routing fundamentals and operations.
Part 10 : Routing in IP networks and interdomain routing with BGPOlivier Bonaventure
This document discusses routing in IP networks and interdomain routing with BGP. It begins by covering intradomain routing protocols like RIP and OSPF, then discusses interdomain routing and the exterior gateway protocol BGP. BGP allows domains to exchange routing information and select paths between domains while applying each domain's routing policies.
PLNOG 13: L. Iannone, W. Shao: Internet Traffic-Engineering with LISPPROIDEA
Luigi IANNONE - Luigi is currently an Associate Professor at Telecom ParisTech (Paris), since May 2012. He was previously Senior Research Scientist at Deutsche Telekom Innovation Laboratories (TLabs, Berlin Germany); post-doc Researcher at Université catholique de Louvain (UCL - Belgium); and worked at the Université Pierre et Marie Curie (Paris VI – France), first as Ph.D. candidate and later as post-doc. His current research interests include intra- and inter- domain routing, future Internet architectures, as well as mobility, wireless networks, and wired/wireless convergence. He is currently serving on the editorial board of Elsevier Computer Networks Journal. Luigi Iannone is also co-chair of the LISP Working Group at the IETF (Internet Engineering Task Force) and the main developer of the OpenLISP Project.
Wenqin Shao – Wenqin SHAO is a PhD candidate at Telecom ParisTech. Meanwhile he is also a research engineer working for BORDER 6. He received an Engineering degree from Telecom ParisTech in 2013 and a Bachelor of Engineering in 2010 from Fudan University, Shanghai. He previously worked as solution manager and network architect separately for SFR and Wibox, both of which are French telecom operators. His current research interests cover internet routing and traffic engineering, and more generally enhanced solutions for operating network systems, so as to deliver ever-evolving services in a less constrained Internet.
Abstract: “LISP (locator/Identifier Separation Protocol) brings a revolutionary model for routing in largescale networks. Its original aim is to help reducing the size of the routing tables and thus bringing better scalability to the Internet. Due to its inherent flexibility, there are today several scenarios and use-cases where LISP is experimented and deployed either to enable new features or to fix (or at least alleviate) issues with current models and protocols (e.g., VM mobility, IPv6 transition, traffic-engineering, etc.). These new and improved capabilities are experimented within two co-existing environments: the LISP Beta-Network (http://www.lisp4.net), where Cisco is a major contributor, and LISP-lab (http://www.lisplab. org), mainly built on the open-source OpenLISP Project (http://www.openlisp.org). Within this session, we propose to present a case study where LISP is used as a control-plane signaling protocol for traffic engineering over the Internet. It intends to showcase how the current Internet performance can be improved through coordinated traffic engineering via orchestrated source and destination Autonomous Systems routing decisions. Such an objective is achieved without touching or tweaking in any way the current BGP routing infrastructure. In the proposed deployment model LISP provides both control- and data- plane functions; with a full LISP stack on both ends, it can as well operate as an traffic engineering control-plane on top of the BGP routing infrastructure.
The document provides an overview of routing basics, including: what routers do in finding paths and forwarding packets; the difference between routing and forwarding; how IP route lookup works using longest prefix matching; how routing information databases (RIBs) and forwarding information bases (FIBs) are used; explicit versus default routing; and an introduction to autonomous systems, routing policies, interior gateway protocols (IGPs), exterior gateway protocols (EGPs) like BGP, and how routing and traffic flows work within and between autonomous systems.
This document contains a tutorial on BGP (Border Gateway Protocol) presented at the APRICOT 2004 conference in Kuala Lumpur. The tutorial is split into two parts, with part one covering introductions and routing basics, and part two focusing on multihoming techniques. The presentation covers topics such as BGP attributes, path selection, policy, and scaling BGP implementations.
APNIC Information Products Manager Tom Harrison gives an overview of RPKI and whois updates at AusNOG 2023, held in the Gold Coast, Australia from 7 to 8 September 2023.
v6_whats-happening (presentation at GEANT APM meeting, 2011, Ljubljana)matjazsi
The document discusses IPv6 traffic monitoring and analysis capabilities in networks. It provides examples of using Cisco and Juniper routers to collect IPv6 traffic counters and NetFlow data. Analysis of IPv6 traffic in ARNES' network shows a year-over-year increase from a 1:7,000 to 1:70 ratio of IPv6 to IPv4 traffic. Most of the IPv6 traffic originates from Google's AS, due to the deployment of IPv6 in student dormitories and ARNES' participation in the IPv6 @Google program.
Segment Routing (SR) is a tunneling and traffic engineering technology that allows routers to steer traffic along an SR path that may differ from the normal shortest path. An SR path is divided into segments that connect points within the SR domain. Segments are represented by Segment Identifiers (SIDs) that can identify single hops or multiple hops. The SR header or MPLS label stack enumerates the segments in the path to forward packets. SR supports various segment types including adjacency, prefix, anycast, and binding segments. SR provides traffic engineering capabilities and flexibility in path selection within the domain.
- R1 tracks its OSPF metric to R3's loopback interface using a track object, which adjusts R1's HSRP priority when the metric exceeds thresholds.
- When R1's link to R3 fails, the track object detects the increased OSPF metric and lowers R1's HSRP priority, making R2 the active router.
- R2 also tracks its OSPF metric to R4's loopback, dividing the metric to fit the 1-255 threshold range. This allows R1 to regain active status if its path to R4 improves.
The document provides an overview of IPv6 addressing and subnetting. It discusses IPv6 address representation and structure, including that addresses are 128 bits long and represented in hexadecimal. The addressing hierarchy from ISP to customer site to individual devices is covered. Different address types like link-local and global unicast are defined. IPv6 autoconfiguration and how devices generate interface IDs are summarized. The document concludes with an example of how to subnet a provider's IPv6 block and allocate /48 prefixes to multiple customers.
Internet Protocol version 6 (IPv6) is the most recent version of the Internet Protocol (IP), the communications protocol that provides an identification and location system for computers on networks and routes traffic across the Internet. IPv6 was developed by the Internet Engineering Task Force (IETF) to deal with the long-anticipated problem of IPv4 address exhaustion. IPv6 is intended to replace IPv4. Watch more: http://telecomacadmey.com/What-is-Ipv6/ ============================================================================================================ Join us on Site: http://telecomacadmey.com/ Join us on Facebook: https://www.facebook.com/Telecom-Acad... Join us on Twitter: https://twitter.com/TelecomAcad Join us on tumblr: https://www.tumblr.com/blog/telecomac... Join us on Quora: https://www.quora.com/profile/Telecom... Join us on Google +: https://plus.google.com/u/0/104392545... Join us on Instagram: https://www.instagram.com/telecomacad/ Join us on pinterest: https://www.pinterest.com/hamzathenet...
The document describes migrating from OSPF to IS-IS as an IGP. It begins by discussing the preparation needed, such as verifying OSPF configuration, deploying IS-IS across the entire backbone, and setting OSPF's administrative distance higher than IS-IS. Next, it details removing any remaining OSPF configuration and confirming IS-IS is operating correctly before fully removing OSPF. The goal is a smooth migration to using a single IGP of IS-IS for both IPv4 and IPv6 routing.
- By default, EIGRP has auto summarization enabled which summarizes routes to classful boundaries, but this can cause issues, so EIGRP allows manual summarization at arbitrary boundaries using the ip summary-address command.
- Manual summarization can be configured on any router or interface in an EIGRP domain. A summary route will exist as long as there is at least one more specific route; if the last specific route disappears, the summary will also disappear.
- The document provides an example configuration of EIGRP routing between four routers (R1, R2, R3, R4) with the configuration of manual summarization on R2's S0/0 interface to summarize routes
This document summarizes a chapter about EIGRP and OSPF routing protocols. It discusses key aspects of configuring and verifying EIGRP like using the router eigrp command to enable EIGRP on interfaces, and show commands to view EIGRP neighbor relationships and routing tables. It also covers fundamental OSPF concepts like using network statements to assign interfaces to areas, and show commands to verify the OSPF configuration and neighbor adjacencies. The document provides configuration examples and explains OSPF terminology regarding neighbors, designated routers, and using wildcards in network statements.
This document provides guidance on IPv6 address planning. It discusses how to obtain IPv6 address space from regional internet registries or upstream ISPs. It recommends allocating address space for infrastructure, point-to-point links, LANs, and customers. Specific allocation sizes are suggested, such as a /48 for infrastructure and a /48 or smaller for customers depending on their needs. The document also discusses nibble boundaries and examples of IPv6 address plans including for ISP infrastructure, point-to-point links to customers, and allocating to customers.
The document discusses redistributing routes between routing protocols. It provides configuration examples of redistributing OSPF routes into EIGRP on router R1. The key command for redistribution is "redistribute" in router configuration mode. Metrics are also configured on R1 using the "default-metric" command to redistribute OSPF routes into EIGRP.
An experiment was conducted using stateless NAT64 to connect an IPv6-only network to an IPv4-only network at a conference with 350 attendees and 550 devices. TAYGA, an open-source stateless NAT64 implementation, was used to provide one-to-one mapping between IPv6 hosts and IPv4 addresses. DNS64 was also implemented to provide synthetic DNS responses. The results showed no noticeable performance degradation compared to the dual-stack network, and popular applications like Skype and Dropbox worked successfully, demonstrating stateless NAT64 can be a viable solution.
The document provides an overview of 6RD (IPv6 Rapid Deployment), describing how it was developed from 6to4 to allow ISPs to deliver IPv6 connectivity to customers over their existing IPv4 networks using a stateless encapsulation method, and details the key components and configuration parameters needed for implementing 6RD including the 6RD prefix, IPv4 common bits, and border relay address.
Internet Routing Registry and RPKI Tutorial, by Nurul Islam Roman [APNIC 38]APNIC
The document provides an introduction to Internet routing registries (IRRs) and the APNIC Routing Registry. It explains key concepts such as autonomous systems (AS), routing policies, and the Routing Policy Specification Language (RPSL) used to define routing objects and policies in IRRs. The document also outlines the benefits of using the APNIC Routing Registry to define routing policies and filtering requirements between networks and autonomous systems.
Internet Routing Registry Tutorial, by Nurul Islam Roman [APRICOT 2015]APNIC
The document provides an introduction to the APNIC Routing Registry and Routing Policy Specification Language (RPSL). It discusses (1) the objectives of explaining concepts of the global Internet Routing Registry (IRR), outlining benefits of APNIC's registry, and discussing RPSL; (2) an overview of what an IRR is, how routing policies are represented, and how objects in the APNIC database are related and protected; and (3) how routing information is integrated into the APNIC database and distributed through the global IRR system.
This 3-day routing workshop covers key routing concepts including IP routing, routing protocols, IPv6 addressing, and hands-on exercises. Participants will learn about interior routing protocols like OSPF, exterior routing protocols like BGP, routing attributes, path selection, and scaling techniques. Hands-on labs will provide experience with router configuration, OSPF, iBGP, eBGP, route reflectors, and Internet exchange policies. The goal is to give attendees a solid foundation in routing fundamentals and operations.
Part 10 : Routing in IP networks and interdomain routing with BGPOlivier Bonaventure
This document discusses routing in IP networks and interdomain routing with BGP. It begins by covering intradomain routing protocols like RIP and OSPF, then discusses interdomain routing and the exterior gateway protocol BGP. BGP allows domains to exchange routing information and select paths between domains while applying each domain's routing policies.
PLNOG 13: L. Iannone, W. Shao: Internet Traffic-Engineering with LISPPROIDEA
Luigi IANNONE - Luigi is currently an Associate Professor at Telecom ParisTech (Paris), since May 2012. He was previously Senior Research Scientist at Deutsche Telekom Innovation Laboratories (TLabs, Berlin Germany); post-doc Researcher at Université catholique de Louvain (UCL - Belgium); and worked at the Université Pierre et Marie Curie (Paris VI – France), first as Ph.D. candidate and later as post-doc. His current research interests include intra- and inter- domain routing, future Internet architectures, as well as mobility, wireless networks, and wired/wireless convergence. He is currently serving on the editorial board of Elsevier Computer Networks Journal. Luigi Iannone is also co-chair of the LISP Working Group at the IETF (Internet Engineering Task Force) and the main developer of the OpenLISP Project.
Wenqin Shao – Wenqin SHAO is a PhD candidate at Telecom ParisTech. Meanwhile he is also a research engineer working for BORDER 6. He received an Engineering degree from Telecom ParisTech in 2013 and a Bachelor of Engineering in 2010 from Fudan University, Shanghai. He previously worked as solution manager and network architect separately for SFR and Wibox, both of which are French telecom operators. His current research interests cover internet routing and traffic engineering, and more generally enhanced solutions for operating network systems, so as to deliver ever-evolving services in a less constrained Internet.
Abstract: “LISP (locator/Identifier Separation Protocol) brings a revolutionary model for routing in largescale networks. Its original aim is to help reducing the size of the routing tables and thus bringing better scalability to the Internet. Due to its inherent flexibility, there are today several scenarios and use-cases where LISP is experimented and deployed either to enable new features or to fix (or at least alleviate) issues with current models and protocols (e.g., VM mobility, IPv6 transition, traffic-engineering, etc.). These new and improved capabilities are experimented within two co-existing environments: the LISP Beta-Network (http://www.lisp4.net), where Cisco is a major contributor, and LISP-lab (http://www.lisplab. org), mainly built on the open-source OpenLISP Project (http://www.openlisp.org). Within this session, we propose to present a case study where LISP is used as a control-plane signaling protocol for traffic engineering over the Internet. It intends to showcase how the current Internet performance can be improved through coordinated traffic engineering via orchestrated source and destination Autonomous Systems routing decisions. Such an objective is achieved without touching or tweaking in any way the current BGP routing infrastructure. In the proposed deployment model LISP provides both control- and data- plane functions; with a full LISP stack on both ends, it can as well operate as an traffic engineering control-plane on top of the BGP routing infrastructure.
The document provides an overview of routing basics, including: what routers do in finding paths and forwarding packets; the difference between routing and forwarding; how IP route lookup works using longest prefix matching; how routing information databases (RIBs) and forwarding information bases (FIBs) are used; explicit versus default routing; and an introduction to autonomous systems, routing policies, interior gateway protocols (IGPs), exterior gateway protocols (EGPs) like BGP, and how routing and traffic flows work within and between autonomous systems.
This document contains a tutorial on BGP (Border Gateway Protocol) presented at the APRICOT 2004 conference in Kuala Lumpur. The tutorial is split into two parts, with part one covering introductions and routing basics, and part two focusing on multihoming techniques. The presentation covers topics such as BGP attributes, path selection, policy, and scaling BGP implementations.
APNIC Information Products Manager Tom Harrison gives an overview of RPKI and whois updates at AusNOG 2023, held in the Gold Coast, Australia from 7 to 8 September 2023.
v6_whats-happening (presentation at GEANT APM meeting, 2011, Ljubljana)matjazsi
The document discusses IPv6 traffic monitoring and analysis capabilities in networks. It provides examples of using Cisco and Juniper routers to collect IPv6 traffic counters and NetFlow data. Analysis of IPv6 traffic in ARNES' network shows a year-over-year increase from a 1:7,000 to 1:70 ratio of IPv6 to IPv4 traffic. Most of the IPv6 traffic originates from Google's AS, due to the deployment of IPv6 in student dormitories and ARNES' participation in the IPv6 @Google program.
This excellent session by Alexander Bolshev (@dark_k3y) was a very pleasant surprise, and it's a bit frustrating that it is one of the three lost S4x14 videos.
We were concerned that it would be a bit S4x13 / insecure by design / low hanging fruit, but HART has received so little attention that we thought it was worth including in S4x14. HART is widely used in DCS to connect controllers and instruments. The HART Foundation says over 30 million HART devices are deployed.
Alexander covers the protocol in the early slides, but make sure you look at slides 16-21 where he shows how he can change the RTU's Polling Unit ID (who the RTU expects to poll it) to create a man-in-the-middle attack.
There are a number of other HART protocol attacks described, but I was most interested in his HRT Shield board - a high-power low-noise HART modem Arduino shield for sniffing, injecHng, and jamming current loop. He brought over some boards that we are building up to have in our Rack when we go out on an assessment.
I should note, mainly to avoid an email from Jeff, that WirelessHART has integrated security such as source/data authentication and encryption. As we walk through plants and factories we are seeing a number of these WirelessHART devices. They are easy to spot because they can be deployed in the most physically convenient place without worrying about wiring.
The document discusses routing protocols in IP networks and interdomain routing. It provides an overview of IPv6 neighbor discovery, routing protocols RIP and OSPF, and interdomain routing with BGP. Key concepts covered include how routers discover each other on the local link, distance vector and link-state routing, using areas in OSPF, and the path vector exchange in BGP to choose optimal routes between autonomous systems.
Cisco Connect Toronto 2017 - Model-driven TelemetryCisco Canada
This document provides an overview of Cisco's model-driven telemetry solution. It discusses key concepts like data models, encodings, transports and the telemetry pipeline. YANG is presented as the modeling language and telemetry is described as having three key enablers: push-based collection, analytics-ready data formats, and being data model-driven. Cisco routers support model-driven telemetry via gRPC, TCP, UDP and provide interfaces, system and other data in YANG, OpenConfig and IETF models.
Routing Registry Function Automation using RPKI & RPSLAPNIC
Routing Registry Function Automation using RPKI & RPSL, by Nurul Islam and Fakrul Alam.
A presentation given at APRICOT 2016’s Routing Registry Function Automation using RPKI & RPSL (Part 1 and 2) sessions on 22 February 2016.
The document discusses various techniques for transitioning from IPv4 to IPv6, including dual stack, tunnels, and translation. Dual stack allows simultaneous support of both IPv4 and IPv6 by keeping both protocol stacks. Tunnels encapsulate IPv6 packets in IPv4 packets to carry IPv6 traffic over IPv4 networks. Translation techniques like NAT64 algorithmically translate IPv4 and IPv6 addresses to allow communication between IPv4-only and IPv6-only nodes. Newer methods like 464XLAT and DS-Lite aim to address IPv4 exhaustion by sharing public IPv4 addresses among more clients.
Applied Detection and Analysis with Flow Data - SO Con 2014chrissanders88
The document discusses using network flow data for applied detection and analysis. It describes how to collect flow data using tools like SiLK, analyze the data using rwfilter, rwstats and other SiLK tools, and use the results for detection via visualizations with FlowPlotter and intelligence gathering. Flow data provides benefits like small data footprint and scalability compared to full packet capture.
The presentation covers the basics of packet forwarding and simplified architecture of the router. Additionally it explains what problem Cisco Express Forwarding (CEF) solves and how. At the end static routing is covered.
Delivered by Dmitry Figol, CCIE R&S #53592.
Navigating IP Addresses: Insights from your Regional Internet RegistryRIPE NCC
The document summarizes insights from Alena Muravska of the RIPE NCC about navigating IP addresses. It provides statistics on Internet number resources allocated to Poland by the RIPE NCC, including that Poland has 687 members and 737 LIRs. It discusses the depletion of IPv4 addresses and the new IPv4 allocation policy, noting that 32 Polish LIRs are currently waiting in the IPv4 waiting list. It also covers IPv6 allocations and assignments for members and non-members, and provides graphs on IPv4 holdings and IPv6 capability in Poland.
The presentation discusses the RPKI system and a recent incident where a threat actor gained access to an organization's RPKI dashboard using a leaked password. This led to unexpected changes being made to the organization's RPKI ROAs, causing a routing outage that disrupted internet connectivity. The presentation emphasizes the importance of strong passwords, multi-factor authentication, network security monitoring, and having an incident response plan to prevent similar incidents and increase routing resilience.
LIA HESTINA - Minimising impact before incidents occur with RIPE Atlas and RISRIPE NCC
This document discusses how network operators can minimize the impact of incidents on their networks using RIPE Atlas and Routing Information Services (RIS). It recommends strategically deploying RIPE Atlas probes and peering with RIS to continuously monitor the network. It also suggests setting up alerts to detect abnormalities and anomalies swiftly. Additional recommendations include maintaining low latency through debugging, and impressing customers by showcasing network performance.
IGF UA - Dialog with I_ organisations - Alena Muavska RIPE NCC.pdfRIPE NCC
This document summarizes Alena Muravska's presentation on engaging the Ukrainian community during times of war. It discusses how the Ukrainian community can participate in the RIPE community through various working groups and meetings. It also outlines how the RIPE NCC has supported Ukraine, including dedicating sessions to discuss the internet in Ukraine and forming a task force on best practices to survive disasters or war. Finally, it discusses efforts taken to protect Ukrainian resource holders, such as preventing unauthorized transfers of internet resources and examining changes made to country codes during the invasion.
Opportunities for Youth in IG - Alena Muravska RIPE NCC.pdfRIPE NCC
The document discusses opportunities for youth involvement in internet governance through the RIPE NCC. It describes the RIPE NCC as the regional internet registry for Europe, the Middle East, and Central Asia that allocates IP addresses and supports the open internet community. It outlines how individuals can participate in RIPE community working groups, meetings, policy development processes, and more. It specifically highlights the RIPE Fellowships and RIPE Academic Cooperation Initiative programs that fund youth attendance at RIPE meetings and encourage engagement between academia and the RIPE community.
The document discusses the RIPE NCC's Internet measurement tools - RIPE Routing Information Service (RIPE RIS), RIPEstat, and RIPE Atlas. It provides details on each tool, including how they collect and analyze routing data, Internet traffic maps, and performance measurements from over 12,000 probes worldwide. The tools are used by network operators, researchers, and policymakers to monitor routing, identify incidents, and inform future plans. Future plans include improving data collection and analysis, open sourcing components, and renewing back-end systems.
This document discusses RPKI (Resource Public Key Infrastructure) for securing Internet routing. It provides statistics on RPKI adoption in Luxembourg and neighboring countries, showing that while Luxembourg has over 65% of its address space covered by ROAs, not all networks have fully implemented RPKI. The goal is 100% RPKI implementation to validate all routes and prevent route hijacking, but obstacles still exist to full deployment. The presenter's contact information is provided for any questions.
The document discusses RIPE NCC's engagement in Southeast Europe, including organizing meetings, supporting network operator groups, developing internet exchange points, and funding opportunities. It then covers the topics of internet resiliency, analyzing networks in Belarus, Ukraine, Turkey and Poland using routing data. Next, it provides an analysis of internet landscapes in specific Southeast European countries. Key findings include the role of incumbent telecom operators, efficiency of regional routing but some anomalies, and modest diversity in routes into the region. Data sources used are also listed.
Know Your Network: Why Every Network Operator Should Host RIPE AtlasRIPE NCC
The document discusses the benefits of network operators hosting RIPE Atlas probes. It describes RIPE Atlas as an active measurements platform that monitors internet reachability through probes hosted by volunteers around the world. It highlights that RIPE Atlas data is publicly available and can be used by network operators to monitor performance, identify issues, validate findings, and plan improvements. The document encourages network operators in Africa to install RIPE Atlas probes to better monitor their networks and neighborhoods.
Minimising Impact When Incidents Occur With RIPE AtlasRIPE NCC
The document discusses how the online gaming company Mbappe uses RIPE Atlas to monitor network performance and minimize latency issues for their global users. It recommends strategically deploying RIPE Atlas probes, continuously monitoring measurements, and setting up alerts to quickly detect anomalies. When issues are found, the recommended actions are to identify network problems swiftly, debug issues to maintain low latency, and showcase network performance to impress customers. Installing probes in specific autonomous systems and networks could help identify parts of the network with high latency that are important to address.
- RIPE NCC provides internet measurement services including the Routing Information Service (RIS), RIPEstat, and RIPE Atlas to collect and provide data on internet routing and performance.
- RIS collects raw BGP data from remote route collectors at internet exchange points to observe real internet routing. RIPEstat and RIPE Atlas provide tools to analyze and visualize this data.
- RIPE Atlas specifically operates a global network of internet measurement devices that actively monitor connectivity, reachability, and performance. Its data and custom measurement tools are available to both network operators and researchers.
RIPE Atlas is a global measurement platform that uses probes hosted by volunteers to monitor internet connectivity and latency. It provides latency maps showing routes between networks and allows custom measurements. The presentation highlighted how RIPE Atlas can be used to identify networks with high latency, view routes and locations of probes, and conduct DNS and traceroute tests while remaining secure and low cost. Hosting a RIPE Atlas probe or improving coverage in certain regions would further benefit internet monitoring.
Presentasi menjelaskan tentang penggunaan RIPE Atlas untuk mendeteksi masalah latensi di internet. RIPE Atlas adalah platform pengukuran internet global yang menggunakan probe di seluruh dunia untuk melakukan pengukuran kinerja jaringan seperti ping dan traceroute. Presentasi mendemonstrasikan bagaimana RIPE Atlas dapat digunakan untuk mengidentifikasi anomali latensi dan membantu perusahaan game online menyelesaikan masalah kinerja mereka.
RIPE Atlas is a global network measurement platform that uses volunteer-hosted probes to monitor Internet performance and availability. It runs tests including ping, traceroute, and DNS to identify issues like high latency. The presentation discusses using RIPE Atlas to help an online gaming company identify and address latency problems impacting users in different regions. It also provides examples of the probes and measurements available in Southeast Asian countries like the Philippines.
20 Comprehensive Checklist of Designing and Developing a WebsitePixlogix Infotech
Dive into the world of Website Designing and Developing with Pixlogix! Looking to create a stunning online presence? Look no further! Our comprehensive checklist covers everything you need to know to craft a website that stands out. From user-friendly design to seamless functionality, we've got you covered. Don't miss out on this invaluable resource! Check out our checklist now at Pixlogix and start your journey towards a captivating online presence today.
How to Get CNIC Information System with Paksim Ga.pptxdanishmna97
Pakdata Cf is a groundbreaking system designed to streamline and facilitate access to CNIC information. This innovative platform leverages advanced technology to provide users with efficient and secure access to their CNIC details.
Cosa hanno in comune un mattoncino Lego e la backdoor XZ?Speck&Tech
ABSTRACT: A prima vista, un mattoncino Lego e la backdoor XZ potrebbero avere in comune il fatto di essere entrambi blocchi di costruzione, o dipendenze di progetti creativi e software. La realtà è che un mattoncino Lego e il caso della backdoor XZ hanno molto di più di tutto ciò in comune.
Partecipate alla presentazione per immergervi in una storia di interoperabilità, standard e formati aperti, per poi discutere del ruolo importante che i contributori hanno in una comunità open source sostenibile.
BIO: Sostenitrice del software libero e dei formati standard e aperti. È stata un membro attivo dei progetti Fedora e openSUSE e ha co-fondato l'Associazione LibreItalia dove è stata coinvolta in diversi eventi, migrazioni e formazione relativi a LibreOffice. In precedenza ha lavorato a migrazioni e corsi di formazione su LibreOffice per diverse amministrazioni pubbliche e privati. Da gennaio 2020 lavora in SUSE come Software Release Engineer per Uyuni e SUSE Manager e quando non segue la sua passione per i computer e per Geeko coltiva la sua curiosità per l'astronomia (da cui deriva il suo nickname deneb_alpha).
Unlock the Future of Search with MongoDB Atlas_ Vector Search Unleashed.pdfMalak Abu Hammad
Discover how MongoDB Atlas and vector search technology can revolutionize your application's search capabilities. This comprehensive presentation covers:
* What is Vector Search?
* Importance and benefits of vector search
* Practical use cases across various industries
* Step-by-step implementation guide
* Live demos with code snippets
* Enhancing LLM capabilities with vector search
* Best practices and optimization strategies
Perfect for developers, AI enthusiasts, and tech leaders. Learn how to leverage MongoDB Atlas to deliver highly relevant, context-aware search results, transforming your data retrieval process. Stay ahead in tech innovation and maximize the potential of your applications.
#MongoDB #VectorSearch #AI #SemanticSearch #TechInnovation #DataScience #LLM #MachineLearning #SearchTechnology
Pushing the limits of ePRTC: 100ns holdover for 100 daysAdtran
At WSTS 2024, Alon Stern explored the topic of parametric holdover and explained how recent research findings can be implemented in real-world PNT networks to achieve 100 nanoseconds of accuracy for up to 100 days.
Why You Should Replace Windows 11 with Nitrux Linux 3.5.0 for enhanced perfor...SOFTTECHHUB
The choice of an operating system plays a pivotal role in shaping our computing experience. For decades, Microsoft's Windows has dominated the market, offering a familiar and widely adopted platform for personal and professional use. However, as technological advancements continue to push the boundaries of innovation, alternative operating systems have emerged, challenging the status quo and offering users a fresh perspective on computing.
One such alternative that has garnered significant attention and acclaim is Nitrux Linux 3.5.0, a sleek, powerful, and user-friendly Linux distribution that promises to redefine the way we interact with our devices. With its focus on performance, security, and customization, Nitrux Linux presents a compelling case for those seeking to break free from the constraints of proprietary software and embrace the freedom and flexibility of open-source computing.
Goodbye Windows 11: Make Way for Nitrux Linux 3.5.0!SOFTTECHHUB
As the digital landscape continually evolves, operating systems play a critical role in shaping user experiences and productivity. The launch of Nitrux Linux 3.5.0 marks a significant milestone, offering a robust alternative to traditional systems such as Windows 11. This article delves into the essence of Nitrux Linux 3.5.0, exploring its unique features, advantages, and how it stands as a compelling choice for both casual users and tech enthusiasts.
Threats to mobile devices are more prevalent and increasing in scope and complexity. Users of mobile devices desire to take full advantage of the features
available on those devices, but many of the features provide convenience and capability but sacrifice security. This best practices guide outlines steps the users can take to better protect personal devices and information.
Encryption in Microsoft 365 - ExpertsLive Netherlands 2024Albert Hoitingh
In this session I delve into the encryption technology used in Microsoft 365 and Microsoft Purview. Including the concepts of Customer Key and Double Key Encryption.
GraphSummit Singapore | The Future of Agility: Supercharging Digital Transfor...Neo4j
Leonard Jayamohan, Partner & Generative AI Lead, Deloitte
This keynote will reveal how Deloitte leverages Neo4j’s graph power for groundbreaking digital twin solutions, achieving a staggering 100x performance boost. Discover the essential role knowledge graphs play in successful generative AI implementations. Plus, get an exclusive look at an innovative Neo4j + Generative AI solution Deloitte is developing in-house.
“An Outlook of the Ongoing and Future Relationship between Blockchain Technologies and Process-aware Information Systems.” Invited talk at the joint workshop on Blockchain for Information Systems (BC4IS) and Blockchain for Trusted Data Sharing (B4TDS), co-located with with the 36th International Conference on Advanced Information Systems Engineering (CAiSE), 3 June 2024, Limassol, Cyprus.
A tale of scale & speed: How the US Navy is enabling software delivery from l...sonjaschweigert1
Rapid and secure feature delivery is a goal across every application team and every branch of the DoD. The Navy’s DevSecOps platform, Party Barge, has achieved:
- Reduction in onboarding time from 5 weeks to 1 day
- Improved developer experience and productivity through actionable findings and reduction of false positives
- Maintenance of superior security standards and inherent policy enforcement with Authorization to Operate (ATO)
Development teams can ship efficiently and ensure applications are cyber ready for Navy Authorizing Officials (AOs). In this webinar, Sigma Defense and Anchore will give attendees a look behind the scenes and demo secure pipeline automation and security artifacts that speed up application ATO and time to production.
We will cover:
- How to remove silos in DevSecOps
- How to build efficient development pipeline roles and component templates
- How to deliver security artifacts that matter for ATO’s (SBOMs, vulnerability reports, and policy evidence)
- How to streamline operations with automated policy checks on container images
Alt. GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using ...James Anderson
Effective Application Security in Software Delivery lifecycle using Deployment Firewall and DBOM
The modern software delivery process (or the CI/CD process) includes many tools, distributed teams, open-source code, and cloud platforms. Constant focus on speed to release software to market, along with the traditional slow and manual security checks has caused gaps in continuous security as an important piece in the software supply chain. Today organizations feel more susceptible to external and internal cyber threats due to the vast attack surface in their applications supply chain and the lack of end-to-end governance and risk management.
The software team must secure its software delivery process to avoid vulnerability and security breaches. This needs to be achieved with existing tool chains and without extensive rework of the delivery processes. This talk will present strategies and techniques for providing visibility into the true risk of the existing vulnerabilities, preventing the introduction of security issues in the software, resolving vulnerabilities in production environments quickly, and capturing the deployment bill of materials (DBOM).
Speakers:
Bob Boule
Robert Boule is a technology enthusiast with PASSION for technology and making things work along with a knack for helping others understand how things work. He comes with around 20 years of solution engineering experience in application security, software continuous delivery, and SaaS platforms. He is known for his dynamic presentations in CI/CD and application security integrated in software delivery lifecycle.
Gopinath Rebala
Gopinath Rebala is the CTO of OpsMx, where he has overall responsibility for the machine learning and data processing architectures for Secure Software Delivery. Gopi also has a strong connection with our customers, leading design and architecture for strategic implementations. Gopi is a frequent speaker and well-known leader in continuous delivery and integrating security into software delivery.
Dr. Sean Tan, Head of Data Science, Changi Airport Group
Discover how Changi Airport Group (CAG) leverages graph technologies and generative AI to revolutionize their search capabilities. This session delves into the unique search needs of CAG’s diverse passengers and customers, showcasing how graph data structures enhance the accuracy and relevance of AI-generated search results, mitigating the risk of “hallucinations” and improving the overall customer journey.
Let's Integrate MuleSoft RPA, COMPOSER, APM with AWS IDP along with Slackshyamraj55
Discover the seamless integration of RPA (Robotic Process Automation), COMPOSER, and APM with AWS IDP enhanced with Slack notifications. Explore how these technologies converge to streamline workflows, optimize performance, and ensure secure access, all while leveraging the power of AWS IDP and real-time communication via Slack notifications.
5. Internet Routing Registry
• Several public databases that contain routing policy
information that mirror each other:
• RIPE, APNIC, RADB, JPIRR, Level3, etc.
• http://www.irr.net
!
• RIPE NCC operates the RIPE Routing Registry
• Part of the RIPE Database
• Part of the Internet Routing Registry
5
6. IRR, RIPE DB, RIPE RR 6
Internet Routing
Registry
APNIC
DB
RADB
RIPE
ROUTING
REGISTRY
RIPE DB
ARIN
DB
LEVEL3
LACNIC
DB
AFRINIC
DB
...
7. What is the purpose of RR?
• To be able to answer the question:
• Is that ASN authorised to originate that address
range?
7
8. What is a Routing Policy?
• What prefixes do you announce?
• Who are your neighbours?
• Peers, transits and customers
• Which prefixes do you accept from them?
• What are your preferences?
8
9. Why Publish Your Policy?
• Some transit providers and IXPs (Internet Exchange
Points) require it for filtering
• Contributes to make routing more secure and stable
!
• Can help with troubleshooting
!
9
10. RIPE Database and the RR
• Close relation between registry information and routing
policy
• The holder of the resource knows how it should be
routed
!
• The Routing Policy Specification Language (RPSL)
originates from a RIPE Document
• Shares attributes with the RIPE Database
10
11. Challenges for the RR
• Accuracy and completeness
• Not every Routing Registry is linked directly to an
Internet Registry
• Online verification of the resource holder is needed
• Different authorisation methods
• Mirrors are not always up to date
11
14. RIPE Database
• Public internet resource and routing registry database
• All internet resources (IPv4, IPv6, AS numbers) are
registered
• Provides contact information
• It is also the RIPE Routing Registry with routing policy
information
14
15. RIPE Database Objects
• inetnum = IPv4 address range
• inet6num = IPv6 address range
• aut-num = AS number
• route, route6 = address range announced by an
AS number
15
16. Contact Info for inet6num object 16
person: John Doe
nic-hdl: JD1-RIPE!
address: Sesame Street 1!
phone: +1 555 0101!
email: john@xmpl.org!
mnt-by: RED-MNT
inet6num: 2001:db8::/32
org: ORG-BB2-RIPE!
admin-c: LA789-RIPE!
tech-c: LA789-RIPE!
!
mnt-by: RIPE-NCC-HM-MNT!
admin-c: JD1-RIPE
22. Exercise 1: route Object
• Group A
• Create a route object for your IPv4 allocation
• List your AS Number as the origin
!
• Group B
• Create a route6 object for your IPv6 allocation
• List your AS Number as the origin
22
25. Routing Policy
• A routing policy describes how a network works:
• Who do you connect with
• Which prefixes or routes do you announce
• Which routes do you accept from others
• What are your preferences
!
• In your router, this is your BGP configuration
• Neighbours
• route-maps
• localpref
25
26. Routing Policy Specification Language
!
• Language used by the IRRs
• Not vendor specific
• Documented in RFC 2622 and 2650
• Can be translated into router configuration
26
27. Objects Involved
• route or route6 object
• Connects a prefix to an origin AS
• aut-num object
• Registration record of an AS Number
• Contains the routing policy
• Sets
• Objects can be grouped in sets, i.e. as-set, route-set
• Keywords
• “ANY” matches every route
27
28. Notation
• AS Numbers are written as ASxxx
• Prefixes are written in CIDR notation
• 193.0.4.0/24
• Any value can be replaced by a list of values of the
same type
• AS1 can be replaced by “AS1 AS2 AS3”
• You can reference a set instead of a value
• “...announce AS1” or “...announce as-myname”
28
29. Traffic Direction 29
aut-num: AS1
AS2AS1
import: from AS2 accept AS2
!
!
export: to AS2 announce AS1
AS1 accepts prefixes from AS2 that originate in AS2.
Outbound traffic for AS2 can go towards AS2
AS1 announces prefixes (originating in AS1) to AS2.
Incoming traffic for AS1 can flow from AS2
announcements
traffic
30. 3 scenarios: 1. You are downstream 30
Internet
AS1
AS2
aut-num: AS1!
import: from AS2 accept ANY!
export: to AS2 announce AS1
Transit provider
You
31. 3 scenarios: 2. You are upstream 31
Internet
AS1
AS3
aut-num: AS1!
import: from AS3 accept AS3!
export: to AS3 announce ANY
Downstream customer
You
32. 3 scenarios: 3.Peering 32
Internet
AS1AS4
aut-num: AS1!
import: from AS4 accept AS4!
export: to AS4 announce AS1
Peer You
33. 3 scenarios: Summary 33
Internet
AS1
AS2
aut-num: AS1!
import: from AS2 accept ANY!
export: to AS2 announce AS1 AS3!
import: from AS3 accept AS3!
export: to AS3 announce ANY!
import: from AS4 accept AS4!
export: to AS4 announce AS1 AS3
Transit
provider
You
AS3
AS4
!
Peer
Downstream
34. Building an aut-num object 34
aut-num: AS2 aut-num: AS1 aut-num: AS3
AS1
AS2 AS3
Internet
import: from AS1 accept AS1 export: to AS2
import: from AS3
accept ANY
import: from AS2
accept AS2
export: to AS3 announce AS1
export: to AS1 announce ANY
import: from AS1 accept AS1
announce AS1
export: to AS1 announce AS2
35. IPv6 in the Routing Registry 35
mp-import: afi ipv6.unicast from AS201 accept AS201!
mp-export: afi ipv6.unicast to AS20 announce ANY
• RPSL is older than IPv6, the default is IPv4
• IPv6 was added later using a different syntax
• You have to specify that it’s IPv6
38. Modifying Your aut-num Object 38
• Take the scenario as presented:
ASx
(you)
AS 101
(transit)
AS107
(backup transit)
• In the TEST database update your AS, adding import and
export attributes to describe your policy towards these
neighbors
41. Example Routing Policy 41
aut-num:! ! AS99!
as-name:! ! SMALL-ISP-EU!
descr:! ! ! My network!
remark:!! ! *** Transit via 101 ***!
import:!! ! from AS101 accept ANY!
export:!! ! to AS101 announce AS99 AS201 AS202!
remark:!! ! *** Transit via 102 ***!
import:!! ! from AS102 accept ANY!
export:!! ! to AS102 announce AS99 AS201 AS202!
remark:!! ! *** AS201 is a customer ***!
import:!! ! from AS201 accept AS201!
export:!! ! to AS201 announce ANY!
remark:!! ! *** AS202 is a customer ***!
import:!! ! from AS202 accept AS202!
export:!! ! to AS201 announce ANY
42. Using AS-set
• Adding and removing customers can become time
consuming
• Create a set to list them all at once
42
as-set:!! AS-SMALLISP!
descr:! ! Customers’ ASNs of a small ISP!
members:! AS201!
members:! AS202
• And use that to describe your policy
export:!! to AS101 announce AS-SMALLISP!
export:!! to AS102 announce AS-SMALLISP
43. Using Keywords for AS-sets 43
• peerAS means
• from AS5 accept AS5
• from AS7 accept AS7
• from AS8 accept AS8
as-set: AS4:AS-CUSTOMERS!
members: AS7, AS5, AS8
aut-num: AS4!
export: to AS3 announce AS4 AS4:AS-customers!
export: to AS4:AS-CUSTOMERS announce ANY!
import: from AS4:AS-CUSTOMERS accept PeerAS!
44. Indicating Your Preferences 44
• BGP uses “localpref” to influence which received routes
you want to prefer
• In RPSL you can use the “pref” action on your import
attributes
• Important: lower value means more preferred!
import:!! from AS101 action pref=20;
! ! ! ! accept ANY!
import:!! from AS102 action pref=30;
! ! ! ! accept ANY
45. Describing AS Path Prepending 45
• AS path prepending is used to influence routing, both
inbound and outbound
• Prepending can also be notated in RPSL using another
action statement:
export:! ! to AS102 action aspath.prepend
AS99
(you)
AS99 AS99
AS 102
(transit)
AS99
(you)
AS 101
(transit)
some AS
(AS99, AS99); announce AS-SMALLISP!
46. An aut-num object (second example) 46
aut-num: AS5 aut-num: AS1 aut-num: AS4
AS1
AS5 AS4
Internet
import: from AS1 accept AS1
export: to AS5
action aspath.prepend (AS1, AS1);
announce AS1
import: from AS4
accept ANY
export: to AS4 announce AS1
import: from AS5
accept ANY
export: to AS1 announce ANY
import: from AS1 accept AS1
announce AS1
export: to AS1 announce ANY
action pref=80;
action pref=90;
import: from AS5 action pref=70
accept AS5
48. Modifying Your aut-num Object 48
• Take the scenario as presented:
• In the TEST database update your AS, adding import and
export attributes to describe your policy towards these
neighbors
ASx
(you)
AS 201
(customer)
AS 101
(transit)
AS601
(peer)
AS107
(backup transit)
50. MED 50
• Multiple Exit Discriminator
• differentiates connections to same peer
• “which inbound connection do I prefer?”
• doesn’t go beyond neighbour
• Local Pref has precedence over MED
• to honor your neighbor’s MED:
• don’t set different prefs
51. MED, route-sets 51
export: ! to AS4!
!! ! 10.0.0.4 at 10.0.0.1!
!! ! action med=1000;!
!!announce AS99!
export: ! to AS4!
!! ! 10.0.0.5 at 10.0.0.2!
!! ! action med=2000;!
!!announce AS99!
export: ! to AS4!
!! ! 10.0.0.4 at 10.0.0.1!
!! ! action med=1000;!
!!announce AS99!
export: ! to AS4!
!! ! 10.0.0.5 at 10.0.0.2!
!! ! action med=2000;!
!!announce AS99
AS99
(you)
AS 4
10.0.0.410.0.0.1
10.0.0.2 10.0.0.5
52. Communities 52
• Optional tags
• Can go through many peers
• Can be used for advanced filtering
• Not a routing parameter
• Enables customers to control their own routing policy
• Publish your communities, and what you do with them
• Filter incoming announcements accordingly
53. Communities: setting them 53
• Set a community:
import:! ! from AS6 !
action community = { 99:100 }; !
accept AS6
• Append a community:
import:! ! from AS7 !
action community.append(99:51); !
accept AS7
export:! ! to AS3 !
action community .= { 99:100 }; !
announce ANY
• Delete a community:
import:! ! from AS201 action community.delete
! ! ! ! (99:100); accept AS201!
54. Communities: filtering 54
import:! ! from AS21 !
accept AS6 AND !
community.contains = (21:32)
import:! ! from AS17 !
accept community(68:2)
import:! ! from AS1:AS-CUSTOMERS!
accept PeerAS AND!
community.contains (202:3)
export:! ! to AS3!
announce AS1:AS-CUST AND!
community == {1:113}!
export:! ! to AS1:AS-PEERS !
announce ANY AND!
community.contains (1:75)!
55. AS Path Regular Expression 55
• You can use regular expressions in your filters
• They are always enclosed in “< >”
import: from AS201 accept <^AS201+$>
• Uses the standard posix notation:
• “^” start of path
• “$” end of path
• “*” zero or more
• “+” one or more
• “?” zero or one
56. Literal Prefixes 56
• Instead of AS Numbers you can use prefixes:
import: from AS2121 accept {193.0.24.0/21}
• Operators can be used to define ranges:
• “^-” all more specifics excluding the prefix itself
• “^+” all more specifics including the prefix itself
• “^n” all routes of length n in this prefix
• “^n-m” all routes of length n to length m
57. Using a route-set 57
• Groups literal prefixes
• Can include other route-sets and even ASNs
• And use that to describe/simplify your policy
route-set:!rs-bar!
descr:! ! All ASNs of a small ISP!
members:! 5.0.0.0/8^+, 30.0.0.0/8^24-32!
members:! rs-foo^+!
members:! AS2
export:!! to AS101 announce RS-BAR
58. Default Routes 58
• Next to import and export there can also be a default line to
describe your default policy
• Instead of all routes, you can also announce a default route
export:!! to AS99 announce AS201!
import:!! from AS202 accept AS202!
export:!! to AS202 announce AS201!
default:! to AS99 action pref=150
export:!! to AS201 announce {0.0.0.0/0}
59. The Simplified Object 59
aut-num:! ! AS99!
as-name:! ! SMALL-ISP-EU!
descr:!! ! My network!
remark:!! ! *** Announcements are grouped ***!
import:!! ! from AS101 accept ANY!
export:!! ! to AS101 announce AS-SMALLISP!
import:!! ! from AS102 accept ANY!
export:!! ! to AS102 announce AS-SMALLISP!
remark:!! ! *** My Customers are grouped ***!
import:!! ! from AS99:Customers accept PEERAS!
export:!! ! to AS99:Customers announce ANY
62. A Look at the Real World 62
• Have a look at AS3333 in the RIPE Database
• Find out if they have any “customer” ASNs
• Which prefixes would you accept from AS3333 if it was
your customer?
• Remember to use the real database!
!
• Optionally: verify the results using the tools at
http://stat.ripe.net
65. Making Life Easier 65
• There are a lot of tools around that use information in the
Routing Registry
• Some can generate “complete” router configurations like
the IRRToolset
• Most are open source tools
• You can modify them to your needs
• Some are not very well maintained
66. Getting the Complete Picture 66
• Automation relies on the IRR being complete
• Not all resources are registered in an IRR
• Not all information is correct
• Check your output before using it
• Be prepared to make manual overrides
!
• Tools:
• IRRToolkit (in C++)
• RPSLtool (perl)
• whois -h filtergen.level3.net RIPE::ASxxxx
67. RIPEstat RRC 67
• You can compare the Routing Registry and the internet
routing table using http://stat.ripe.net
70. What is the purpose of Certification? 70
• To be able to answer the question:
• Is that ASN authorised to originate that address range?
71. Why RPKI? 71
• Why yet another system?
• Lots of Routing Registries
• Not all mirroring each other
• Different levels of trustworthiness and authentication
• RPKI replaces RR or lives side by side?
• Side by side: different advantages
• Security, almost real time, simple interface: RPKI
• More information in: RR
72. The Advantages of RPKI 72
• Usable toolset
• No installation required
• Easy to configure manual overrides
• Tight integration with routers
• Supported routers have awareness of RPKI validity states
73. Certificates 73
• RIPE NCC issues digital certificates
• To LIRs only (more info coming soon!)
• Upon request
!
• Certificate lists all resources held by the member
74. Which Resources Are Certified? 74
• Everything for which we are 100% sure who the owner is:
• Provider Aggregatable (PA) IP addresses
• Provider Independent (PI) IP addresses marked as
“infrastructure” of the LIR
!
• Other resources will be added soon!
• PI addresses for which we have a contract
• ERX resources
75. RPKI: Chain of Trust 75
• RPKI system:
• RIPE NCC holds self-signed root certificate for all resources
they have in the registry
• Signed by the root’s private key
• The root certificate is used to sign all certificates for
members listing their resources
• Signed by the root’s private key
76. ROA 76
• Route Origin Authorisation
• LIRs can use their certificate to create a ROA for each of
their resources (address ranges)
• ROA states:
• Address range
• Which AS number this is announced from (freely chosen)
• Maximum length (freely chosen)
• You can have multiple ROAs for an IP range
• ROAs can overlap
77. Examples with ROAs (1) 77
193.0.24.0/21
193.0.24.0/22 193.0.30.0/23
193.0.24.0/21
AS2121
ROA
Max Length: _
✖✖
78. Examples with ROAs (2) 78
193.0.24.0/23 193.0.30.6/23
193.0.24.0/21
AS2121
ROA
Max Length: /23
193.0.24.0/21
193.0.24.0/22
193.0.26.0/23
193.0.28.0/22
193.0.28.0/23
89. Validator 89
• The validator of the client can access RIPE NCC’s
Repository with all the certificates, public keys, ROAs
• It downloads everything and then performs validation,
checking whether the certificates and ROAs are valid
• Then it constructs a list of valid ROAs, which is its
“validated cache”
90. Validator 90
Validated cache
Validated ROAs only
Validator
at the Relying Party’s site
RIPE NCC’s Repository
ROA
AS
Certificate
Certificates
ROAs
ROA
ROA
ROA
91. Invalid ROAs 91
• Invalid ROAs are simply not included in the list of valid
ROAs when the validator of the client computes them
• Reasons for a ROA to be invalid
• The signing certificate or key pair has expired or has been
revoked
• It does not validate back to a configured trust anchor
• The LIR’s resource has been returned to the RIPE NCC
92. Modifying the Validated Cache 92
• The RIPE NCC Validator allows you to manually override
the validation process
• Adding an ignore filter will ignore all ROAs for a given prefix
• The end result is the validation state will be “unknown”
• Creating a whitelist entry for a prefix and ASN will locally
create a valid ROA
• The end result is the validation state becomes “valid”
93. Comparing BGP Announcement 93
• valid
• there is a ROA in the validated cache that matches the
BGP announcement of the peer. Size matches too
• unknown
• There is no ROA for that prefix in the cache
• invalid
• There is a ROA for the prefix, but for a different AS
• Or the size doesn’t match
94. Invalid ROA vs. Invalid Announcement 94
• Invalid ROA:
• The ROA in the repository cannot be validated by the
client (ISP) so it is not included in the validated cache
!
• Invalid BGP announcement:
• There is a ROA in the validated cache for that prefix but
for a different AS
• Or the max. length doesn’t match
• Remember: If no ROA in cache -> announcement unknown!
95. Router 95
• The Relying Party’s router can connect and download the
cache from the validator
• Router can then compare any BGP announcements to
the list of valid ROAs in the validated cache
96. You Are In Control 96
• As an announcer/LIR:
• You choose if you want certification
• You choose if you want to create ROAs
• You can choose max. length and AS
• As a Relying Party
• You can choose if you use the validator
• You can choose to make any routing decisions based on
the results of the BGP Verification (valid/invalid/unknown)
101. Exporting the Validated Cache 101
• Router sessions
• Validator listens on 8282 for RPKI-RTR Protocol
• Routers can connect and download the cache
• Export function
• Allows you to download a CSV with the cache
• Can be integrated with your internal workflow
• Use for statistics or spotting anomalies
102. RPKI Support of Routers 102
• The RPKI-RTR Protocol is an IETF standard
• All router vendors can implement it
• Production Cisco support
• ASR1000, 7600, ASR903, ASR901 in releases 15.2(1)S or
X 3.5
• Cisco Early Field Trial (EFT)
• ASR9000, CRS1, CRS3, c12K (IOS-XR)
• Juniper has support since version 12.2
• Quagga has support through BGP-ERX
103. Public Testbeds 103
• Cisco (hosted by the RIPE NCC):
• Telnet to rpki-rtr.ripe.net
• User: ripe, no password
• Juniper (hosted by Kaia Global Networks)
• Telnet to 193.34.50.25 or 193.34.50.26
• User: rpki, password: testbed
!
• (http://www.ripe.net/certification/tools-and-resources)
106. IPv4 Allocation Transfers 106
• Only between RIPE NCC Members
• Allocation is allowed to be in use
• Minimum size is /22
• Must qualify for allocation
• 80% usage criteria applies
• Evaluated by RIPE NCC
107. Types of Transfers 107
• PA between RIPE NCC members
• Due to merger or acquisition
• From legacy space
108. Transfers, how 108
• IPv4 RIPE NCC Listing Service
• Accessible from LIR Portal Account
• Brokers
• Listed on RIPE NCC website
• NOT endorsed by RIPE NCC
• Signed an agreement to conform to RIPE policies