Fundamental Capabilities
1. BGP Over QUIC
1.1 BGP Over QUIC
Publication URL: https://datatracker.ietf.org/doc/html/draft-retana-idr-bgp-quic
Introduction:
This document defines the use of QUIC as BGP transport protocol.
1.2 Use of Streams in BGP over QUIC
Publication URL: https://datatracker.ietf.org/doc/html/draft-retana-idr-bgp-quic-stream
Introduction:
This document specifies the use of QUIC Streams to support multiple BGP sessions over one connection in order to achieve high resiliency.
Reference
BGP over QUIC demo: Github: RustyBGP over QUIC
Scalability
1. IGP
1.1 Dynamic Flooding on Dense Graphs
Publication URL: https://datatracker.ietf.org/doc/html/draft-ietf-lsr-dynamic-flooding
Introduction:
Routing with link state protocols in dense network topologies can result in sub-optimal convergence times due to the overhead associated with flooding. This can be addressed by decreasing the flooding topology so that it is less dense.
This document discusses the problem in some depth and an architectural solution. Specific protocol changes for IS-IS, OSPFv2, and OSPFv3 are described in this document.
1.2 Flooding Topology Computation Algorithm
Publication URL: https://datatracker.ietf.org/doc/html/draft-cc-lsr-flooding-reduction
Introduction:
This document proposes an algorithm for a node to compute a flooding topology, which is a subgraph of the complete topology per underline physical network. When every node in an area automatically calculates a flooding topology by using a same algorithm and floods the link states using the flooding topology, the amount of flooding traffic in the network is greatly reduced. This would reduce convergence time with a more stable and optimized routing environment.
1.3 Flooding Topology Minimum Degree Algorithm
Publication URL: https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flooding-topo-min-degree
Introduction:
This document proposes an algorithm for a node to compute a flooding topology, which is a subgraph of the complete topology per underline physical network. When every node in an area automatically calculates a flooding topology by using a same algorithm and floods the link states using the flooding topology, the amount of flooding traffic in the network is greatly reduced. This would reduce convergence time with a more stable and optimized routing.
2. BGP
2.1 Use of BGP for Routing in Large-Scale Data Centers
Publication URL: https://datatracker.ietf.org/doc/html/rfc7938
Introduction:
Some network operators build and operate data centers that support over one hundred thousand servers. In this document, such data centers are referred to as “large-scale” to differentiate them from smaller infrastructures. Environments of this scale have a unique set of network requirements with an emphasis on operational simplicity and network stability. This document summarizes operational experience in designing and operating large-scale data centers using BGP as the only routing protocol. The intent is to report on a proven and stable routing design that could be leveraged by others in the industry.
2.2 BGP Link-State Shortest Path First (SPF) Routing
Publication URL: https://datatracker.ietf.org/doc/html/draft-ietf-lsvr-bgp-spf
Introduction:
Many Massively Scaled Data Centers (MSDCs) have converged on simplified layer 3 routing. Furthermore, requirements for operational simplicity have led many of these MSDCs to converge on BGP as their single routing protocol for both their fabric routing and their Data Center Interconnect (DCI) routing. This document describes extensions to BGP to use BGP Link-State distribution and the Shortest Path First (SPF) algorithm used by Internal Gateway Protocols (IGPs) such as OSPF. In doing this, it allows BGP to be efficiently used as both the underlay protocol and the overlay protocol in MSDCs.
2.3 Requirements and Considerations in BGP Peer Auto-Configuration
Publication URL: https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-autoconf-considerations
Introduction:
This draft is an exploration of the requirements, the alternatives, and trade-offs in BGP peer auto-discovery at various layers in the stack. It is based on discussions in the IDR Working Group BGP Autoconf Design Team. The current target environment is the datacenter.
This document is not intended to become an RFC.
3. RIFT
3.1 RIFT: Routing in Fat Trees
Publication URL: https://datatracker.ietf.org/doc/html/draft-ietf-rift-rift
Introduction:
This document defines a specialized, dynamic routing protocol for Clos and fat-tree network topologies optimized towards minimization of control plane state as well as configuration and operational complexity.
Maintenability
1. BMP
1.1 BGP Monitoring Protocol (BMP)
Publication URL: https://datatracker.ietf.org/doc/html/rfc7854
Introduction:
This document defines the BGP Monitoring Protocol (BMP), which can be used to monitor BGP sessions. BMP is intended to provide a convenient interface for obtaining route views. Prior to the introduction of BMP, screen scraping was the most commonly used approach to obtaining such views. The design goals are to keep BMP simple, useful, easily implemented, and minimally service affecting. BMP is not suitable for use as a routing protocol.
1.2 Support for Adj-RIB-Out in the BGP Monitoring Protocol (BMP)
Publication URL: https://datatracker.ietf.org/doc/html/rfc8671
Introduction:
The BGP Monitoring Protocol (BMP) only defines access to the Adj-RIB-In Routing Information Bases (RIBs). This document updates BMP (RFC7854) by adding access to the Adj-RIB-Out RIBs. It also adds a new flag to the peer header to distinguish between Adj-RIB-In and Adj-RIB-Out.
1.3 BGP Route Policy and Attribute Trace Using BMP
Publication URL: https://datatracker.ietf.org/doc/html/draft-xu-grow-bmp-route-policy-attr-trace
Introduction:
The generation of BGP adj-rib-in, local-rib or adj-rib-out comes from BGP route exchange and route policy processing. BGP Monitoring Protocol (BMP) provides the monitoring of BGP adj-rib-in (RFC7854), BGP local-rib [I-D.ietf-grow-bmp-local-rib] and BGP adj-rib-out [I-D.ietf-grow-bmp-adj-rib-out]. By monitoring these BGP RIB’s the full state of the network is visible, but how route-policies affect the route propagation or changes BGP attributes is still not. This document describes a method of using BMP to record the trace data on how BGP routes are (not) changed under the process of route policies.
1.4 VPN Traffic Engineering Using BMP
Publication URL: https://datatracker.ietf.org/doc/html/draft-gu-grow-bmp-vpn-te
Introduction:
The BGP Monitoring Protocol (BMP) is designed to monitor BGP running status, such as BGP peer relationship establishment and termination and route updates. This document provides a traffic engineering (TE) method in the VPN (Virtual Private Network) scenario using BMP.
1.5 VPN Label Monitoring Using BMP
Publication URL: https://datatracker.ietf.org/doc/html/draft-gu-grow-bmp-vpn-label
Introduction:
The BGP Monitoring Protocol (BMP) is designed to monitor BGP running status, such as BGP peer relationship establishment and termination and route updates. This document provides a method of collecting the VPN label using BMP, as well as an implementation example.
1.6 Monitoring BGP Capabilities Using BMP
Publication URL: https://datatracker.ietf.org/doc/html/draft-zhuang-grow-monitoring-bgp-capabilities
Introduction:
The BGP Monitoring Protocol (BMP) (RFC7854) is designed to monitor BGP (RFC4271) running status, such as BGP peer relationship establishment and termination and route updates. This document provides a use case that the BMP station can get all BGP capability information of the monitored network device via BMP.
1.7 TLV support for BMP Route Monitoring and Peer Down Messages
Publication URL: https://datatracker.ietf.org/doc/html/draft-ietf-grow-bmp-tlv
Introduction:
Most of the message types defined by the BGP Monitoring Protocol (BMP) do provision for optional trailing data. However, Route Monitoring messages (to provide a snapshot of the monitored Routing Information Base) and Peer Down messages (to indicate that a peering session was terminated) do not. Supporting optional data in TLV format across all BMP message types allows for an homogeneous and extensible surface that would be useful for the most different use- cases that need to convey additional data to a BMP station. While it is not intended for this document to cover any specific utilization scenario, it defines a simple way to support optional TLV data in all message types.
1.8 BMP Extension for Path Status TLV
Publication URL: https://datatracker.ietf.org/doc/html/draft-cppy-grow-bmp-path-marking-tlv
Introduction:
The BGP Monitoring Protocol (BMP) provides an interface for obtaining BGP Path information. BGP Path Information is conveyed within BMP Route Monitoring (RM) messages. This document proposes an extension to BMP to convey the status of a BGP path before and after being processed by the BGP best-path selection algorithm. This extension makes use of the TLV mechanims described in draft-ietf-grow-bmp-tlv [I-D.ietf-grow-bmp-tlv] and draft-lucente-grow-bmp-tlv-ebit [I-D.lucente-grow-bmp-tlv-ebit].
1.9 Support for Enterprise-specific TLVs in the BGP Monitoring Protocol
Publication URL: https://datatracker.ietf.org/doc/html/draft-lucente-grow-bmp-tlv-ebit
Introduction:
Message types defined by the BGP Monitoring Protocol (BMP) do provision for optional trailing data in TLV - Type, Length, Value - format; however the space for Type value is unique and governed by IANA. To allow the usage of vendor-specific TLVs, a mechanism to define per-vendor Type values is required. With this document we want to introduce an Enterprise Bit, or E-bit, for such purpose.
2. NMP
2.1 Network Monitoring Protocol (NMP)
Publication URL: https://datatracker.ietf.org/doc/html/draft-gu-network-monitoring-protocol
Introduction:
To evolve towards automated network OAM (Operations, administration and management), the monitoring of control plane protocols is a fundamental necessity. In this document, a network monitoring protocol (NMP) is proposed to provision the running status information of control plane protocols, e.g., IGP (Interior Gateway Protocol) and other protocols. By collecting the protocol monitoring data and reporting it to the NMP monitoring server in real-time, NMP can facilitate network troubleshooting. In this document, NMP for IGP troubleshooting are illustrated to showcase the necessity of NMP. IS-IS is used as the demonstration protocol, and the case of OSPF (Open Shortest Path First) and other control protocols will be elaborated in the future versions. The operations of NMP are described, and the NMP message types and message formats are defined in the document.
2.2 Network-wide Protocol Monitoring (NPM): Use Cases
Publication URL: https://datatracker.ietf.org/doc/html/draft-chen-npm-use-cases
Introduction:
As networks continue to scale, we need a coordinated effort for diagnosing control plane health issues in heterogeneous environments. Traditionally, operators developed internal solutions to address the identification and remediation of control plane health issues, but as networks increase in size, speed and dynamicity, new methods and techniques will be required.
This document highlights key network health issues, as well as network planning requirements, identified by leading network operators. It also provides an overview of current art and techniques that are used, but highlights key deficiencies and areas for improvement.
This document proposes a unified management framework for coordinating diagnostics of control plane problems and optimization of network design. Furthermore, it outlines requirements for collecting, storing and analyzing control plane data, to minimise or negate control plane problems that may significantly affect overall network performance and to optimize path/peering/policy planning for meeting application-specific demands.
2.3 Network Monitoring For IGP
Publication URL: https://datatracker.ietf.org/doc/html/draft-gu-opsawg-network-monitoring-igp
Introduction:
To evolve towards automated network OAM (Operations, administration and management), the monitoring of control plane protocols is a fundamental necessity. This document proposes network monitoring for IGP to facilitate troubleshooting by collecting the IGP monitoring data and reporting it to the network monitoring server in real-time. In this document, the operations of network monitoring for ISIS are described, and the corresponding network monitoring message types and message formats are defined.
3. PASP
3.1 Protocol Assisted Protocol (PASP)
Publication URL: https://datatracker.ietf.org/doc/html/draft-li-rtgwg-protocol-assisted-protocol
Introduction:
For routing protocol troubleshooting, different approaches exibit merits w.r.t. different situations. They can be generally divided into two categories, the distributive way and the centralized way. A very commonly used distributive approach is to log in possiblly all related devices one by one to check massive data via CLI. Such approach provides very detailed device information, however it requires operators with high NOC (Network Operation Center) experience and suffers from low troubleshooting efficiency and high cost. The centralized approach is realized by collecting data from devices via approaches, like the streaming Telemetry or BMP(BGP Monitoring Protocol) (RFC7854), for the centralized server to analyze all gathered data. Such approach allows a comprehensive view fo the whole network and facilitates automated troubleshooting, but is limited by the data collection boundary set by different management domains, as well as high network bandwidth and CPU computation costs.
This document proposes a semi-distributive and semi-centralized approach for fast routing protocol troubleshooting, localizing the target device and possibly the root cause, more precisely. It defines a new protocol, called the PAP (Protocol assisted Protocol), for devices to exchange protocol related information between each other in both active and on-demand manners. It allow devices to request specific information from other devices and receive replies to the requested data. It also allows actively transmission of information without request to inform other devices to better react w.r.t. network issues.
Security
1. SAVA
1.1 A Source Address Validation Architecture (SAVA) Testbed and Deployment Experience
Publication URL: https://datatracker.ietf.org/doc/html/rfc5210
Introduction:
Because the Internet forwards packets according to the IP destination address, packet forwarding typically takes place without inspection of the source address and malicious attacks have been launched using spoofed source addresses. In an effort to enhance the Internet with IP source address validation, a prototype implementation of the IP Source Address Validation Architecture (SAVA) was created and an evaluation was conducted on an IPv6 network. This document reports on the prototype implementation and the test results, as well as the lessons and insights gained from experimentation.
1.2 An RPKI and IPsec-based AS-to-AS Approach for Source Address Validation
Publication URL: https://datatracker.ietf.org/doc/html/draft-xu-risav/
Introduction:
This document presents RISAV, a protocol for establishing and using IPsec security between Autonomous Systems (ASes) using the RPKI identity system. In this protocol, the originating AS adds authenticating information to each outgoing packet at its Border Routers (ASBRs), and the receiving AS verifies and strips this information at its ASBRs. Packets that fail validation are dropped by the ASBR. RISAV achieves Source Address Validation among all participating ASes.
1.3 Control Plane of Inter-Domain Source Address Validation Architecture
Publication URL: https://datatracker.ietf.org/doc/html/draft-xu-savax-control/
Introduction:
Because the Internet forwards packets according to the IP destination address, packet forwarding typically takes place without inspection of the source address and malicious attacks have been launched using spoofed source addresses. The inter-domain source address validation architecture is an effort to enhance the Internet by using state machine to generate consistent tags. When communicating between two end hosts at different ADs of IPv6 network, tags will be added to the packets to identify the authenticity of the IPv6 source address.
This memo focus on the control plane of the SAVA-X mechanism.
1.4 Data Plane of Inter-Domain Source Address Validation Architecture
Publication URL: https://datatracker.ietf.org/doc/html/draft-xu-savax-data/
Introduction:
This memo focus on the data plane of the SAVA-X mechanism.
1.5 Communication Protocol Between the AD Control Server and the AD Edge Router of Inter-Domain Source Address Validation Architecture
Publication URL: https://datatracker.ietf.org/doc/html/draft-xu-savax-protocol/
Introduction:
This memo focus on the packet formats and processing flow of the SAVA-X mechanism.
2. SAVI
2.1 Source Address Validation Improvement (SAVI) Framework
Publication URL: https://datatracker.ietf.org/doc/html/rfc7039
Introduction:
Source Address Validation Improvement (SAVI) methods were developed to prevent nodes attached to the same IP link from spoofing each other’s IP addresses, so as to complement ingress filtering with finer-grained, standardized IP source address validation. This document is a framework document that describes and motivates the design of the SAVI methods. Particular SAVI methods are described in other documents.
2.2 Source Address Validation Improvement (SAVI) Solution for DHCP
Publication URL: https://datatracker.ietf.org/doc/html/rfc7513
Introduction:
This document specifies the procedure for creating a binding between a DHCPv4/DHCPv6-assigned IP address and a binding anchor on a Source Address Validation Improvement (SAVI) device. The bindings set up by this procedure are used to filter packets with forged source IP addresses. This mechanism complements BCP 38 (RFC 2827) ingress filtering, providing finer-grained source IP address validation.
2.3 Source Address Validation Improvement (SAVI) for Mixed Address Assignment Methods Scenario
Publication URL: https://datatracker.ietf.org/doc/html/rfc8074
Introduction:
In networks that use multiple techniques for address assignment, the spoofing of addresses assigned by each technique can be prevented using the appropriate Source Address Validation Improvement (SAVI) methods. This document reviews how multiple SAVI methods can coexist in a single SAVI device and how collisions are resolved when the same binding entry is discovered by two or more methods.
2.4 A SAVI Solution for WLAN
Publication URL: https://datatracker.ietf.org/doc/html/draft-bi-savi-wlan
Introduction:
This document describes a source address validation solution for WLAN enabling 802.11i or other security mechanisms. This mechanism snoops NDP and DHCP packets to bind IP address to MAC address, and relies on the security of MAC address guaranteed by 802.11i or other mechanisms to filter IP spoofing packets. It can work in the special situations described in the charter of SAVI(Source Address Validation Improvements) workgroup, such as multiple MAC addresses on one interface. This document describes three different deployment scenarios, with solutions for migration of binding entries when hosts move from one access point to another.
2.5 Problems and Requirements of Source Address Spoofing in Integrated Space and Terrestrial Networks
Publication URL: https://datatracker.ietf.org/doc/html/draft-jliu-istn-savi-requirement
Introduction:
This document presents the detailed analysis about the problems and requirements of dealing with the threat of source address spoofing in Integrated Space and Terrestrial Networks (ISTN). First, characteristics of ISTN that cause DDos are identified. Secondly, it analyzes the major reasons why existing terrestrial source address validation mechanism does not fit well for ISTN. Then, it outlines the major requirements for improvement on source address validation mechanism for ISTN.
3. SAVNET
WG link: https://datatracker.ietf.org/wg/savnet/about/
Mail Archive: https://mailarchive.ietf.org/arch/browse/savnet/
To subscribe: https://www.ietf.org/mailman/listinfo/savnet/
3.1 Source Address Validation in Intra-domain Networks (Intra-domain SAVNET) Gap Analysis, Problem Statement and Requirements
Publication URL: https://datatracker.ietf.org/doc/html/draft-li-savnet-intra-domain-problem-statement/
Introduction:
Source Address Validation in Intra-domain Networks (Intra-domain SAVNET) aims to make improvements to existing intra-domain Source Address Validation (SAV). This document provides the gap analysis of existing intra-domain SAV mechanisms, describes the fundamental problems, and defines the requirements for improvements.
3.2 Source Address Validation in Inter-domain Networks (Inter-domain SAVNET) Gap Analysis, Problem Statement, and Requirements
Publication URL: https://datatracker.ietf.org/doc/html/draft-wu-savnet-inter-domain-problem-statement/
Introduction:
Source Address Validation in Inter-domain Networks (Inter-domain SAVNET) focuses on narrowing the technical gaps of existing source address validation (SAV) mechanisms in inter-domain scenarios. This document provides a gap analysis of existing inter-domain SAV mechanisms, describes the problem statement based on the analysis results, and concludes the requirements for improving inter-domain SAV.
3.3 The Incentive Consideration for Defense Against Reflection Attacks
Publication URL: https://datatracker.ietf.org/doc/html/draft-qin-savnet-incentive/
Introduction:
Source address spoofing remains a significant challenge in today’s Internet. Although source address validation (SAV) mechanisms, such as ingress filtering [RFC2827], unicast Reverse Path Forwarding (uRPF) [RFC3704], and the Enhanced Feasible-Path Unicast Reverse Path Forwarding (EFP-uRPF) [RFC8704], have been proposed for a long time, some ASes have not deployed SAV due to the problems of existing SAV mechanism, such as inaccurate validation, misaligned incentive, or other overhead concerns. This document specifically explains the misaligned incentive problem of existing SAV mechanisms and clarifies the direct incentive that a new SAV mechanism should achieve.
3.4 Intra-domain Source Address Validation (SAVNET) Architecture
Publication URL: https://datatracker.ietf.org/doc/html/draft-li-savnet-intra-domain-architecture/
Introduction:
Intra-domain source address validation (SAV) plays an important role in defending against source address spoofing attacks in intra-domain networks. However, existing intra-domain SAV mechanisms have the problems of inaccurate validation, high operational overhead, and limited protection. To overcome these problems and improve intra-domain SAV, this document proposes an overall architecture of source address validation in intra-domain network (named as Intra-domain SAVNET). Intra-domain SAVNET discovers the real data-plane forwarding path via hop-by-hop message propagation and helps intra-domain routers generate accurate SAV tables.
3.5 Inter-domain Source Address Validation (SAVNET) Architecture
Publication URL: https://datatracker.ietf.org/doc/html/draft-wu-savnet-inter-domain-architecture/
Introduction:
Source address validation (SAV) plays a significant role in defending against various attacks based on source IP address spoofing. BCP84 [RFC3704][RFC8704] provides practical SAV mechanisms, i.e., uRPF-based approaches, for inter-domain scenarios. However, current uRPF-based SAV mechanisms have limitations in accuracy and incentive [draft-wu-savnet-inter-domain-problem-statement]. This document provides an architecture of inter-domain SAVNET which actively advertises AS paths to other ASes for generating accurate SAV rules and improving incentive.
3.6 Source Address Validation Using BGP UPDATEs, ASPA, and ROA (BAR-SAV)
Publication URL: https://datatracker.ietf.org/doc/html/draft-sriram-sidrops-bar-sav/
Introduction:
Designing an efficient source address validation (SAV) filter requires minimizing false positives (i.e., avoiding dropping legitimate traffic) while maintaining directionality (see RFC8704). This document advances the technology for SAV filter design through a method that makes use of BGP UPDATE messages, Autonomous System Provider Authorization (ASPA), and Route Origin Authorization (ROA). The proposed method’s name is abbreviated as BAR-SAV. BAR-SAV can be used by network operators to derive more robust SAV filters and thus improve network resilience.
3.7 Source Address Validation Table Abstraction and Application
Publication URL: https://datatracker.ietf.org/doc/html/draft-huang-savnet-sav-table/
Introduction:
Source address validation (SAV) table consists of SAV rules that are manually configured or automatically generated. The table will take effect in data plane for checking the validity of source addresses. SAV mechanisms may enable SAV tables in data plane using different methods (e.g., ACL or FIB), and these tables are suitable for different application scenarios. This document aims to provide a systematic view of existing SAV tables, which makes it convenient for engineers or operators to improve existing SAV mechanisms or properly apply SAV on routers. The document first examines existing forms of SAV tables and provides a unified abstraction. Then, four validation modes are concluded as well as suggestions for application scenarios. Finally, diversified actions for each validity state are introduced for compliance of different operation requirements.
3.8 Intra-domain SAVNET method
Publication URL: https://datatracker.ietf.org/doc/html/draft-lin-savnet-lsr-intra-domain-method/
Introduction:
This document proposes a method of Source Address Validation in Intra-domain, which can be applied to OSPF and IS-IS protocols. By extending IGP and adding the protocol calculation procedure, the SAV information can be accurately calculated to realize the source address verification.
3.9 Analysis of Source Address Validation Data Plane Performance
Publication URL: https://datatracker.ietf.org/doc/html/draft-li-savnet-dataplane-performance/
Introduction:
Source address validation (SAV) is one important way to mitigate source address spoofing attacks. However, there may be concern about whether the source address check action of the data plane would cause a great performance loss and even affect SAV deployment. This document provides an analysis of data plane implementation of SAV mechanisms, including the existing mechanisms and a new mechanism using independent SAV table. The data plane performances of different mechanisms are tested respectively.
3.10 SAVA-based Anti-DDoS Architecture
Publication URL: https://datatracker.ietf.org/doc/html/draft-cui-savnet-anti-ddos/
Introduction:
This document proposes the SAVA-based Anti-DDoS Architecture (SADA), which can efficiently detect, mitigate, and traceback Denial-of-Service (DDoS) attacks that spoof source addresses. The SADA consists of a distributed DDoS detection mechanism based on honeynets, a multi-stage DDoS mitigation mechanism, and a suspect-based DDoS traceback mechanism. By adopting the Source Address Validation Architecture (SAVA) of SAVNET and introducing the data plane and the control plane, the SADA makes minor changes to the SAVA while providing major benefits.