Intra-domain Source Address Validation (SAVNET) Architecture
draft-li-savnet-intra-domain-architecture-01

Network Working Group                                              D. Li
Internet-Draft                                                     J. Wu
Intended status: Standards Track                     Tsinghua University
Expires: 13 September 2023                                      M. Huang
                                                                  Huawei
                                                                 L. Chen
                                                 Zhongguancun Laboratory
                                                                 N. Geng
                                                                  Huawei
                                                                  L. Qin
                                                     Tsinghua University
                                                                  F. Gao
                                                 Zhongguancun Laboratory
                                                           12 March 2023

      Intra-domain Source Address Validation (SAVNET) Architecture
              draft-li-savnet-intra-domain-architecture-01

Abstract

   Intra-domain source address validation (SAV) plays an important role
   in defending against source address spoofing attacks in intra-domain
   networks.  This document proposes an intra-domain source address
   validation (intra-domain SAVNET) architecture.  Under the
   architecture, a router can automatically generate accurate SAV rules
   based on the SAV-related information from multiple information
   sources.  This document does not specify protocols or protocol
   extensions, instead focusing on architectural components and their
   functionalities in an intra-domain SAVNET deployment.

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/.

Li, et al.              Expires 13 September 2023               [Page 1]
Internet-Draft      Intra-domain SAVNET Architecture          March 2023

   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 13 September 2023.

Copyright Notice

   Copyright (c) 2023 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Design Goals  . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Intra-domain SAVNET Architecture  . . . . . . . . . . . . . .   5
     4.1.  SAV Information Base Manager  . . . . . . . . . . . . . .   6
     4.2.  RPDP and RPDP Speaker . . . . . . . . . . . . . . . . . .   7
   5.  Partial Deployment  . . . . . . . . . . . . . . . . . . . . .   8
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   7.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .   9
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   Source address validation (SAV) is important for mitigating source
   address spoofing and contributing 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
   (such as SAVI [RFC7039][RFC7513], Cable Source Verify [cable-verify],
   and IP Source Guard [IPSG]), intra-domain SAV helps block spoofed
   packets as close to the source as possible.

Li, et al.              Expires 13 September 2023               [Page 2]
Internet-Draft      Intra-domain SAVNET Architecture          March 2023

   There are some intra-domain SAV mechanisms available.  However,
   existing intra-domain SAV mechanisms have the problems of inaccurate
   validation under asymmetric routing and high operational overhead in
   dynamic networks [draft-li-savnet-intra-domain-problem-statement].

   To solve the problems above, this document proposes an intra-domain
   source address validation (intra-domain SAVNET) architecture.  Under
   the architecture, routers can collaborate to discover real incoming
   interfaces of source prefixes adaptive to routing status, and the
   packets from all directions can be validated, which yields
   improvements on source address protection.

   This document focuses on the high-level architecture designs and does
   not specify protocols or protocol extensions.

2.  Terminology

   SAV Rule: The rule that indicates the valid incoming interfaces for a
   specific source prefix or that indicates the valid source prefixes
   for a specific interface.

   SAV Table: The table or data structure that implements the SAV rules
   and is used for source address validation in the data plane.

   Improper Block: The validation results that the packets with
   legitimate source addresses are blocked improperly due to inaccurate
   SAV rules.

   Improper Permit: The validation results that the packets with spoofed
   source addresses are permitted improperly due to inaccurate SAV
   rules.

   SIB: SAV information base that is for storing SAV-related information
   collected from different information sources.

   SMP: SIB management protocol that represents any protocols for
   managing data in SIB.

   RPDP: Real path discovering protocol, generally referring to the
   extension of existing routing protocols.  The RPDP messages can
   explicitly or implicitly indicate the real incoming interfaces of
   some specified source prefixes.

3.  Design Goals

   The intra-domain SAVNET architecture is to enhance the intra-domain
   SAV and aims to achieve the following goals:

