BGP Operations for Inter-domain SAV
draft-song-savnet-inter-domain-bgp-ops-02
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Xueyan Song , Chunning Dai , Shengnan Yue , Changwang Lin | ||
| Last updated | 2024-04-17 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-song-savnet-inter-domain-bgp-ops-02
SAVNET Group X. Song
Internet-Draft C. Dai
Intended status: Best Current Practice ZTE Corporation
Expires: 19 October 2024 S. Yue
China Mobile
C. Lin
New H3C Technologies
17 April 2024
BGP Operations for Inter-domain SAV
draft-song-savnet-inter-domain-bgp-ops-02
Abstract
This document attempts to present deployment considerations of source
address validation using BGP protocol in inter-domain network.
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 19 October 2024.
Copyright Notice
Copyright (c) 2024 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.
Song, et al. Expires 19 October 2024 [Page 1]
Internet-Draft BGP OPS for Inter-domain SAV April 2024
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
3. Prefix-to-Interface Mapping . . . . . . . . . . . . . . . . . 3
4. SAV Function . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Scalability . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Multi-homing Scenarios . . . . . . . . . . . . . . . . . . . 5
6.1. Scenario 1 . . . . . . . . . . . . . . . . . . . . . . . 5
6.2. Scenario 2 . . . . . . . . . . . . . . . . . . . . . . . 8
7. Implementation and Operation Considerations . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
11. Informative References . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
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
Song, et al. Expires 19 October 2024 [Page 2]
Internet-Draft BGP OPS for Inter-domain SAV April 2024
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.
2. Conventions
2.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Prefix-to-Interface Mapping
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 with hardware upgrades nor big software updates. The
mapping policy should be used in boarder routers (i.e., ASBR) from
other large networks (such as small stub, enterprise, edge networks,
etc.).
The following terms in this document are used:
Song, et al. Expires 19 October 2024 [Page 3]
Internet-Draft BGP OPS for Inter-domain SAV April 2024
1. Prefix: Has the content (IP address, prefix length), interpreted
as customary (see [RFC4632]).
2. Incoming Interface: The interface which received the traffic of
source route prefixes.
3. Route Prefix: The prefix derived from a route.
4. POI: A tag for IGP/BGP source Prefix Origin Identification (POI).
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:
1. Add Prefix Origin Identification (POI) to BGP route, the POI tag
can be set to BGP route prefix from BGP neighbors.
2. Create prefix-to-interface mapping policy and apply the policy to
the incoming interface of the source address received from the
packets of one specific address prefix.
3. When the source prefix is validated to be matched with the
incoming interface, the packets received are permit to transit;
if not, the packets received should be discarded or redirected to
other interfaces based-on the deployed route policy.
4. SAV Function
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:
* Valid: The address prefix of received traffic matches the incoming
interface.
* Invalid: The address prefix of received traffic does not match the
incoming interface.
* NotFound: The address prefix of received traffic is not found.
Song, et al. Expires 19 October 2024 [Page 4]
Internet-Draft BGP OPS for Inter-domain SAV April 2024
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".
5. Scalability
The POI policy can be deployed as different granularity to satisfy
scalability requirements for source address validation. The document
provides the following policies:
* AS level Prefix Origin Identification (AS POI): The AS number
information which can be obtained along the prefix advertisement
is used for SAV filtering policy.
* Community level Prefix Origin Identification (Community POI): The
policy uses BGP Community feature for source address validation.
It may require BGP extentions to carry the necessary POI
information.
* Router level Prefix Origin Identification (Router POI): This is
one practical way to reuse some of the existing fields to indicate
the directionality or location of the source packets belong to.
The policy suggests to use router-id as POI.
* Prefix level Prefix Origin Identification (Prefix POI): The policy
is the smallest filtering granularity for source address
validation. The traffic packets received at incoming interface of
BGP ASBR are validated by the POI. Considering the inter BGP
domains may be managed by different operators, the Prefix POI is
recommended be deployed as local policy.
6. Multi-homing Scenarios
6.1. Scenario 1
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
Song, et al. Expires 19 October 2024 [Page 5]
Internet-Draft BGP OPS for Inter-domain SAV April 2024
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
Figure 1: SAV Functions for CDN Multi-homing Scenario
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 is based-on AS level and is showed as the below 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 |
+--------+---------+-----------+
Table 1: Prefix-to-Interface
Mapping
Song, et al. Expires 19 October 2024 [Page 6]
Internet-Draft BGP OPS for Inter-domain SAV April 2024
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 |
+-----------+--------+--------+
Table 2: SAV Action
In this case, the prefix from the same origin (i.e., AS number) 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.
Song, et al. Expires 19 October 2024 [Page 7]
Internet-Draft BGP OPS for Inter-domain SAV April 2024
6.2. Scenario 2
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. This section provides 2 POI policies
apllied in AS-level and Router-level.
+----------------------------------+
| ISP200 |
+----------------------------------+
| | |
| Prefix:A,C| |
Prefix:A,B| | |Prefix:A,B,C
+----+ +----+ +----+
+--|POP1|-------|POP2|-----|POP3|--+
| +----+ +----+ +----+ |
| \ | / |
| \ | / |
| \ | / |
| +---------------+ |
| | RR | |
| +---------------+ SP |
+----------------------------------+
Figure 2: SAV Functions for Multiple POPs Access Scenario
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 |
+--------+-----+-----------+
Table 3: Prefix-to-
Interface Mapping
Song, et al. Expires 19 October 2024 [Page 8]
Internet-Draft BGP OPS for Inter-domain SAV April 2024
If AS POI applied in the case the traffic packets of prefix (i.e., A,
B and C in this example) received at POP1 from AS 200 are treated
from the same trusted source. If the POI policy replaced by router
POI the packets of prefix C will be filtered and processed as invalid
source address at POP1 in this example.
Through BGP method provided in this document, the SAV function is
applied by BGP edge routers (i.e., SAV validation node) using prefix-
to-interface rules to complete source address validation accurately.
It's obvious that the BGP method described in section 5.1 and 5.2
improves the source address validation accuracy and overcomes the
limitation of strict URPF method in multi-homing scenarios.
7. Implementation and Operation Considerations
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 3 can be used
to take action and based on the validation state to complete SAV
function introduced in section 4 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 following operational considerations applied to the BGP
validation mechanism:
* The BGP validation mechanism SHOULD support backward compatibility
with existing routers.
* The BGP validation mechanism SHOULD be hardware friendly, does not
require hardware upgrades nor big software updates.
* The BGP validation mechanism SHOULD comply with the routers
existing policies and allow for incremental and partial network
deployment.
Song, et al. Expires 19 October 2024 [Page 9]
Internet-Draft BGP OPS for Inter-domain SAV April 2024
* The BGP validation mechanism SHOULD support actual network
implement requirement.
8. Security Considerations
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].
9. IANA Considerations
This document has no requests for IANA.
10. Acknowledgements
The authors would like to acknowledge Wei Yuehua, Xiao Min, Liu Yao,
Zhou Fenlin for their thorough review and feedbacks.
11. Informative References
[I-D.ietf-savnet-inter-domain-problem-statement]
Li, D., Wu, J., Liu, L., Huang, M., and K. Sriram, "Source
Address Validation in Inter-domain Networks Gap Analysis,
Problem Statement, and Requirements", Work in Progress,
Internet-Draft, draft-ietf-savnet-inter-domain-problem-
statement-04, 19 March 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-savnet-
inter-domain-problem-statement-04>.
[I-D.ietf-sidrops-aspa-verification]
Azimov, A., Bogomazov, E., Bush, R., Patel, K., Snijders,
J., and K. Sriram, "BGP AS_PATH Verification Based on
Autonomous System Provider Authorization (ASPA) Objects",
Work in Progress, Internet-Draft, draft-ietf-sidrops-aspa-
verification-17, 29 February 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
aspa-verification-17>.
[I-D.wu-savnet-inter-domain-architecture]
Li, D., Wu, J., Huang, M., Chen, L., Geng, N., Liu, L.,
and L. Qin, "Inter-domain Source Address Validation
Song, et al. Expires 19 October 2024 [Page 10]
Internet-Draft BGP OPS for Inter-domain SAV April 2024
(SAVNET) Architecture", Work in Progress, Internet-Draft,
draft-wu-savnet-inter-domain-architecture-07, 4 March
2024, <https://datatracker.ietf.org/doc/html/draft-wu-
savnet-inter-domain-architecture-07>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March
2004, <https://www.rfc-editor.org/info/rfc3704>.
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
(CIDR): The Internet Address Assignment and Aggregation
Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August
2006, <https://www.rfc-editor.org/info/rfc4632>.
[RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R.
Austein, "BGP Prefix Origin Validation", RFC 6811,
DOI 10.17487/RFC6811, January 2013,
<https://www.rfc-editor.org/info/rfc6811>.
[RFC7115] Bush, R., "Origin Validation Operation Based on the
Resource Public Key Infrastructure (RPKI)", BCP 185,
RFC 7115, DOI 10.17487/RFC7115, January 2014,
<https://www.rfc-editor.org/info/rfc7115>.
[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>.
[RFC8704] Sriram, K., Montgomery, D., and J. Haas, "Enhanced
Feasible-Path Unicast Reverse Path Forwarding", BCP 84,
RFC 8704, DOI 10.17487/RFC8704, February 2020,
<https://www.rfc-editor.org/info/rfc8704>.
[RFC9319] Gilad, Y., Goldberg, S., Sriram, K., Snijders, J., and B.
Maddison, "The Use of maxLength in the Resource Public Key
Infrastructure (RPKI)", BCP 185, RFC 9319,
DOI 10.17487/RFC9319, October 2022,
<https://www.rfc-editor.org/info/rfc9319>.
Authors' Addresses
Song, et al. Expires 19 October 2024 [Page 11]
Internet-Draft BGP OPS for Inter-domain SAV April 2024
Xueyan Song
ZTE Corporation
China
Email: song.xueyan2@zte.com.cn
Chunning Dai
ZTE Corporation
China
Email: dai.chunning@zte.com.cn
Shengnan Yue
China Mobile
China
Email: yueshengnan@chinamobile.com
Changwang Lin
New H3C Technologies
China
Email: linchangwang.04414@h3c.com
Song, et al. Expires 19 October 2024 [Page 12]