| Internet-Draft | BGP OPS for Inter-domain SAV | October 2023 |
| Song, et al. | Expires 9 April 2024 | [Page] |
This document attempts to present deployment considerations of source address validation using BGP protocol in inter-domain network.¶
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 9 April 2024.¶
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.¶
It is well known that internet routing security challenges include: route leaks, route prefix hijacking and source address spoofing. To address these challenges, Resource Public Key Infrastructure (RPKI) provides an approach to build a formally verifiable database of IP addresses and AS numbers as resources. And there are RPKI-based BGP Prefix Origin Validation (POV) (see [RFC7115]) and BGP AS path validation (see [I-D.ietf-sidrops-aspa-verification]) to mitigate route leaks. The Route Origin Authorization currently used for RPKI-ROA (see [RFC6811], [RFC9319]) prevents hijacking of route prefix. Unlike RPKI-based BGP ROA, POV or ASPA, Source Address Validation (SAV) is one feasible way to filter invalid address and mitigate source address spoofing attacks in the data plane.¶
To help reduce source address spoofing attacks in networks the feasible way is to validate whether the source address is spoofed or not. The security requirement is the ability to validate the accuracy of incoming interface of the traffic for specific IP address prefixes. More specifically, one router needs to validate that the incoming interface receiving the source IP address prefixes is in fact the right interface. This document describes a BGP validation mechanism to satisfy this security requirement in inter-domain networks.¶
As analyzed at [I-D.ietf-savnet-inter-domain-problem-statement], there are existing urpf-like mechanisms which describe an approach to build source address filtering. However, the urpf technologies may improperly permit spoofed traffic or block legitimate traffic. For example, strict uRPF (see [RFC3704]) technology is a simple way to implement and provides a very reasonable way to single-homing scenarios for ingress filtering. But in asymmetrical or multi-homing scenarios it brings wrong block for logic source address prefixes. Loose URPF [RFC3704] takes a looser validation mechanism than strict URPF to avoid improper block but may permit improperly spoofed source address. However, the urpf technologies may improperly permit spoofed traffic or block legitimate traffic. The FP-uRPF (see [RFC3704]) attempts to strike the banlance of the strict and loose uRPF but still has some shortcoming. The EFP-uRPF (see [RFC8704]) provides a more feasible way in overcoming the improper block of strict uRPF in asymetric routing scenario, but EFP-uRPF has not been implemented in practical networks yet.¶
The BGP validation mechanism introduced in this document aims to reduce false positives regarding invalid incoming interface, mitigate source address spoofing, resolve the inflexibility about directionality of strict-URPF to improve accuracy of source address validation in inter-domain networks. The deployment of Source Address Validation using BGP may have many operational considerations.¶
This document attempts to collect and present some operational and security considerations to deploy Source Address Validation on routers in inter-domain networks.¶
The Source Address Validation needs only be done by edge routers (or AS boarder routers) in a network and is deployed on current routers without significant hardware upgrades. The prefix-to-interface mapping method introduced in this document does not need to update current routers. The mapping policy should be used in boarder routers from other large networks (such as small stub, enterprise, edge networks, etc.).¶
The following terms in this document are used:¶
Based-on these definitions, any given IP address received from the traffic of one specific address prefix derived from a BGP route needs be verified locally using BGP validation method. The deployment for prefix-to-interface mapping policy on routers listed as the following:¶
An implementation should provide the ability to match the validation policy and set validation state of routes as part of its source address validation policy SAV function. The SAV function involves 2 characters: source address prefix and incoming interface.¶
The objectives of SAV function include (1) set prefix-to-interface mapping of BGP route prefix from BGP neighbor with the incoming interface as route policy deployed at the edge routers, (2) match the validation mapping policy and (3) decide the validation state for the source address. When the traffic of one specific address prefix received at one interface of the edge routers, the validation policy should be deployed and filtered the source address. And based-on the validation state the source address should be validated correctly.¶
The validation state is considered to include:¶
When the source address received of traffic which prefix derived from the BGP route is not matched with the incoming interface, the validation state is considered as "Invalid". Only the prefix matched with the incoming interface the validation state is set as "valid". Similarly, if no valid route be found its corresponding address packets should be discarded and its validation state should be set as "NotFound".¶
In terms of the URPF technologies may improperly permit spoofed traffic or block legitimate traffic, the URPF enhancements for solving limitations of strict URPF for inter-domain networks is mainly on improvement of ingress filtering accuracy in multi-homing scenarios.¶
The following figure 1 shows an example for Content Delivery Networks (CDN) service access to Service Provider Networks (SPN) through the Internet Service Provider (ISP) networks. For the ISPs are outside networks of SPN, the SPN needs to verify the validity of source address prefix of traffic received from ISPs. The CDN1 announces source prefix P1 to the ISP1 and ISP2, announces source prefix P2 to ISP1, and prefix P3 to ISP2. The POP1 (Point of Presence) is the point or infrastructure used for access of ISP1 and ISP2. The POP1 learns routes directly connected ISPs and some non-directly connected ISPs/CDNs from multiple ISPs. The set of routes learned from the same non-directly connected ISP is inconsistent but overlapped.¶
It's assumed that the prefix from ISPs in the following figure are trusted.¶
Prefix:A,B,D,F
+------------+
/---| ISP100 |---\
+---------+ / +------------+ \
| SP | / \ Prefix: A,B,C
| +----+ +----------+
| |POP1| | CDN1 |
| +----+ +----------+
+---------| \ +------------+ /
\---| ISP200 |---/
+------------+
Prefix:A,C,E,F
It's assumed that the POI for the prefix origin from ISP100 is set as 100, and POI for ISP200 is set as 200. The prefix-to-interface mapping rule shows as the table 1.¶
| Prefix | POI | Interface |
|---|---|---|
| A | 100,200 | 1,2 |
| B | 100 | 1 |
| C | 200 | 2 |
| D | 100 | 1 |
| E | 200 | 2 |
| F | 100,200 | 1,2 |
When the packets received in POP1 the source address is validated using prefix-to-interface mapping rule. For example, prefix A tagged with POI 100 and 200, respectively matched with Int1 and Int2 of POP1, so the packets of prefix A will be permitted to transit by Int1 and Int2. For prefix B tagged with POI 100 can only be permitted by Int1 according to the prefix-to-interface mapping rule. Similarly, the prefix F comes from both ISP1 and ISP2 will be permitted by Int1 and Int2.¶
The SAV actions table shows as table 2.¶
| Interface | Prefix | Action |
|---|---|---|
| 1 | A | Permit |
| 1 | B | Permit |
| 1 | C | Deny |
| 1 | D | Permit |
| 1 | E | Deny |
| 1 | F | Permit |
| 2 | A | Permit |
| 2 | B | Deny |
| 2 | C | Permit |
| 2 | D | Deny |
| 2 | E | Permit |
| 2 | F | Permit |
In this case, the prefix from the same origin (i.e., BGP neighbor) as a whole set is trusted and the prefix-to-interface mapping rule is applied to the incoming interfaces of traffic received for source validation in routers.¶
The following figure 2 shows an example of multipoint interconnection between multiple POP points and the same ISP. In this case, the set of routes learned from different POP points to the same ISP is inconsistent but overlapped.¶
+----------------------------------+
| ISP200 |
+----------------------------------+
| | |
| Prefix:A,C| |
Prefix:A,B| | |Prefix:A,B,C
+----+ +----+ +----+
+--|POP1|-------|POP2|-----|POP3|--+
| +----+ +----+ +----+ |
| \ | / |
| \ | / |
| \ | / |
| +---------------+ |
| | RR | |
| +---------------+ SP |
+----------------------------------+
In this case, the prefix-to-interface mapping rule shows as the table 3.¶
| Prefix | POI | Interface |
|---|---|---|
| A | 200 | 1,2,3 |
| B | 200 | 1,3 |
| C | 200 | 2,3 |
Through BGP method provided in this document, the SAV function is applied by BGP edge routers using prefix-to-interface rules to complete source address validation accurately. It's obvious that the BGP method described in section 4.1 and 4.2 improves the source address validation accuracy and overcomes the limitation of strict URPF method in multi-homing scenarios.¶
This document assumes the BGP route prefix origin is trusted. The validation to the origination Autonomous System (AS) of BGP routes is out of the scope of the document. The source address validation is selected for filtering invalid address or mitigating source address spoofing through validating the incoming interface of traffic received for one specific source prefix is in fact the right interface. The mapping policy as discussed in section 2 can be used to take action and based on the validation state to complete SAV function introduced in section 3 for address filtering.¶
The policies can be implemented include (1) identifying the route prefix advertised by different ISPs(i.e., BGP neighbors) as different POIs. (2) applying Prefix-to-Interface mapping rule to the BGP edge routers and process the Source Address Validation (SAV) function. (3) making the corresponding action based-on the validation state.¶
The validating router uses the result of source address validation to influence local policy in one network. In deployment, the policy should fit into the routers existing policy and allows a network to deploy incrementally or partially. The prefix-to-interface mapping rules used by the BGP edge routers are expected to be updated based-on the real network requirement.¶
The BGP method introduced in this document provides a feasible way to validate address of traffic received for one specific source prefix. In this document, the BGP route prefix in inter-domain network is considered as trusted. If there are invalid routes which are not matched with the current BGP route table should be blocked. The validation of origination AS of BGP routes is introduced in BGP POV document (see [RFC6811]). This document only attempts to verify the incoming interface is in fact the right interface for the source prefix. The detailed inter-domain SAV security please refer to [I-D.wu-savnet-inter-domain-architecture].¶
This document has no requests for IANA.¶
The authors would like to acknowledge Wei Yuehua, Xiao Min, Liu Yao, Zhou Fenlin for their thorough review and feedbacks.¶