Li, et al.              Expires 13 September 2023               [Page 3]
Internet-Draft      Intra-domain SAVNET Architecture          March 2023

   *  Accurate validation.  The real incoming interfaces of source
      prefixes need to be completely learned, and improper block can be
      avoided.  By trying to exclude non-real incoming interfaces from
      the valid interface group, improper permit can be reduced.

   *  Low operational overhead.  The routers after initial
      configurations can adapt to dynamic routing changes automatically,
      so that the operational overhead can be controlled.

   *  Working in partial deployment.  Routers need to do SAV for both
      external packets (from subnets or the Internet) and internal
      packets (forwarded by other routers).  On the one hand, edge (or
      border) routers take SAV for external packets including those from
      both the subnets and the Internet.  On the other hand, edge
      routers and non-edge routers take SAV for internal packets, which
      is necessary in partial deployment cases.  Under partial
      deployment, edge routers may not be able to block all the spoofed
      external packets.  SAV for internal packets is to filter the
      malicious packets mixed in internal packets.

   To achieve the goal of accurate validation, a router cannot generate
   SAV rules based on only local RIB/FIB because asymmetric routing
   exists, and purely relying on manual SAV rule configurations for
   guaranteeing accurate validation is not practical.  The key challenge
   is how to make a router automatically discover real incoming
   interfaces of source prefixes of both external and internal packets.

   Consider that the real incoming interfaces are determined by the
   forwarding rules of other routers in the network and cannot be
   entirely obtained locally.  To address the key challenge, the intra-
   domain architecture includes a real path discovery protocol (RPDP) by
   extending existing routing protocols.  Routers will propagate SAV-
   related data by sending RPDP messages adaptive to forwarding rules.
   These messages will be received by other routers.  By combining the
   information from manual configurations, RIB/FIB, and protocol
   messages, accurate SAV rules for both external and internal packets
   can be generated.

   Other design goals, such as low data plane overhead and easy
   implementation, are also important, but out of the scope of this
   document.  They should be considered in specific protocols or
   protocol extensions of SAVNET.

Li, et al.              Expires 13 September 2023               [Page 4]
Internet-Draft      Intra-domain SAVNET Architecture          March 2023

4.  Intra-domain SAVNET Architecture

   The intra-domain SAVNET architecture is depicted from the perspective
   of a router.  Figure 1 shows the architecture which consists of a few
   components.  Among these components, the three of SAV Information
   Base (SIB) manager, RPDP speaker, and SAV table are specialized for
   SAV.  The other components are existing ones but are required for SAV
   rule generation.

             +------------------------------------------+
             |          Other Protocol Speakers         |
             +------------------------------------------+
                               /\
                               | Protocol Messages
       +-----------------------------------------------------+
       | Router                 |                            |
       |                        \/                           |
       | +-------------------------------------------------+ |
       | |  Routing           +------------------------+   | |
       | |  Protocol          |      RPDP Speaker      |   | |
       | |  Speaker           +------------------------+   | |
       | +-------------------------------------------------+ |
       |   |Routing        /\Routing     |SAV                |
       |   |Information     |Table       |Information        |
       |   |Dissemination   |            |Dissemination      |
       |   |Messages        |            |Messages           |
       |   \/               |            \/                  |
       | +--------------------+   +----------------------+   |
       | |                    |   |+--------------------+|   |
       | |   Routing          |   ||SAV Information Base||   |
       | |   Information      |-->|+--------------------+|   |
       | |   Base             |   | SAV Information Base |   |
       | |                    |   | Manager              |   |
       | +--------------------+   +----------------------+   |
       |                                   |SAV Rules        |
       |                                   \/                |
       |                             +-----------+           |
       |                             | SAV Table |           |
       |                             +-----------+           |
       +-----------------------------------------------------+
                 /\ Manual Configurations
                 |
       +----------------------+
       | CLI, YANG, SMP, etc. |
       +----------------------+

               Figure 1: The intra-domain SAVNET Architecture

Li, et al.              Expires 13 September 2023               [Page 5]
Internet-Draft      Intra-domain SAVNET Architecture          March 2023

