Internet-Draft Intra-domain SAVNET Architecture October 2022
Li, et al. Expires 27 April 2023 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-li-savnet-intra-domain-architecture-00
Published:
Intended Status:
Standards Track
Expires:
Authors:
D. Li
Tsinghua University
J. Wu
Tsinghua University
L. Qin
Tsinghua University
F. Gao
Zhongguancun Laboratory
N. Geng
Huawei
T. Zhou
Huawei

Intra-domain Source Address Validation (SAVNET) Architecture

Abstract

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.

Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 8174 [RFC8174].

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 27 April 2023.

▲

Table of Contents

1. Introduction

Source address validation (SAV) is important to mitigate source address spoofing and contribute to the Internet security. Source Address Validation Architecture (SAVA) [RFC5210] divides SAV into three checking levels, i.e., access-network SAV, intra-domain SAV, and inter-domain SAV. When an access network does not deploy SAV at the source (e.g., SAVI), intra-domain SAV helps block spoofed packets as close to the source as possible. However, existing intra-domain SAV mechanisms have the problems of inaccurate validation, high operational overhead, and limited protection[draft-li-savnet-intra-domain-problem-statement], resulting in legitimate packets being discarded or spoofed packets being permitted. To effectively prevent intra-domain source address spoofing and facilitate the deployment of SAV, a new intra-domain SAV mechanism is required to achieve accurate SAV, acceptable overhead, and all-direction protection.

For this purpose, this document provides an architecture to generate accurate SAV tables on routers in intra-domain networks. In Intra-domain Source Address Validation (Intra-domain SAVNET) architecture, every router originates individual control-plane messages to its neighbors, carrying information used for SAV table generation. Upon receiving a message, the router can identify a valid incoming interface for the related source address prefixes. After that, it will further propagate this information to generate SAV tables at other routers, or terminate the propagation.

This document also describes basic considerations related to intra-domain SAVNET, including accuracy, convergence, incremental deployment, and security. This document does not describe how to implement intra-domain SAVNET using existing routing protocols, which will be defined in other documents.

2. Terminology

SAV rule: The rule that defines valid incoming interfaces for the specific source prefix.

SAV table: The data structure that stores SAV rules on the data plane.

Improper block: The packets with legitimate source IP addresses are blocked improperly due to inaccurate SAV rules.

Improper permit: The packets with spoofed source IP addresses are accepted due to inaccurate SAV rules.

SPA message: Source Prefix Advertisement message, the message (in intra-domain SAVNET architecture) for a router advertising its source prefixes and router ID to all the other routers in the intra-domain network.

SPD message: Source Path Discovery message, the message (in intra-domain SAVNET architecture) for discovering real data-plane forwarding paths. Through it, a router notifies the valid incoming direction for its source prefixes to other routers on the data-plane forwarding path.

3. Goals of Intra-domain SAVNET

To make improvements to existing intra-domain SAV, intra-domain SAVNET aims to achieve the following goals:

As described in [draft-li-savnet-intra-domain-problem-statement], existing intra-domain SAV mechanism, i.e. ingress filtering[RFC2827][RFC3704], cannot meet the above goals. Specifically, ingress filtering is typically deployed on edge routers and only performs SAV for traffic received from directly connected subnets, making it completely vulnerable to spoofed traffic received from other directions. Besides, ingress filtering mechanisms, such as ACL-based SAV and strict uRPF, either require manual configuration or suffer from severe improper block in the case of asymmetric routing, which cannot meet both the requirements of low cost and high accuracy simultaneously.

To address the problems of existing intra-domain SAV mechanisms, intra-domain SAVNET requires routers to exchange information used for SAV through control-plane protocols and generates SAV tables strictly following real data-plane forwarding paths. The cost of intra-domain SAV includes the communication cost for SAV table generation and the storage and querying cost of SAV table. These costs should be reduced to a reasonable level under current equipment hardware and software conditions.

4. Control-plane Architecture

To achieve the goals in Section 3, the basic procedures of intra-domain SAVNET is to discover the real data-plane forwarding path from the source via hop-by-hop path discovery, and generate SAV rules in routers along the path. Overall, six different operations will be conducted in the procedures:

4.1. Process for SAV Rule Generation

