IGP Extensions for Intra-Domain SAV

Requirements for intra-domain Source Address Validation (SAV) Mechanisms are described in . The most important requirements include: Accurate Validation, Fast Convergence of SAV table/rules on dynamic routing changes, and Backward Compatible (i.e., Working in Incremental/Partial Deployment). This document proposes IGP (i.e., OSPF and IS-IS) extensions for Intra-Domain SAV to meet these requirements.

This section briefs SAV table and its usage, and then introduces one area (i.e., intra-area) SAV and multiple areas (i.e., inter-area) SAV.

Every node (i.e., IGP control plane on the node) in a Autonomous System (AS) builds and maintains its own Source Address Validation (SAV) Table based on its Link-State Database (LSDB). The format of a SAV table is shown in .

|S-prefix-2|Interface-b | ==> |D-prefix-2 |Out-interface-b | ==> ^ +----------+------------+ ^ +-----------+----------------+ ^ | ... | ... | | +----------+------------+ | +-----------+----------------+ | | |S-prefix-n|Interface-x | | |D-prefix-n |Out-interface-x | | | +----------+------------+ | +-----------+----------------+ | | Format of SAV Table | FIB | | | | Packet in forward Packet Packet out if source address and receiving interface of Packet in SAV Table]]> When there is a shortest path from source prefix S-prefix-i to a destination through node N and interface Interface-j of node N, the SAV table of node N has a row containing S-prefix-i as Source Prefix and Interface-j as Incoming Interface. For example, the first row in the SAV table of node N contains S-prefix-1 as Source Address and Interface-a as Incoming Interface. This row indicates that there is a shortest path from S-prefix-1 to a destination through node N and Interface-a of node N. The SAV table is sent to the data plane and used to validate the source address of a packet. When receiving a packet from an interface, the node validates the packet using its SAV table. If the source address of the packet and the receiving/incoming interface are in the SAV table (i.e., there is one row in the SAV table containing the source address and the receiving/incoming interface), the packet is forwarded according to the FIB and destination address of the packet as shown in the figure; otherwise (i.e., there is no row in the SAV table containing the source address and the receiving/incoming interface), the packet is blocked or dropped.

This section introduces a method for a node to build its SAV table in a special case where an AS has only one area or SAV is for only one area. When every routing/forwarding path in an AS is symmetric (i.e., every path has the same cost in both directions), every node in the AS builds and maintains its SAV table using its RIB/FIB. The node can determine whether every path is symmetric by checking its LSDB. If every link in its LSDB is symmetric (i.e., has the same metric or cost in both directions), then every path is symmetric; otherwise (i.e., there is an asymmetric link, its metric/cost in one direction is different from the one in the other/reverse direction), there are some asymmetric paths. The node builds its SAV table using the RIB/FIB by including a row in its SAV table for each prefix with a next hop interface in its RIB/FIB. The row contains the prefix and the interface in the Source Prefix and Incoming Interface columns respectively. When there is a routing/forwarding path which is not symmetric, every node X builds its SAV table in the following steps: Builds reverse shortest path tree (RSPT). Node X computes/builds a shortest path tree from node X to the other nodes using the link metric or cost of each link in the reverse direction. Builds reverse routing table (RRT) using RSPT. When node X finds a shortest path from node X to node Y with a next hop interface in its RSPT, node X adds an entry for each prefix attached to Y into its RRT. The entry has the prefix as the destination and the next hop interface as the next hop. Builds SAV table using RRT. Node X includes a row in its SAV table for each prefix with a next hop interface in its RRT. The row contains the prefix and the interface in the Source Prefix and Incoming Interface columns respectively. There are a few options below for the scope of the prefixes to be validated. The prefixes attached to every node. The prefixes attached to each ASBR and ABR. The prefixes indicated/configured on any node. The method above builds the SAV table for option 1. For option 2, we consider only ASBR and ABR Y in step 2. Thus the RRT contains only the prefixes attached to ASBRs and ABRs. So does the SAV table. For option 3, we consider only the prefixes attached to node Y and indicated/configured by node Y in step 2. Thus the RRT contains only these prefixes. So does the SAV table.