4.1.  SAV Information Base Manager

   SIB manager is the core component for SAV rule generation in the
   architecture.  The component collects SAV-related information from
   multiple information sources, stores the information in SIB after
   consolidation, and outputs SAV rules based on the stored information.
   SAV rules indicate the valid incoming interfaces of source prefixes,
   which can be represented by <Prefix, Interface> pairs.

   As described previously, collecting SAV-related information purely
   from local routing information and manual configuration is not enough
   or practical for learning accurate <Prefix, Interface> pairs.  The
   protocol called RPDP in the document is designed as the third
   information source which provides accurate SAV information.
   Therefore, in the architecture, there are total of three information
   sources, which are listed as follows:

   *  Manual Configuration: The routers should support SAV-related
      configurations.  The configurations may be from CLI, YANG, SIB
      management protocol (SMP), etc.  SMP mentioned herein represents
      any protocols designed for managing data in SIB.

   *  Routing Information Base: RIB stores routing information learned
      from routing protocols.  It has been used in some existing SAV
      mechanisms.

   *  RPDP Messages: Routers will send RPDP messages according to local
      forwarding rules.  The real incoming interfaces of source prefixes
      can be learned from the received messages.

   Although there are multiple information sources, one can choose some
   of them (e.g., RIB and RPDP speaker) for SAV instead of using all of
   them.  When more than one information sources are used, data
   conflicts may exist.  To address the issue, priorities can be set to
   the sources.  For the items with data conflicts, the items from the
   source of higher priority will be preferred.  For the items without
   data conflicts, a union of the items will be taken.  For example,
   suppose that manual configuration has the highest priority.  When the
   information from RIB indicates that Interface 1 is the valid incoming
   interface of source prefix P1, the operators can manually configure
   Interface 1 as the invalid interface of P1.

   By consolidating the information from different sources, SAV manager
   will get the pairs of <Prefix, Interface> for all prefixes, which are
   stored in SAV information base.  Figure 2 illustrates SAV information
   base.  In the figure, each source prefix (including the default
   prefix, i.e., 0.0.0.0) has one or more valid incoming interfaces.
   The information sources for a pair of <Prefix, Interface> are also

Li, et al.              Expires 13 September 2023               [Page 6]
Internet-Draft      Intra-domain SAVNET Architecture          March 2023

   recorded.  For example, P1 has two incoming interfaces of Interface 1
   and Interface 3.  Any other interfaces except Interface 1 and 3 will
   be considered invalid for P1.  In the example, Interface 3 for P1 is
   discovered by only RPDP, which may appear in asymmetric routing
   cases.

   An SAV table can be generated based on SAV information base.  The SAV
   rules in the table will be installed into the data plane for
   validating the packets from all directions.  The working modes and
   usage suggestions of SAV table can be found in
   [draft-huang-savnet-sav-table].

   +----------------------------------------------------------+
   | Source Prefix | Incoming Interface | Information Sources |
   +---------------+--------------------+---------------------+
   |     P1        |    Interface 1     |       b,c           |
   |     P1        |    Interface 3     |       b             |
   |     P2        |    Interface 2     |       b,c           |
   |     P3        |    Interface 4     |       a             |
   |     ...       |        ...         |       ...           |
   |     default   |    Interface 4     |       a             |
   +----------------------------------------------------------+
   * a: Manual Config, b: RIB, c: RPDP

             Figure 2: An illustration of SAV information base

4.2.  RPDP and RPDP Speaker

   The RPDP is for automatically discovering real incoming interfaces of
   source prefixes.  Particularly, the RPDP needs to extend existing
   routing protocols.  The RPDP speaker is responsible for dealing with
   message interactions of the RPDP, and it naturally resides in the
   routing protocol speaker.  The RPDP messages are carried by newly
   defined TLVs or messages of routing protocols.

   Through the RPDP speaker, routers can send RPDP messages explicitly
   or implicitly indicating the real incoming interfaces of some
   specified source prefixes.  A router receiving RPDP messages can
   resolve the SAV-related information for rule generation.  Thus, there
   exists cooperation between routers.  The followings are some kinds of
   SAV-related information that can be propagated by RPDP:

   *  Source prefixes with a configured tag.  A router can construct a
      message containing some source prefixes (e.g., the prefixes
      matching a routing policy) as well as a configured tag.  The
      routers whose interfaces are configured the same tag value, will
      receive the tagged source prefixes and will consider the
      interfaces with the same tag value as the real incoming interfaces

Li, et al.              Expires 13 September 2023               [Page 7]
Internet-Draft      Intra-domain SAVNET Architecture          March 2023

      of these source prefixes.  Note that, some initial manual
      configurations are needed such as tag configuration and prefix
      matching policy configuration.  After the initial configurations,
      the routers can adapt to prefix changes automatically.

   *  Source prefixes which are propagated through real forwarding
      paths.  A router can construct a message containing some source
      prefixes and one of the locally reachable destination prefixes.
      The message will be sent to the nexthop through which the
      destination prefix is reachable according to the local forwarding
      rules.  The routers receiving the message from an interface will
      bind the interface with the source prefixes.  Then, the message
      will be sent out by looking up the local forwarding rules of the
      destination prefix.  A router may have lots of locally reachable
      destination prefixes and needs to send messages for each of the
      destination prefixes so that all the real incoming interfaces can
      be discovered.  To reduce the communication overhead, a message
      can contain multiple destination prefixes who have the same
      nexthop.  Note that, any factors that affect forwarding should be
      considered during the message propagation.

   *  Forwarding information.  A router can advertise the local
      forwarding information (e.g., route redirection) that may result
      in asymmetric routing.  Then, other routers will conduct path
      computations and then get the real forwarding paths of source
      prefixes.

   In the architecture, the RPDP speaker will get routing table from the
   RIB and policy routing information from the policy-based routing.
   These kinds of information will be useful for the RPDP speaker
   constructing and sending RPDP messages.  After receiving RPDP
   messages, the speaker will disseminate SAV information to the SIB
   manager component.

   The RPDP speaker should sense the adaptiveness of local source
   prefixes, forwarding rules, and SAV-related configurations (e.g.,
   tags), etc.  The adaptiveness should be notified to related routers
   through RPDP messages in time.