The process for SAV rule generation is briefly described as follows:

  1. Each router A first conducts the operation of source prefix identification to identify its local source prefixes and generates SAV rules for its directly connected subnets (if any). Specifically, for each directly connected subnet N, it generates the SAV rule <source prefixes of subnet N, interface X>, where interface X is the interface connected to the subnet. The process of source prefix identification will be introduced in Section 4.2.
  2. Router A advertises its local source prefixes and its router ID by sending SPA messages to other routers within the AS. Finally, routers can learn the mapping relationship between router IDs and intra-domain source prefixes.

  3. Router A conducts the operation of SPD origination. It sends one SPD message to every next-hop neighboring router according to its local FIB (Forwarding Information Base), carrying two fields:

    • Origin router ID: the router ID of itself (i.e., A);
    • Propagation scope: the destination prefixes which take the neighboring router as the next hop from local FIB.
  4. When the neighboring Router B receives the SPD message at interface I, it first conducts the operation of SAV rule generation. Router B gets the source prefixes corresponding to the origin router ID A based on mapping relationship information learned in step b, and determines interface I as a valid incoming interface for source prefixes of Router A. In other words, it generates the SAV rule <source prefixes of Router A, interface I>.
  5. After that, Router B checks the destination prefixes in the propagation scope field of the received SPD message against its local FIB. If the propagation scope only contains its local source prefixes, Router B conducts the operation of SPD termination. Otherwise, Router B conducts the operation of SPD relaying: It groups these destination prefixes according to their next-hop routers. For each next-hop Router C, Router B generates a relaying SPD message to C. The new propagation scope field contains the corresponding destination prefixes which take Router C as the next hop. The origin router ID in every relaying SPD message should keep the same as the received message.
  6. The other routers that receive SPD messages will do the same processing as in step d and step e.
  7. The above steps will be executed periodically or when any source prefix or routing state changes. Periodical or triggered SPA and SPD messages aim to update SAV rules on the affected routers. Particularly, to reduce the communication cost, only the changed information should be propagated again in the triggered update messages. Intra-domain SAVNET does not explicitly notify routers to withdraw invalid SAV rules, but uses an aging mechanism. The SAV rule will expire if it is not refreshed in the next periodical update process. The aging mechanism helps improve the resilience and avoid improper block in the case of transient route behaviors, since the SAV table does not delete the "invalid" SAV rule immediately. 
                                         +-----------+
       ----------------------------------|  Router 1 #---+P1
       |                                 +-----+-----+
       |                                       | msg 1:
       |                                       | origin_router_ID=[R1],
       |                                       | propagation_scope=[P2,P3,
       |       msg 1.1:                        |                  P4,P5,P6]
       |       origin_router_ID=[R1],          \/
 +-----+-----+ propagation_scope=[P6]    +-----#-----+
 |  Router 6 #<--------------------------+  Router 2 +---+P2
 +-----+-----+     ----------------------+-----+-----+
       |           | msg 1.2:                  | msg 1.3:
       +           | origin_router_ID=[R1],    | origin_router_ID=[R1],
       P6          | propagation_scope=[P3,P5] | propagation_scope=[P4,P5]
                   \/                          \/
             +-----#-----+               +-----#-----+
        P3---+  Router 3 |          P4---+  Router 4 |
             +-----+-----+               +-----+-----+
                   | msg 1.2.1:                | msg 1.3.1:
                   | origin_router_ID=[R1],    | origin_router_ID=[R1],
                   | propagation_scope=[P5]    | propagation_scope=[P5]
                   \/                          |
             +-----#-----+                     |
       P5--- +  Router 5 # <--------------------
             +-----------+

       - P1, P2, P3, P4, P5, and P6 are the source prefixes of
         Router 1, 2, 3, 4, 5, and 6, respectively.
       - R1, R2, R3, R4, R5, and R6 are the router IDs of
         Router 1, 2, 3, 4, 5, and 6, respectively.
       - '#' means the valid incoming interface for the
          data-plane packets with source addresses of P1.
       - The FIB of Router 1:
        +---------------------------------------+
        +  Dest.  Prefix   |  Next hop          +
        +---------------------------------------+
        +  P2              |  Router 2          +
        +  P3              |  Router 2          +
        +  P4              |  Router 2          +
        +  P5              |  Router 2          +
        +  P6              |  Router 2          +
        +---------------------------------------+
       - The FIB of Router 2:
        +---------------------------------------+
        +  Dest.  Prefix   |  Next hop          +
        +---------------------------------------+
        +  P1              |  Router 1          +
        +  P3              |  Router 3          +
        +  P4              |  Router 4          +
        +  P5              |  Router 3/4        +
        +  P6              |  Router 6          +
        +---------------------------------------+
       - The FIB of Router 3:
        +---------------------------------------+
        +  Dest.  Prefix   |  Next hop          +
        +---------------------------------------+
        +  P1              |  Router 2          +
        +  P2              |  Router 2          +
        +  P4              |  Router 2          +
        +  P5              |  Router 5          +
        +  P6              |  Router 2          +
        +---------------------------------------+

      Figure 1: The process for SAV rule generation

