Intra-domain Source Address Validation (SAVNET) Architecture

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 26 January 2024.¶

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

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 from the access network as close to the source as possible. The concept of intra-domain SAV in this document keeps consistent with that in [I-D.ietf-savnet-intra-domain-problem-statement].¶

The main task of SAV mechanisms is to generate SAV rules for checking the validity of source addresses of data packets. The information of source addresses/prefixes and their incoming directions makes up the SAV rules. How to efficiently and accurately learn the information is the core challenge for SAV mechanisms. There are many intra-domain SAV mechanisms available such as ACL-based filtering [RFC2827], strict uRPF [RFC3704], and loose uRPF [RFC3704]. SAV rules are generated by either routing information or manual configurations. However, they are faced with the problems of high operational overhead and inaccurate validation in some scenarios [I-D.ietf-savnet-intra-domain-problem-statement].¶

An intra-domain architecture is proposed in this document to address the above issues. Consider that routing information is not accurate enough for SAV rule generation. SAV-specific information is defined which can provide more accurate incoming directions of source addresses. For example, a route indicates that the next-hop of address P1 is Intf. 1, while the packets with source address of P1 come from Intf. 2. SAV-specific information can be used to indicate the real incoming interface of the address and replace the reverse route looking up.¶

Under the architecture, devices can communicate with each other and share SAV-specific information besides routing information. Accurate SAV rules on devices can be automatically generated based on the learned SAV-related information. When the architecture is partially or incrementally deployed, complete SAV-specific information may not be available. Devices can leverage routing information for generating SAV rules. By default, SAV-specific information has a higher priority than routing information in case of information conflicts.¶

This document presents the high-level designs for future intra-domain SAV mechanisms. The definitions of SAV-specific information, architectural components, and the collaborations between them are the focus of the document. The main purpose is to provide a conceptual framework and guidance for the development of intra-domain SAV mechanisms, allowing implementers to adapt and implement the architecture based on their specific requirements and network environments. The protocols or protocol extensions for implementing the architecture are not in the scope of this document.¶

2. Design Goals

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

• Automatic Update. The devices after initial configurations can adapt to dynamic routing changes automatically, so that the operational overhead can be controlled.¶
• Accurate Validation. The real incoming interfaces of source prefixes need to be completely learned, and false positive can be avoided. By trying to exclude non-real incoming interfaces from the valid interface group, false negative can be reduced.¶
• Working in Incremental/Partial Deployment. The architecture should be no worse than existing mechanisms under incremental/partial deployment.¶

Existing SAV mechanisms mostly rely on routing information for automatically generating SAV rules. However, route decides the outgoing interface of source address while SAV focuses on the incoming interface. Therefore, in some cases, routing information cannot support accurate rule generation. The information specifically useful to accurate SAV is required. Manually configuring such information on devices is not practical especially in large-scale and dynamic networks.¶

To achieve the above goals, the architecture proposes to allow devices to advertise SAV-specific information automatically. The SAV-specific information will provide more accurate incoming directions of source addresses than routing information. Devices receiving the information will be able to generate accurate SAV rules. Since the updates of SAV-specific information will be advertised proactively, the generated SAV rules can be automatically updated. By properly utilizing routing information, the architecture can also work in incremental/partial deployment¶

3. SAV-Specific Information

SAV-related information represents any information that is useful for getting or generating SAV rules. There are largely two kinds of SAV-related information: routing information and SAV-specific information.¶

Routing information is used for forwarding rule computation, which mostly stored in RIB/FIB. It is not specialized for SAV but can be used to some extent for SAV. Existing SAV mechanisms like strict uRPF and loose uRPF conduct SAV solely based on routing information.¶

SAV-specific information is specialized for SAV, which explicitly or implicitly indicates the accurate incoming directions of source addresses. Compared to using routing information, the accuracy of SAV rules can be improved through SAV-specific information. The false positive problems can be avoided and the false negative problems can be reduced.¶