5.  Partial Deployment

   Since an intra-domain network mostly has one administration, it is
   possible to deploy SAVNET on all routers.  Under full deployment,
   only edge routers need to enable SAV for validating external packets.
   However, partial deployment may still exist due to phased deployment
   or the limitations coming from multi-vendor supplement.  In such
   cases, the SAV for internal packets are needed, which is supported by
   the intra-domain SAVNET architecture.

Li, et al.              Expires 13 September 2023               [Page 8]
Internet-Draft      Intra-domain SAVNET Architecture          March 2023

   There are another kind of cases where the SAV for internal packets
   are necessary.  Sometimes, the software of some edge routers has been
   upgraded for supporting SAVNET, but these routers are not able to do
   SAV due to the limited data plane capability.  In such cases, these
   edges routers can still run SAVNET protocols to help other routers
   accurately validating external and internal packets.

   The architecture does not require to be deployed in the whole network
   like an AS.  It also works when an area of the network supports the
   architecture.  A more detailed analysis on partial deployment may be
   provided in the future version of the document.

6.  Security Considerations

   The security considerations should be provided in the protocol
   extension documents.

7.  Privacy Considerations

   An intra-domain network is mostly operated by a single organization
   or company, so the architecture does not import privacy issues in
   most cases.  There should be an analysis on privacy in the protocol
   extension documents.

8.  IANA Considerations

   This document has no IANA requirements.

9.  References

9.1.  Normative References

   [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", 15 December 2022.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

9.2.  Informative References

   [cable-verify]
              Cisco, "Cable Source-Verify and IP Address Security",
              2021, <https://www.cisco.com/c/en/us/support/docs/
              broadband-cable/cable-security/20691-source-verify.html>.

Li, et al.              Expires 13 September 2023               [Page 9]
Internet-Draft      Intra-domain SAVNET Architecture          March 2023

   [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", 24 October 2022.

   [IPSG]     Cisco, "Configuring DHCP Features and IP Source Guard",
              2016, <https://www.cisco.com/c/en/us/td/docs/switches/lan/
              catalyst2960/software/release/12-
              2_53_se/configuration/guide/2960scg/swdhcp82.html>.

   [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, June 2008,
              <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, October 2013,
              <https://www.rfc-editor.org/info/rfc7039>.

   [RFC7513]  Bi, J., Wu, J., Yao, G., and F. Baker, "Source Address
              Validation Improvement (SAVI) Solution for DHCP",
              RFC 7513, DOI 10.17487/RFC7513, May 2015,
              <https://www.rfc-editor.org/info/rfc7513>.

Authors' Addresses

   Dan Li
   Tsinghua University
   Beijing
   China
   Email: tolidan@tsinghua.edu.cn

   Jianping Wu
   Tsinghua University
   Beijing
   China
   Email: jianping@cernet.edu.cn

   Mingqing Huang
   Huawei
   Beijing
   China
   Email: huangmingqing@huawei.com

Li, et al.              Expires 13 September 2023              [Page 10]
Internet-Draft      Intra-domain SAVNET Architecture          March 2023

   Li Chen
   Zhongguancun Laboratory
   Beijing
   China
   Email: lichen@zgclab.edu.cn

   Nan Geng
   Huawei
   Beijing
   China
   Email: gengnan@huawei.com

   Lancheng Qin
   Tsinghua University
   Beijing
   China
   Email: qlc19@mails.tsinghua.edu.cn

   Fang Gao
   Zhongguancun Laboratory
   Beijing
   China
   Email: gaofang@zgclab.edu.cn

Li, et al.              Expires 13 September 2023              [Page 11]