Verification of Routes Using Region AuthorizationCAICTNo.52, Hua Yuan Bei RoadBeijing100191Chinashenchen@caict.ac.cnHuawei TechnologiesHuawei Campus, No. 156 Beiqing RoadBeijing100095Chinazhoutianran@huawei.comChina Mobile32 Xuanwumenxi Ave.Beijing100032Chinaliuyisong@chinamobile.comCAICTNo.52, Hua Yuan Bei RoadBeijing100191Chinayuwenyan@caict.ac.cnHuawei TechnologiesHuawei Campus, No. 156 Beiqing RoadBeijing100095Chinarainsword.wang@huawei.comHuawei TechnologiesHuawei Campus, No. 156 Beiqing RoadBeijing100095Chinazhuangshunwan@huawei.comHuawei TechnologiesHuawei Campus, No. 156 Beiqing RoadBeijing100095Chinachenshuanglong@huawei.com
Ops & Mgmt Area
SIDROPSRegion VerificationDraftBGP routing security is becoming a major issue that affects the
normal running of Internet services. Currently, there are many
solutions, including ROA authentication and ASPA authentication, to
prevent route source hijacking, path hijacking, and route leaking.
However, on an actual network, large ISPs with multiple ASes can use
carefully constructed routes to bypass ROA and ASPA authentication to
attack the target network.This document defines an region-based authentication method for large
ISPs with many ASes to prevent traffic hijacking within ISPs.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 2119.The design of the Border Gateway Protocol (BGP) lacks a mechanism to
validate BGP attributes, which is prone to BGP hijacking and BGP route
leaks . defines a method for verifying the origin of
BGP prefixes, which can resolve the most common source AS hijacking.
defines an AS-pairs
based authentication method to resolve AS-Path hijacking and route
leaking.However, even if these two technologies are deployed on large ISP
networks with many ASes, there are still risks of being attacked by
carefully constructed path hijacking.OV: Origin ValidationRPKI: Resource Public Key InfrastructureRP: Relying PartyRBA: Region Based AuthorizationCurrently, some large ISPs have more than one public ASes to
facilitate management. In these ISPs, only one or very few ASes are used
to connect to external ISPs. However, the sub-ASes of these ISPs also
exchange routes to provide services for different customers. Therefore,
the route access between these sub-ASes may still be subjected to a
well-crafted attack.As shown in the Figure 1. ISP1 has AS65001, AS65002, and
AS65003 and connects to an external ISP, such as AS65500. There is a
server connect to the AS65003, and a user connecte to the AS65002.
AS65003 advertises the server's route to AS65002, and AS65002 uses the
route to provide services for users.After the AS65500 obtains the route for the server, it can spoof
the route and change the source AS to AS65003. In this way, the
spoofed route is advertised to AS65001 with AS-Path AS65500 AS65003.
AS65001 selects routes between the routes advertised by AS65003 and
AS65500. Therefore, AS65001 may preferentially select the forged
routes of AS65500. As a result, subsequent traffic from users to the
server is hijacked to AS65500.IIn actual deployment, to facilitate traffic adjustment, the mask
of the address in the ROA database registered by ISP1 may be in a
certain range. In this case, the AS65500 can more easily hijack
traffic by using more specific prefixes and spoofing the source
AS.The scenario described here can be prevented by ASPA because the AS
pair (AS65500,AS65003) does not exist..As shown in Figure 2. ISP1 has AS65001, AS65002, and
AS65003 and connects to external ISPs, such as AS65500 and ISP2's
AS65104. ISP2 has AS65104, AS65105, and AS65106, and connects to
external ISPs such as AS65500 and ISP1's AS65001. There is a server
connect to AS65105, and a user connect to AS65002. AS65105 advertises
the server's route to AS65002 through the BGP peer. AS65002 then
provides services for users.The AS65500 can also obtain the route for the server from AS65104.
The AS65500 can spoof the route of the server and change the source AS
to AS65105. In this way, the AS65500 constructs a more specific
prefix, which AS-Path is AS65500 AS65104 AS65105, and advertises the
route to AS65001. The traffic from the user to the server will be
hijacked to AS65500.In this scenario it also can't be prevented by ASPA.An RBA is a digital signature object that contains two types of data.
One type is to bind multiple ASNs of an ISP to an region ID. The region
ID represents the ISP and is signed by the administrator of the ISP. The
RBA certifies which ASNs an ISP has. An AS should belongs to only one
ISP. The second type is to bind an ISP's region ID to a region
confederation ID, which is signed by the ISP's administrator. The region
ID and region confederation ID introduced here can be allocated and
managed by a unified structure.To solve this problem, a region-based verification is introduced.
This method is applicable to large ISPs with multiple ASes. In addition
to OV verification, region-based verification is performed to prevent
the attack scenarios mentioned in section 3.As shown in Figure 1, ISP1 can be set to area 1, including AS65001,
AS65002, and AS65003.When a device learns a route, it will verifie whether the route is
a local region route based on basic OV verification.The verification process is as follows:1) Perform OV verification on the route. If the OV verification
result is valid, then perform area verification.2) Check whether the route's origin AS is belong to local
region.3) If not, it indicates that the route is not a local region route.
No additional verification is required in single region
scenarios..4) If the route's origin AS is belong to local region, check
whether the peer that learns the route is belong to local region.5) If the peer that learns a route is not belong to local region,
the route verification result is invalid.If the route verification result is invalid, the route can be
consider as an invalid route and is not involved in route selection.
This prevents routes belong to local region from being learned by
external ASs and prevents possible route hijacking.For the case of Figure 2, region confederations can be set. ISP1 is
set to region 1, including AS65001, AS65002, and AS65003. ISP2 is set
to region 2, including AS65104, AS65105, and AS6. In addition, the
region of ISP1 and ISP2 form a regional confederation, which is set to
regional confederation 1.The verification process is as follows:1) First, perform the step of region verification. After single
region verification step 2, if the route's origin AS is not belong to
local region, then check whether the route belongs to the local
confederation.2) If the route belongs to the local confederation, check whether
the peer that learned the route is belong to the local
confederation.3) If the peer is not belong to the local confederation, the route
verification result is invalid.4) Optionally, further checking whether the peer is the region to
which the route belongs maybe done. If the region to which the route
belongs does not match the region to which the learned peer belongs,
the route may be considered as the lowest preference.If the route verification result is invalid, the route can be
consider as an invalid route and is not involved in route selection.
This prevents routes belong to local region from being learned by
external ASs and prevents possible route hijacking.The region information and region confederation information can be
obtained in either of the following ways:1) Obtained through the RP. When the region information is
registered through RPKI, it can be obtained through RP.2) Static configuration. When RP is not ready, this can be achieved
through manual configuration.Generally, the RPKI mode is recommended..The verification here can also be implemented through routing
policies.For region verification scenarios, regular expression-based
policies,such as denying all routes whose origin AS is the
local ISP's ASes, can be configured by the external peers to filter
routes. However, in this mode, complex policies need to be configured based
on the AS planning of the ISP. In addition, these policies need to be
integrated with existing routing policies, which is complex to
use.The RPKI mechanism can be used to verify the area information
obtained from the RP, which simplifies the deployment.NANA