SAV-specific information can be various kinds of information on devices. Some examples are as follows:¶

• Forwarding information, e.g., preferred paths or forwarding next-hops. A device may need to consolidate forwarding information from multiple devices so as to discover real incoming directions of source addresses.¶
• Prefix information like hidden prefixes. Hidden prefixes may not appear in routing information but are carried as source addresses by legitimate data packets.¶
• SAV rules like <prefix, valid interfaces> entries. Devices can directly advertise SAV rules to other devices.¶

4. Intra-domain SAVNET Architecture

The proposed architecture is shown in Figure 1. In the architecture, there is a communication channel connecting two entities, i.e., Source Entity and Validation Entity. Source Entity is the information source and provides SAV-related information to Validation Entity. Validation Entity receives the information, generates SAV rules, and conducts validation. An entity can be a router, a server, or some other SAV-equipped devices. A device can act as a Source Entity, a Validation Entity, or both of them.¶

Source Speaker resides in Source Entity is responsible to communicate with Validation Speaker in Validation Entity through the communication channel. The communication channel may consist of several sessions for transmitting SAV-related information including routing information and SAV-specific information. In order to transmit SAV-specific information in the channel, a new SAV-specific protocol should be developed to carry the SAV-specific information. The SAV-specific protocol should define the data structure or format for communicating the SAV-specific information and the operations and timing for originating, processing, propagating, and terminating the messages which carry the information.¶

Under the incremental/partial deployment, not all devices support advertising SAV-specific information. So, complete SAV-specific information will not be available for the devices acting as Validation Entity. In the stage of incremental/partial deployment, routing information can be used as a supplement of SAV-specific information for SAV rule generation. That is why the advertisement of routing information is also included in the architecture.¶

SAV Agent in Validation Entity stores SAV-related information from Validation Receiver, consolidates the different types of information from all sources, and outputs SAV rules to the SAV table. The concrete structure of SAV Agent will be introduced later.¶

    +-------------------+             +-------------------+
    |   Source Entity   |Communication| Validation Entity |
    | +---------------+ |   Channel   | +---------------+ |
    | |  Source       +-----------------+  Validation   | |
    | |  Speaker      | |             | |  Receiver     | |
    | +-------+-------+ |             | +-------+-------+ |
    |         |         |             |         |         |
    |         |         |             |         |         |
    | +-------+-------+ |             | +-------+-------+ |
    | |  SAV-related  | |             | |  SAV          | |
    | |  Information  | |             | |  Agent        | |
    | +---------------+ |             | +---------------+ |
    +-------------------+             +-------------------+

    +--------------------+
    | Speaker/Receiver   |
    | +----------------+ |
    | |Management      <------------
    | |Speaker/Receiver| |         |
    | +----------------+ |         |
    | +----------------+ |         ---> Interact
    | |Routing Protocol<--------------> with other
    | |Speaker/Receiver| |         ---> speakers
    | +----------------+ |         |
    | +----------------+ |         |
    | |SAV-specific    | |         |
    | |Protocol        <------------
    | |Speaker/Receiver| |
    | +----------------+ |
    +--------------------+

                Messages from
                Validation Receiver
                    |
    +---------------|---------------+
    | SAV Agent     |               |
    | +-------------\/------------+ |
    | | SAV Information Manager   | |
    | | +-----------------------+ | |
    | | | SAV Information Base  | | |
    | | +-----------------------+ | |
    | +-------------+-------------+ |
    |               |               |
    |   SAV-related | information   |
    |               |               |
    | +-------------\/------------+ |
    | | SAV Rule Generator        | |
    | | +-----------------------+ | |
    | | | SAV Table             | | |
    | | +-----------------------+ | |
    | +---------------------------+ |
    +-------------------------------+

5. Use Cases