Figure 1 illustrates the process for SAV rule generation by taking the process of generating SAV rules for source prefix P1 as an example. There are six routers in the intra-domain network. Each router is connnected to a subnet.

Router 1 first identifies its source prefix P1 (we omit the interface addresses for brevity) and generates the SAV rule <P1, interface '#'>. Then, it conducts the operation of source address advertisement and advertises prefix P1 and its router ID R1 to other routers. After that, as shown in Figure 1, Router 1 conducts the operation of SPD origination to notify other routers of the valid incoming direction for prefix P1. From the FIB of Router 1, P2, P3, P4, P5, P6 take Router 2 as the next hop, so Router 1 generates an original SPD message to Router 2, with R1 in the origin router ID field and P2, P3, P4, P5, P6 in the propagation scope field. Although Router 6 is also a neighboring router of Router 1, Router 1 does not send any SPD message to Router 6 because no prefix takes Router 6 as the next hop from the FIB for Router 1.

When Router 2 receives the SPD message from Router 1 at interface '#', it identifies the source prefix P1 for router ID R1 based on previous SPA messages, and specifies interface '#' as the valid incoming interface for prefix P1. Then, Router 2 checks the destination prefixes in the propagation scope field against its local FIB. P2 is the source prefix of Router 2, so P2 is directly deleted from the propagation scope. From the FIB of Router 2 (note that Router 2 has multiple paths to P5), P3 and P5 take Router 3 as the next hop; P4 and P5 take Router 4 as the next hop; P6 takes Router 6 as the next hop. Therefore, Router2 conducts the operation of SPD relaying and generates an individual relaying SPD message to Router 3, 4, 6, respectively. The relaying SPD message destined to each next-hop router carries corresponding destination prefixes in the new propagation field. The origin router ID in every relaying SPD message keeps the same as the received SPD message.

When Router 3 or Router 4 receives the relaying SPD message from Router 2, it first generates the SAV rule <P1, interface '#'> and then generates a relaying SPD message to Router 5 because P5 takes Router 5 as the next hop in its FIB.

When Router 6 receives the relaying SPD message from Router 2, it generates the SAV rule <P1, interface '#'> but conducts the operation of SPD termination because the propagation scope only contains P6 which is the source prefix of itself. Similarly, upon receiving the relaying SPD message from Router 3 or Router 4, Router 5 generates the SAV rule <P1, interface '#'> and then conducts the operation of SPD termination. It is noted that Router 5 finally determines two valid incoming interfaces for source prefix P1 because it receives two SPD messages with an origin router ID of R1 from different interfaces.

In the end, all routers accurately learn the valid incoming interfaces for source prefix P1. The process of generating SAV rules for other source prefixes is similar. In intra-domain SAVNET, with the exception of some special cases, such as multipath routing, routers usually receive only one SPD message originated from each origin router.

4.2. Process for Source Prefix Identification

The local source prefixes of a router include its interface addresses and the source prefixes of its subnets.

4.2.1. Source Prefix Identification for Interface Addresses

To identify router interface addresses, the router can obtain these prefixes directly from local interface configuration information.

4.2.2. Source Prefix Identification for Single-homed Subnet

To identify source prefixes of a single-homed subnet, the router can easily identify the source prefixes through local routes to the subnet (such as direct interface routes, configured static routes, or dynamic routes imported from the subnet).

4.2.3. Source Prefix Identification for Multi-homed Subnet