This section introduces a method for a node to build its SAV table in a general case where an AS has multiple areas and SAV is for all the areas. The method is based on the one described in . For any area A, every node X in A builds its SAV table using the following steps: Gets area shortest path tree (ASPT). The ASPT is a tree from node X as root to all the other nodes in area A. If every link in area A is symmetric, the ASPT is the SPT built by node X for its RIB, which is reused; otherwise (i.e., there is asymmetric link in area A), the ASPT is a RSPT from node X as root to all the other nodes in area A. Node X computes/builds the RSPT as described in . Extends ASPT. For each leaf node L of ASPT, node X attaches node L of ASPT every prefix of node L if the cost from the prefix to L is minimal. If every link in area A is symmetric and every path between any ABR and a summary prefix/address from the ABR is symmetric, the extended ASPT is the SPT with the prefixes of each node in area A built by node X for its RIB, which is reused. Builds reverse routing table (RRT) using extended ASPT. When node X finds a shortest path from node X to node Y with a next hop interface in its extended ASPT, node X adds an entry for each prefix attached to Y into its RRT. The entry has the prefix as the destination and the next hop interface as the next hop. Builds SAV table using RRT. Node X includes a row in its SAV table for each prefix with a next hop interface in its RRT. The row contains the prefix and the interface in the Source Prefix and Incoming Interface columns respectively. The method above builds the SAV table for option 1. For option 2, we consider only ASBR and ABR Y in step 3. Thus the RRT contains only the prefixes attached to ASBRs and ABRs. So does the SAV table. For option 3, we consider only the prefixes attached to node Y and indicated/configured by node Y in step 3. Thus the RRT contains only these prefixes. So does the SAV table.

This section describes extensions to OSPFv2, OSPFv3 and IS-IS for SAV. The extensions include: A new S-Flag (SAV Prefix Flag) of 1 bit indicating a prefix to be validated when option 3 described in is selected. A new Sub-TLV, called Reverse Cost to Prefix Sub-TLV, for ABR to advertise the cost of the shortest path from the prefix to the ABR when the path between the ABR and the prefix is not symmetric (i.e., the cost of the shortest path from the ABR to the prefix is different from that of the path from the prefix to the ABR).

defines the OSPFv2 Extended Prefix TLV to advertise additional attributes associated with the prefix. A new flag of one bit in Flags field of the TLV is defined below: Set when the prefix is configured for SAV (i.e., to be validated as a Source Address of a packet).

defines the OSPFv2 Extended Prefix TLV. A new OSPFv2 Reverse Cost to Prefix Sub-TLV is defined to be included in this TLV with Route Type 3 (Inter-Area). It has the following format:

defines Intra-Area-Prefix TLV and External-Prefix TLV to advertise additional attributes associated with the prefix. A new Sub-TLV called Prefix Attribute Flags Sub-TLV is defined to be included in these two TLVs. It has the following format:

One flag of 1-bit in Prefix Attribute Flags field is defined below: Set when the prefix is configured for SAV (i.e., to be validated as a Source Address of a packet).

defines the Intra-Area-Prefix TLV. A new OSPFv3 Reverse Cost to Prefix Sub-TLV is defined to be included in this TLV. It has the following format:

defines the Prefix Attribute Flags Sub-TLV to advertise additional IPv4 and IPv6 prefix attributes in TLV 135 (Extended IP Reachability), 235 (MT IP Reach), 236 (IPv6 IP Reach) and 237 (MT IPv6 IP Reach). A new one bit flag in the Sub-TLV is defined below: Set when the prefix is configured for SAV (i.e., to be validated as a Source Address of a packet).

A new IS-IS Reverse Cost to Prefix Sub-TLV is defined for an ABR (i. e., level 2/1 router) to include it in TLV 135, 235, 236 and 237 for the prefix. It has the following format:

TBD.

Under "OSPFv2 Extended Prefix TLV Flags registry", IANA is requested to assign a codepoint for SAV Prefix Flag as follows:

+===========+=========================+==================+ | Value | Description | Reference | +===========+=========================+==================+ | TBD1 | Reverse Cost to Prefix | This document | +-----------+-------------------------+------------------+

Under "OSPFv3 Extended-LSA Sub-TLVs registry" as defined in , IANA is requested to assign a registry value for Reverse Cost to Prefix Sub-TLV as follows:

+===========+=========================+==================+ | Value | Description | Reference | +===========+=========================+==================+ | TBD2 | Prefix Attribute Flags | This document | +-----------+-------------------------+------------------+ | TBD3 | Reverse Cost to Prefix | This document | +-----------+-------------------------+------------------+

Under "IS-IS Bit Values for Prefix Attribute Flags Sub-TLV", IANA is requested to assign a codepoint for SAV Prefix Flag as follows:

+=====+========================+=============+ |Bit #|Name |Reference | +=====+========================+=============+ | 5 |SAV Prefix Flag (S-flag)|This document| +-----+------------------------+-------------+ Under "IS-IS Sub-TLVs for TLVs Advertising Prefix Reachability", IANA is requested to assign a codepoint for Reverse Cost to Prefix Sub-TLV as follows:

+===========================+==+===+===+===+===+===+===+=============+ |Type|Description |27|126|127|135|235|236|237|reference | +====+======================+==+===+===+===+===+===+===+=============+ |TBD3|Reverse Cost to Prefix|n | n | n | y | y | y | y |This document| +----+----------------------+--+---+---+---+---+---+---+-------------+

The authors would like to thank Joel Halpern for the valuable comments and suggestions on this draft..