This section will present two use cases to show why the architecture can work better than existing SAV mechanisms. Figure 4 shows an example of intra-domain SAV. In the figure, Subnet1 and Subnet3 are single-homed to Router1 and Router2, respectively. Subnet2 is multi-homed to Router1 and Router2. Router3 connects to the Internet through two external interfaces. A typical deployment of existing SAV mechanisms is: Strict uRPF is deployed on interface '#' for validating packets from subnets, and ACL rules are configured at external interface '*' for blocking internal source addresses from the Internet.¶

+-----------------------------------------+
|               Internet                  |
+-----------------------------------------+
              |      |
              |      |
+-------------+------+--------------------+
| AS          |      |                    |
|       Intf.5|      |Intf.6              |
|           ┌─*──────*─┐                  |
|           │ Router 3 │                  |
|           └──────────┘                  |
|              /     \                    |
|             /       \                   |
|            /         \                  |
|   ┌──────────┐     ┌──────────┐         |
|   │ Router 1 │     │ Router 2 │         |
|   └──#─────#─┘     └─#─────#──┘         |
|Intf.1|Intf.2\ Intf.3/       \Intf.4     |
|      |       \     /         \          |
|      |        \   /           \         |
|   Subnet1    Subnet2           Subnet3  |
|                                         |
+-----------------------------------------+

6. Connectivity Models

This section presents some examples of connectivity models of the architecture. A combination of these models is also suitable to the architecture.¶

    +-----------------+
    | Source Entity 1 |---------
    +-----------------+         \
                                 \
    +-----------------+           \ +-------------------+
    | Source Entity 2 |-------------| Validation Entity |
    +-----------------+           / +-------------------+
            ...                  /
    +-----------------+         /
    | Source Entity n |---------
    +-----------------+

                                  +---------------------+
                        ----------| Validation Entity 1 |
                       /          +---------------------+
                      /
    +---------------+/            +---------------------+
    | Source Entity |-------------| Validation Entity 2 |
    +---------------+\            +---------------------+
                      \                      ...
                       \          +---------------------+
                        ----------| Validation Entity n |
                                  +---------------------+

    +-------------------+
    | Source Entity     |
    +-------------------+
              |
    +-------------------+
    | Validation&Source |
    | Entity            |
    +-------------------+
              |
    +-------------------+
    | Validation Entity |
    +-------------------+

7. Convergence Considerations

Network topologies may change sometimes and result in the change of SAV-related information. Convergence of the architecture is needed. Source Entity MUST advertise the updates of SAV-related information to Validation Entity in time. Then, Validation Entity MUST update local SAV rules immediately. Even so, there will still be delay of message delivery (sometimes re-transmission delay due to packet loss) and information processing. Therefore, during the convergence process, the SAV rules for checking packets are possibly inaccurate, which may result in severe false positive or too much false negative.¶

Existing routing information-based SAV mechanisms like strict uRPF is also faced with convergence problem. Inaccurate validation may appear during the convergence of routing, which is inevitable in practice. However, the proposed architecture involves SAV-specific Protocols that are especially for SAV. The convergence process can be slowed down due to the existence of SAV-specific Protocols.¶

The protocol for implementing the architecture MUST carefully consider the convergence problems, so that normal packet forwarding won't be impacted too much. There are some potential work directions for dealing with convergence problems:¶

• Taking full use of routing information. Routing information usually provides most of the SAV-related information for rule generation, and SAV-specific information is relatively a small set of information for supplementing missed information. Therefore, most of SAV rules can be updated during routing convergence if routing information is fully taken for rule generation.¶
• Advertising and processing the information first that will probably result in false positive. This is because false positive is more harmful to the network than false negative. It is reasonable to allocate more resources for eliminating false positive first.¶

8. Incremental/Partial Deployment Considerations

Although an intra-domain network mostly has one administration, incremental/partial deployment may still exist due to phased deployment or the limitations coming from multi-vendor supplement. Under incremental/partial deployment, if complete SAV-specific information is unavailable, SAV rules can be generated by combing available SAV-specific information and routing information.¶