However, as described in [draft-li-savnet-intra-domain-problem-statement], the router may not identify complete source prefixes of a multi-homed subnet through local routes to the subnet in the case of routing asymmetry. Hence, an extended SPA message is introduced to exchange local route information between the multiple access routers to get the complete source prefixes.

+--------------------------------------------------------------------+
|                                                       AS           |
|                                                                    |
|                       [10.1.0.0/16]+[tag n]                        |
|  +----------+  ----------------------------------->  +----------+  |
|  | Router A |         Extended SPA messages          | Router B |  |
|  +-------#--+  <----------------------------------+  +--#-------+  |
|          |            [10.0.0.0/16]+[tag n]             |          |
|          |                                              |          |
|          |                                              |          |
|          |                                              |          |
|          |               +----------+                   |          |
|          +---------------+ Subnet N +-------------------+          |
|                          +----------+                              |
|                         (10.0.0.0/15 )                             |
+--------------------------------------------------------------------+

  - Asymmetric routing:
    1) Router A only learns 10.1.0.0/16 from its local route to Subnet N
    2) Router A only learns 10.0.0.0/16 from its local route to Subnet N
  - Interfaces '#' in Router A and Router B are configured with tag n.

Figure 2: Source prefix identification for multi-homed subnet in an asymmetric routing scenario.

Figure 2 shows the process of source prefix identification for the multi-homed subnet in an asymmetric routing scenario:

  1. In intra-domain SAVNET architecture, each multi-homed subnet is assigned a unique tag value and all router interfaces connected to the same multi-homed subnet are configured with the corresponding tag value. Assume Subnet N is assigned the tag n. Interfaces '#' in Router A and Router B are both configured with tag n.
  2. Each of the multiple access routers (e.g., Router A) will generate extended SPA messages to advertise the prefixes learned through its local routes to the multi-homed subnet and the corresponding tag value. For example, Router A will generate extended SPA messages to other intra-domain routers carrying prefix 10.1.0.0/16 (which is identified through its local route to Subnet N) and tag n.
  3. When Router B receives an extended SPA message carrying the same tag value as the tag value of its directly connected Subnet N, it considers the prefix (i.e., 10.1.0.0/16) in the extended SPA message as part of the source prefixes of Subnet N.
  4. Router B finally integrates the prefix 10.1.0.0/16 learned in step c with the prefix 10.0.0.0/16 learned from its local routes to Subnet N for the complete source prefix 10.0.0.0/15 of Subnet N. Similarly, Router A also identifies the complete source prefix 10.0.0.0/15 of Subnet N after receiving an extended SPA message originated from Router B.

4.3. Message Type

4.3.1. SPD Message

SPD message is used to discover the real forwarding data-plane path from the source and generate SAV rules in routers along the path. As shown in Figure 3, the SPD message consists of two main fields:

  • Origin Router ID: This field contains the router ID of the origin router and remains unchanged.
  • Propagation Scope: This field contains a list of destination prefixes which take the neighboring router as the next hop (from FIB) and changes hop by hop. 
                             / +-----------------------+
+-----------------------+   /  |     Dest Prefix 1     |
|    Origin Router ID   |  /   +-----------------------+
+-----------------------+ /    |     Dest Prefix 2     |
|   Propagation Scope   |      +-----------------------+
+-----------------------+ \    |       ......          |
                           \   +-----------------------+
                            \  |     Dest Prefix n     |
                             \ +-----------------------+

               Figure 3: SPD message format

4.3.2. SPA Message

SPA message is used to advertise the relationship between source prefixes and router IDs. As shown in Figure 4, the SPA message has two main fields:

  • Origin Router ID: This field contains the router ID of the origin router.
  • Source Prefix List: This field contains a list of local source prefixes of the origin router. 
                             / +-----------------------+
+-----------------------+   /  |    Source Prefix 1    |
|    Origin Router ID   |  /   +-----------------------+
+-----------------------+ /    |    Source Prefix 2    |
|   Source Prefix List  |      +-----------------------+
+-----------------------+ \    |       ......          |
                           \   +-----------------------+
                            \  |    Source Prefix n    |
                             \ +-----------------------+

              Figure 4: SPA message format

4.3.3. Extended SPA message

