Source Address
Validation in Inter-domain Networks (Inter-domain SAVNET) Gap Analysis,
Problem Statement, and RequirementsTsinghua UniversityBeijingChinajianping@cernet.edu.cnTsinghua UniversityBeijingChinatolidan@tsinghua.edu.cnTsinghua UniversityBeijingChinaqlc19@mails.tsinghua.edu.cnHuaweiBeijingChinahuangmingqing@huawei.comHuaweiBeijingChinagengnan@huawei.comSource Address Validation in Inter-domain Networks (Inter-domain
SAVNET) focuses on narrowing the technical gaps of existing source
address validation (SAV) mechanisms in inter-domain scenarios. This
document provides a gap analysis of existing inter-domain SAV
mechanisms, describes the problem statement based on the analysis
results, and concludes the requirements for improving inter-domain
SAV.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
when, and only when,
they appear in all capitals, as shown here.Source address validation in inter-domain networks (Inter-domain
SAVNET) is vital to mitigate source address spoofing between Autonomous
Systems (ASes). Inter-domain SAV is essential to the Internet security
. Many efforts have been taken on the tasks of
inter-domain SAV.Ingress filtering
is a typical method of inter-domain SAV. Strict uRPF reversely looks up the FIB table and requires that
the valid incoming interface must be the same interface which would be
used to forward traffic to the source address in the FIB table.
Feasible-path uRPF (FP-uRPF) , taking a looser
SAV than strict uRPF, is designed to add more alternative valid incoming
interfaces for the source address. To be more flexible about
directionality, BCP 84
recommends that i) the loose uRPF method which loses directionality
completely SHOULD be applied on lateral peer and transit provider
interfaces, and that ii) the Enhanced FP-uRPF (EFP-uRPF) method with
Algorithm B, looser than strict uRPF, FP-uRPF, and EFP-uRPF with
Algorithm A, SHOULD be applied on customer interfaces. Routers deploying
EFP-uRPF accept a data packet from customer interfaces only when the
source address of the packet is contained in that of the customer
cone.Despite the diversity of inter-domain SAV mechanisms, there are still
some points that are under considered but important for enhancing
Internet security. Moreover, in the currently focused SAV work scope,
these mechanisms may lead to improper permit or improper block problems
in some scenarios.This document does an analysis of the existing inter-domain SAV
mechanisms and answers: i) what are the technical gaps, ii) what are the
major problems needing to be solved, and iii) what are the potential
directions for further enhancing inter-domain SAV.SAV: Source Address Validation, i.e., validating the authenticity of
a packet's source IP address.SAV rule: The rule generated by intra-domain SAV mechanisms that
determines valid incoming interfaces for a specific source prefix.SAV table: The data structure that stores SAV rules on the data
plane. The router queries its local SAV table to validate the
authenticity of source addresses.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
permitted improperly due to inaccurate SAV rules.BCP 84 recommends loose uRPF at provider/peer interfaces and EFP-uRPF
at customer interfaces. The followings are the gap analysis of these SAV
mechanisms.Existing SAV mechanisms may have improper permit problems that the
packets with spoofed source addresses are considered as legal. Here
are two cases where improper permit will appear.The first case is at provider or peer interfaces where loose uRPF
is deployed. Loose uRPF almost accepts any source address, which
fails to protect ASes in the customer cone from externally injected
attacks.Figure 1 shows a reflection attack scenario. The arrow indicates
the direction of the commercial relationship between two ASes. AS 3
is the provider of AS 4. AS 4 is the provider of AS 1 and AS 2.
Assume AS4 has deployed inter-domain SAV. EFP-uRPF is deployed at AS
4's customer interfaces, and loose uRPF is implemented at AS 4's
provider interface. Assume a reflection attacker is attached to AS
3. It sends packets spoofing source addresses of P1 to the server
located in AS 2 for attacking the victim in AS 1. However, this
attack cannot be successfully blocked though AS 4 has deployed
inter-domain SAV.The second case is at customer interfaces where EFP-uRPF with
algorithm B is deployed. It allows packets with source addresses of
the customer cone to enter from any customer interfaces to avoid
potential improper block problems that EFP-uRPF with algorithm A may
have. However, vulnerability is imported. Although EFP-uRPF with
algorithm B can prevent ASes inside the customer cone from using
source addresses of ASes outside the customer cone, it compromises
the directionality of traffic from different customers, which will
lead to improper permit problems.In Figure 2, assume AS 4 implements EFP-uRPF with algorithm B at
customer interfaces. Under EFP-uRPF with algorithm B, AS 4 will
generate SAV rules with legitimate P1 and P2 at both customer
interfaces. When the attacker in AS 2 spoofs source address of AS 1,
AS 4 will improperly permit these packets with spoofed source
addresses of prefix P1. The same also applies when the attacker in
AS 1 forges source prefix P2. That is to say, EFP-uRPF algorithm B
cannot prevent ASes inside the customer cone from spoofing each
other.In some cases, existing inter-domain SAV mechanisms may improperly
block the packets with legitimate source addresses. Here are two cases
where improper permit will appear.Figure 3 presents a NO_EXPORT scenario. AS 1 is the common
customer of AS 2 and AS 3. AS 4 is the provider of AS 2. The
relationship between AS 3 and AS 4 is customer-to-provider (C2P) or
peer-to-peer (P2P). All arrows in Figure 2 represent BGP
advertisements. AS 2 owns prefix P2 and advertises it to AS 4
through BGP. AS 3 also advertises its own prefix P3 to AS 4. AS 1
has prefix P1 and advertises the prefix to the providers, i.e., AS 2
and AS 3. After receiving the route for prefix P1 from AS 1, AS 3
propagates this route to AS 4. Differently, AS 2 does not propagate
the route for prefix P1 to AS 4, since AS 1 adds the NO_EXPORT
community attribute in the BGP advertisement destined to AS 2. In
the end, AS 4 only learns the route for prefix P1 from AS 3.Assume that AS 3 is the customer of AS 4. If AS 4 runs EFP-uRPF
with algorithm A at customer interfaces, the packets with source
addresses of P1 are required to arrive only from AS 3. When AS 1
sends the packets with legitimate source addresses of prefix P1 to
AS 4 through AS 2, AS 4 will improperly block these packets.
EFP-uRPF with algorithm B works well in this case.Assume that AS 3 is the peer of AS 4. AS 4 will never learn the
route of P1 from its customer interfaces. So, no matter EFP-uRPF
with algorithm A or that with algorithm B are used by AS 4, there
will be improper block problems.Besides the NO_EXPORT case above, there are also many route
filtering policies that can result in interruption of BGP
advertisement. Improper block may be induced by existing
inter-domain SAV mechanisms in such cases, and it is hard to prevent
networks from taking these configurations.Anycast is a network addressing and routing methodology. An
anycast IP address is shared by devices in multiple locations, and
incoming requests are routed to the location closest to the sender.
Therefore, anycast is widely used in Content Delivery Network (CDN)
to improve the quality of service by bringing the content to the
user as soon as possible. In practice, anycast IP addresses are
usually announced only from some locations with a lot of
connectivity. Upon receiving incoming requests from users, requests
are then tunneled to the edge locations where the content is.
Subsequently, the edge locations do direct server return (DSR),
i.e., directly sending the content to the users. To ensure that DSR
works, servers in edge locations must send response packets with
anycast IP address as the source address. However, since edge
locations never advertise the anycast prefixes through BGP, an
intermediate AS with EFP-uRPF may improperly block these response
packets.Figure 4 shows a specific DSR scenario. The anycast IP prefix
(i.e., prefix P3) is only advertised from AS 3 through BGP. Assume
AS 3 is the provider of AS 4. AS 4 is the provider of AS 1 and AS 2.
When users in AS 1 send requests to the anycast destination IP, the
forwarding path from users to anycast servers is AS 1 -> AS 4
-> AS 3. Anycast servers in AS 3 receive the requests and then
tunnel them to the edge servers in AS 2. Finally, the edge servers
send the content to the users with source addresses of prefix P3.
The reverse forwarding path is AS 2 -> AS 4 -> AS 1. Since AS
4 never receives routing information for prefix P3 from AS 2,
EFP-uRPF algorithm A/EFP-uRPF algorithm B or other existing
uRPF-like mechanisms at AS 4 will improperly block the response
packets from AS 2.Misaligned incentive is often cited as a major reason why some ASes
do not deploy BCP38 . Specifically, BCP38 only
prevents the AS who deploys SAV from originating spoofed-source
traffic, but does not protect the AS from receiving spoofed-source
traffic or being the victim of source address spoofing attacks. As a
result, the costs of deploying SAV are paid by the AS itself, but the
benefits are experienced by the rest of the Internet.Compared with BCP38, the EFP-uRPF mechanism proposed in can protect the AS which deploys SAV from receiving
spoofed-source traffic from customer interfaces. However, the
combination of EFP-uRPF and loose uRPF validates upstream (i.e., the
packets from customers to providers) strictly but takes a loose
validation for downstream (i.e., the packets from providers/peers to
customers). It aims to prevent the customer cone from originating
spoofed-source traffic, but does not protect the customer cone from
receiving spoofed-source traffic or being the victim of attacks from
ASes outside the customer cone. Particularly, in the case of partial
deployment, even an AS as well as its provider deploy SAV following
the recommendations in , the AS may still
suffer source address spoofing attacks. For example, in the reflection
attack scenario in Figure 1, even if the victim network (i.e. AS1) and
its provider (i.e. AS4) deploy SAV, AS1 is still vulnerable to the
reflection attack from AS3, because it cannot help AS4 accurately
identify and reject the forged request from AS3. The victim network in
a reflection attack cannot gain additional protection even if it has
deployed existing SAV mechanisms.Overall, the combination of EFP-uRPF and loose uRPF makes a
significant improvement upon BCP38, but it is still not well-aligned
with the direct incentive that protects the AS which deploys SAV from
being the victim of source address spoofing attacks (especially
reflection attacks). A detailed discussion about misaligned incentive
can be found in .Existing inter-domain SAV mechanisms have accuracy gaps in some
scenarios like routing asymmetry induced by BGP route policies or
configurations. Particularly, EFP-uRPF takes the RPF list in
data-plane, which means the packets from customer interfaces with
unknown source prefixes (not appear in the RPF list) will be discarded
directly. Improper block issues will arise when legitimate source
prefixes are not accurately learned by EFP-uRPF. The root cause is
that these mechanisms leverage local RIB table of routers to learn the
source addresses and determine the valid incoming interface, which may
not match the real data-plane forwarding path from the source. It may
mistakenly consider a valid incoming interface as invalid, resulting
in improper block problems; or consider an invalid incoming interface
as valid, resulting in improper permit problems. Essentially, it is
impossible to generate an accurate SAV table solely based on the
router's local information due to the existence of asymmetric
routes.Existing inter-domain SAV mechanisms pay more attention to upstream
(traffic from customer to provider/peer), resulting in weak source
address checking of downstream (traffic from provider/peer to
customer). The "strict upstream but weak downstream checking" makes
the benefits of deploying SAV mainly flow to ASes outside the customer
cone. Moreover, the victim is still vulnerable to reflection attacks
even when it has deployed existing inter-domain SAV mechanisms,
because the victim with SAV deployment does not participate in
protecting its source addresses from being forged.Inter-domain SAVNET focuses on narrowing the technical gaps of
existing inter-domain SAV mechanisms. The new inter-domain SAV mechanism
MUST satisfy the following requirements.The new inter-domain SAV mechanism MUST ensure accurate SAV. It
MUST avoid the improper block problems of EFP-uRPF and minimize the
improper permit problems of existing inter-domain SAV mechanisms.
Generating SAV rules solely depending on local routing information
(e.g., RIB) results in inaccurate SAV in the case of asymmetric
routing. Accurate SAV requires that SAV rules MUST match real
data-plane paths. Therefore, to ensure the accuracy of SAV, extra
information out of local routing information is required as a
supplement.The new inter-domain SAV mechanism MUST provide direct incentives.
It would be attractive if the network who deploys SAV can protect
itself from source address spoofing attacks (especially reflection
attacks). In particular, the mechanism MUST work for both upstream and
downstream traffic, and downstream SHOULD be under the same SAV
criteria as upstream. It would be easy to achieve perfect all-round
protection supposing SAV is fully deployed. But when some ASes do not
deploy SAV, efforts are needed to narrow the gaps as much as
possible.The new inter-domain SAV mechanism MUST provide protection for
source addresses even the mechanism is partially deployed. It is
impractical to ensure that all the ASes or most of the ASes enable SAV
simultaneously. Partial deployment or incremental deployment have to
be considered during the work of SAV.The new inter-domain SAV mechanism MUST not modify data-plane
packets, which keeps same as existing inter-domain SAV mechanisms.
Existing architectures or protocols or mechanisms can be used in the
new SAV mechanism to achieve better SAV function.The new inter-domain SAV mechanism should work in the same scenarios
as existing inter-domain SAV mechanisms. Generally, it includes all
IP-encapsulated scenarios:Native IP forwarding: including both global routing table
forwarding and CE site forwarding of VPN;IP-encapsulated Tunnel (IPsec, GRE, SRv6, etc.): focusing on the
validation of the outer layer IP address;Both IPv4 and IPv6 addressesScope does not include:Non-IP packets: including MPLS label-based forwarding and other
non-IP-based forwarding.SAV rules can be generated based on route information (FIB/RIB) or
non-route information. If the information is poisoned by attackers, the
SAV rules will be false. Lots of legal packets may be dropped improperly
or malicious traffic with spoofed source addresses may be permitted
improperly. Route security should be considered by routing protocols.
Non-route information should also be protected by corresponding
mechanisms or infrastructure. If SAV mechanisms or protocols require
information exchange, there should be some considerations on the
avoidance of message alteration or message injection.The SAV procedure referred in this document modifies no field of
packets. So, security considerations on data-plane is not in the scope
of this document.This document does not request any IANA allocations.The Incentive Consideration for Defense Against Reflection
AttacksZhongguancun LaboratoryBeijingChinaLichen@zgclab.edu.cnZhongguancun LaboratoryBeijingChinagaofang@zgclab.edu.cn