The implementation of Validation Entity is RECOMMENDED to support flexible validation modes such as interface-based prefix allowlist, interface-based prefix blocklist, and prefix-based interface allowlist [I-D.huang-savnet-sav-table]. The first two modes are interface-scale, and the last one is device-scale. Under incremental/partial deployment, the device of Validation Entity SHOULD take on the proper validation mode according to the deploying of Source Entities. For example, if Validation Entity is able to get the complete set of legitimate source prefixes arriving at a given interface, interface-based prefix allowlist can be enabled at the given interface, and false positive will not exist.¶

In addition, the SAV filtering at the router can be also performed incrementally. The router can first take conservative actions on the validated data packets. That is to say, the router will not directly discard packet with an invalid result in the beginning of deployment. It can conduct sampling action for measurement analysis at first, and then conducts rate-limiting action or redirecting action for packets with invalid results. These conservative actions will not result in serious consequences under false positive validation results, while still providing protection for the network. Finally, filtering action is enabled only after confirming that there are no false positives.¶

9. Security Considerations

In many cases, an intra-domain network can be considered as a trusted domain. There will be no threats within the domain.¶

However, in some other cases, devices within the domain do not trust each other. Operators SHOULD be aware of potential threats involved in deploying the architecture. Typically, the potential threats and solutions are as follows:¶

• Entity impersonation.¶

  • Potential solution: Mutual authentication SHOULD be conducted before session establishment between two entities.¶
  • Gaps: Impersonation may still exist due to credential theft, implementation flaws, or entity being compromised. Some other security mechanisms can be taken to make such kind of impersonation difficult. Besides, the entities SHOULD be monitored so that misbehaved entities can be detected.¶

• Message blocking.¶

  • Potential solution: Acknowledgement mechanisms MUST be provided in the session between a speaker and a receiver, so that message losses can be detected.¶
  • Gaps: Message blocking may be a result of DoS/DDoS attack, man-in-the-middle (MITM) attack, or congestion induced by traffic burst. Acknowledgement mechanisms can detect message losses but cannot avoid message losses. MITM attacks cannot be effectively detected by acknowledgement mechanisms.¶

• Message alteration.¶

  • Potential solution: An authentication field can be carried by each message so as to ensure message integrity.¶
  • Gaps: More overhead of control plane and data plane will be induced.¶

• Message replay.¶

  • Potential solution: Authentication value can be computed by adding a sequence number or timestamp as input.¶
  • Gaps: More overhead of control plane and data plane will be induced.¶

When implementing the architecture in an extended protocol, the existing security mechanisms of the protocol can be taken.¶

10. Manageability Considerations

The architecture provides a general design for collecting SAV-related information and generating accurate SAV rules. Protocol-independent mechanisms SHOULD be provided for operating and managing SAV-related configurations. For example, a YANG data model for SAV configuration and operation is necessary for the ease of management.¶

SAV may affect the normal forwarding of data packets. The diagnosis approach and necessary logging information SHOULD be provided. SAV Information Base SHOULD store some information that may not be useful for rule generation but is helpful for management.¶

Messages carrying SAV-related information come from different protocol speakers. Each corresponding protocol SHOULD have monitoring and troubleshooting mechanisms, which is necessary for efficiently operating the architecture.¶

11. Privacy Considerations

The advertised SAV-related information mainly indicates the incoming directions of source prefixes. Devices under the architecture will learn more forwarding information of data packets.¶

An intra-domain network is mostly operated by a single organization or company, and the advertised information is only used within the network. Therefore, the architecture does not import critical privacy issues in usual cases.¶

The architecture makes the forwarding information in the network clearer, which can be helpful for network management such as fault diagnosis and traffic visualization.¶

12. IANA Considerations

This document has no IANA requirements.¶

13. Acknowledgements

Many thanks to the valuable comments from: Igor Lubashev, Alvaro Retana, Aijun Wang, Joel Halpern, Jared Mauch, Kotikalapudi Sriram, Rüdiger Volk, Jeffrey Haas, Xiangqing Chang, Changwang Lin, etc.¶

Authors' Addresses