The extended SPA message is used for source prefix identification for multi-homed subnet. As described in Section 4.2.3 and shown in Figure 5, the extended SPA message has three main fields:

  • Origin Router ID: This field contains the router ID of the origin router.
  • Tag: This field contains a tag value configured for a connected subnet.
  • Source Prefix List: This field contains a list of source prefixes learned through local routes to the connected subnet whose tag is filled in the Tag field. 
+-----------------------+
|    Origin Router ID   |    / +-----------------------+
+-----------------------+   /  |    Source Prefix 1    |
|          Tag          |  /   +-----------------------+
+-----------------------+ /    |    Source Prefix 2    |
|   Source Prefix List  |      +-----------------------+
+-----------------------+ \    |       ......          |
                           \   +-----------------------+
                            \  |    Source Prefix n    |
                             \ +-----------------------+

Figure 5:  The extended SPA message format

5. Data-plane Architecture

5.1. SAV Table Format

The format and organization way of the SAV table are similar to the FIB table . As shown in Figure 6, the SAV table consists of two parts: source prefix and incoming interface.

  +------------------------------------------+
  +  Source prefix   |  Incoming interface   +
  +------------------------------------------+
  +  P1              |  Intf.1               +
  +  P2              |  Intf.2, Intf.3       +
  +  P3              |  Intf.4               +
  +------------------------------------------+

    Figure 6: SAV table structure

5.2. Data-plane SAV Operation

When performing SAV for received data-plane packets, the router looks up every packet's source address against its local SAV table, and gets one of three validity states: "valid", "invalid" or "unknown". "Valid" means that there is a source prefix in SAV table covering the source address, and the corresponding valid incoming interfaces cover the incoming interface of the packet. "Invalid" means there is a source prefix in SAV table covering the source address, but the incoming interface of the packet does not match the valid incoming interfaces. "Unknown" means there is no source prefix in SAV table covering the source address.

The router takes different actions based on the validity state of the packet. If the state is "valid", the source address is considered as a legitimate source address and the packet is permitted. If the state is "invalid", the source address is considered as a spoofed address and the packet is blocked. If the state is "unknown", the packet is processed according to the validation mode configured on the incoming interface. Intra-domain SAVNET allows the router to configure individual validation modes for packets received from different interfaces:

More details about the SAV table can be found in [draft-huang-savnet-sav-table].

6. Accuracy Consideration

The most important goal of intra-domain SAVNET is to improve accuracy, i.e., avoid improper block problems and try best to reduce improper permit problems. The key factors that can affect the accuracy of intra-domain SAVNET mainly come from two aspects, i.e. source prefix identification and source path discovery:

6.1. Factors that Affect Source Prefix Identification

Factors that should be considered in the process of source prefix identification have been provided in Section 4.2. However, it is still possible that the router can not recognize its complete local source prefixes. For example, if a multi-homed subnet is connected to two edge routers in different ISPs (Internet Service Provider), the two edge routers are unable to exchange individual local source prefix information through the routing protocol. Therefore, the two edge router are unable to identify the complete source prefixes of the multi-homed subnet in the case of routing asymmetry. It is also difficult for a boundary router to fully identify source prefixes that can be accepted from the interface connected to another autonomous system, due to the existence of default route or asymmetric route. To avoid improperly blocking legitimate traffic in above cases, the router must adopt Interface Allowlist Mode when validating traffic received from the specific interface.

6.2. Factors that Affect Source Path Discovery

6.2.1. FIB Forwarding

FIB forwarding is the most common scenario in which intra-domain SAVNET finds a single next-hop interface based on the destination prefix, i.e., determining the next hop for forwarding based on destination ip-prefix.

ECMP (Equal-cost multi-path routing) or UCMP (Unequal-cost multi-path routing) is a special case for FIB forwarding. To achieve multi-path routing, hashing functions are usually taken, which map packet header field values (e.g., source/destination IP, source/destination port, protocol type) to candidate next hops. Packets with the same destination IP address may be forwarded to different next hops. In this case, SPD messages must be sent to all these next hops, thus generating SAV rules in routers on each ECMP/UCMP path.

6.2.2. ACL Redirection

ACL redirection can redirect traffic to a specific next hop, making the forwarding behavior inconsistent with the FIB. In this case, routers must take the configuration information of ACL redirection into consideration when generating original and relaying SPD messages.

Advanced ACL redirection rules typically match source IP, destination IP, source port, destination port, or protocol type. When conducting the operation of SPD message origination, the router needs to check its local source prefixes and the destination prefixes in local FIB against its ACL redirection rules:

  • If the source prefix matches the ACL redirection rule, it adds all destination prefixes in local FIB into the propagation scope of the original SPD message sent to the redirected next hop.
  • If the destination prefix matches the ACL redirection rule, it adds the matched destination prefix into the propagation scope of the original SPD message sent to the redirected next hop.
  • If there is an ACL redirection rule that does not check source IP and the destination IP, but checks only other fields, packets with any source IP address or destination IP address has the possibility to match this redirection rule. In this case, the router needs to add all destination prefixes in local FIB into the propagation scope of the original SPD message sent to the redirected next hop.

Similarly, when conducting the operation of SPD message relaying, the router should also check the source prefixes of the origin router and the destination prefixes in the propagation scope field against its ACL redirection rules:

  • If the source prefix matches, it adds all destination prefixes carried in the received SPD message into the propagation scope of the relaying SPD message sent to the redirected next hop.
  • If the destination prefix matches, it adds the matched destination prefix into the propagation scope of the relaying SPD message sent to the redirected next hop.
  • If there is an ACL redirection rule that does not check source IP and the destination IP, but checks only other fields, it adds all destination prefixes carried in the received SPD message into the propagation scope of the relaying SPD message sent to the redirected next hop.

6.2.3. Tunneling Technology

Tunnel technologies, such as MPLS, SR, and GRE, are usually used to control the forwarding behavior. In the preliminary idea, intra-domain SAVNET performs data-plane SAV only on routers before and after the tunnel. The ingress router will directly send an SPD message to the corresponding egress router based on local control-plane information of tunnel technology. Upon receiving the SPD message, the egress router will further generate relaying SPD messages by checking the propagation scope against local FIB. However, if there is a need to perform data-plane SAV for IP prefixes used inside the IP-encapsulation tunnel (such as SRv6 and GRE), the SPD message needs to be propagated from the ingress router to the egress router hop by hop, thus generating SAV rules on routers inside the tunnel.

7. Convergence Consideration

The factors influencing the accuracy of intra-domain SAVNET may change with time. Such changes can lead to improper block or improper permit problems. The SAV rules generated through intra-domain SAVNET should be updated in time so as to keep consistent with routing states. The convergence of intra-domain SAVNET is important for the SAV architecture working well in dynamic networks.

A simple method is to generate new SPA and SPD messages periodically. An aging mechanism can also be used for deleting invalid SAV rules. That is, SAV rules will expire after a period of time. However, these solutions may take much time before eliminating improper block and improper permit problems. Some fast convergence mechanisms are necessary to achieve consistency of intra-domain SAVNET in time. Except the aging process works as the basic mechanism, here are some preliminary ideas for different cases:

7.1. Source Prefix Change

When source prefix changes, a router must generate new SPA messages immediately upon discovering its local source prefixes change.

7.2. Forwarding Path Change

Since intra-domain SAVNET generates SAV rules following the real data-plane forwarding path, SAV rules need to be updated when the forwarding path changes. To achieve fast convergence, routers need to generate triggered SPD messages to update SAV rules on other routers as soon as possible. The process of triggered update is as follows:

  1. Initially, each Router A records the information (the origin router ID and the propagation scope) of each received SPD message locally. With this information, Router A knows which origin routers have reached a specific destination prefix through itself.
  2. When Router A notices that the next hop to a destination prefix P changes, Router A generates a triggered SPD message. Different from the periodical SPD message, the triggered SPD message carries not only the router ID of Router A but also router IDs of other origin routers that previously reached the destination prefix through Router A. The propagation scope of the triggered SPD message only contains the destination prefix P. If those origin routers do not change the next hop to destination prefix P, they do not need to generate any triggered SPD messages.
  3. When receiving a triggered SPD message at interface '#', Router B identifies the interface '#' as the valid incoming interface for source prefixes of all router IDs carried in the SPD message. It then conducts the operation of SPD relaying or SPD termination following the description in Section 4.1.

When updating, there may still be a gap between the change of FIB table and the update of SAV rules. The gap is inevitable, but the triggered update mechanism of intra-domain SAVNET can enable the fastest convergence of SAV rule generation. Moreover, the triggered update mechanism requires as few routers as possible to participate in the update process, which significantly reduces the protocol overhead.

7.3. FRR Deployment

For the scenarios where fast reroute (FRR) is deployed, routers will send SPD messages to the backup forwarding paths in advance, and the backup SAV rules can be installed for fast convergence when failure happens.

8. Incremental Deployment

In the intra-domain network, it is difficult to require all routers to support intra-domain SAVNET simultaneously, because routers can have different versions and capabilities. The incremental deployment of intra-domain SAVNET must be considered.

In general, routers in the access layer are used to connect users to the network and have relatively low capability. Routers in the aggregation layer provides policy-based connectivity between access and core layers. Routers in the core layer are mainly used for routing selection and high-speed forwarding. Therefore, routers in aggregation and core layers usually have higher capability, performance, and reliability. In incremental deployment condition, it is highly recommended to preferentially deploy intra-domain SAVNET at routers in the aggregation and core layers to achieve more effective SAV.

For example, in OSPF protocol, non-backbone areas need to pass through the backbone area (i.e., Area 0) for communication. If intra-domain SAVNET cannot be implemented on all intra-domain routers at the same time, it is suggested to implement intra-domain SAVNET in Area 0 as the first step, achieving wider protection scope with the same implementation cost. Specifically, when only deploying intra-domain SAVNET in Area 0, every ABR (Area Border Router) can originate SPA and SPD messages on behalf of the directly connected non-backbone area. In this way, every deployed router learns the valid incoming interfaces for source addresses of individual non-backbone areas, and thus preventing source address spoofing between different non-backbone areas. Similarly, IS-IS protocol also divides backbone area (i.e., Level 2) and non-backbone area (i.e., Level 1). In incremental deployment condition, it is recommended to implement intra-domain SAVNET in Level 2 at the beginning. By starting from the backbone area and expanding the deployment area hop by hop in the non-backbone area, the overall defense capability against source address spoofing provided by intra-domain SAVNET becomes stronger.

9. Security Consideration

As described in [draft-li-savnet-intra-domain-problem-statement], similar to the security scope of intra-domain routing protocols intra-domain SAVNET should ensure integrity and authentication of protocol messages that deliver the required SAV information, but does not provide protection against compromised or misconfigured routers that poison existing control-plane protocols. Since intra-domain SAVNET will be implemented by using or extending existing routing protocols, it can use the security mechanism of existing routing protocols to achieve this goal. Specific protocol extensions and security designs will be included in a separate protocol extension draft.

10. Normative References

[draft-huang-savnet-sav-table]
Huang, M., Zhou, T., Geng, N., Li, D., Chen, L., and J. Wu, "Source Address Validation Table Abstraction and Application", .
[draft-li-savnet-intra-domain-problem-statement]
Li, D., Wu, J., Qin, L., Huang, M., and N. Geng, "Source Address Validation in Intra-domain Networks (Intra-domain SAVNET) Gap Analysis, Problem Statement and Requirements", .
[RFC2827]
Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, , <https://www.rfc-editor.org/info/rfc2827>.
[RFC3704]
Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, , <https://www.rfc-editor.org/info/rfc3704>.
[RFC5210]
Wu, J., Bi, J., Li, X., Ren, G., Xu, K., and M. Williams, "A Source Address Validation Architecture (SAVA) Testbed and Deployment Experience", RFC 5210, DOI 10.17487/RFC5210, , <https://www.rfc-editor.org/info/rfc5210>.
[RFC7039]
Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed., "Source Address Validation Improvement (SAVI) Framework", RFC 7039, DOI 10.17487/RFC7039, , <https://www.rfc-editor.org/info/rfc7039>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC8704]
Sriram, K., Montgomery, D., and J. Haas, "Enhanced Feasible-Path Unicast Reverse Path Forwarding", BCP 84, RFC 8704, DOI 10.17487/RFC8704, , <https://www.rfc-editor.org/info/rfc8704>.

Authors' Addresses

Dan Li
Tsinghua University
Beijing
China
Jianping Wu
Tsinghua University
Beijing
China
Lancheng Qin
Tsinghua University
Beijing
China
Fang Gao
Zhongguancun Laboratory
Beijing
China
Nan Geng
Huawei
Beijing
China
Tianran Zhou
Huawei
Beijing
China