Due to a ransomware attack, the wiki was reverted to a July 2022 version. . We apologize for the lack of a more recent valid backup.
...
Note: Prefix deaggregation is effective for hijacks of IP prefixes less specific than /24, but it might not work for /24 prefixes or more specifics. This is because BGP advertisements of more specific than /24 prefixes are typically filtered by many ISPs, since it is considered as best practice to avoid the exponential increase of the size of the BGP routing table. We plan to address this problem through future extensions of ARTEMIS (e.g., collaborative mitigation).
Future plans: Despite the fact that ARTEMIS was first tested in a non-SDN environment with the basic mitigation strategy of automatic prefix deaggregation in mind, it can support several extensions related to its monitoring, detection and mitigation mechanisms due to its modular design. These extensions, e.g., employing MOAS (Multi-Origin AS Announcements) and tunneling in order to steer the hijacked traffic back to its legitimate owner during the mitigation phase, will also be researched as extra modules built over the ONOS platform. In parallel to the mitigation, an additional monitoring service is envisioned to provide real-time information about the mitigation process. This service can also use data from Periscope, RIPE RIS, BGPstream and BGPmon to monitor/visualize the mitigation.
JSON Configuration File
...
| Code Block | ||
|---|---|---|
| ||
"org.onosproject.artemis" : {
"artemis" : {
"prefixes" : [
{
"prefix" : "40.0.0.0/8",
"paths" : [
{
"origin" : 65004,
"neighbor" : [
{
"asn" : 65002,
"neighbor": [ 65001 ]
}
]
}
],
"moas" : [ ]
}
],
"frequency" : 3000,
"monitors" : {
"ripe" : [ ],
"exabgp": [ "192.168.1.2:5000" ]
}
}
} |
Explanation of Fields
...
prefix: a CIDR representation of the prefix that is monitored/protected.
paths: a list of dictionaries that contain the ASN of the protected AS(origin), along with a list of dictionaries for the neighbors.
neighbor: list of dictionaries that contain each neighbor's ASN and a list of ASNs for the neighbor's neighbor.
For example, in the demo topology the protected AS has origin ASN of 65004 and a neighbor with ASN 65002 who also has a neighbor with ASN 65001 (65004 - 65002 - 65001).moas: *in-progress*
...
Demo Topology
Figures 2 and 3 show the topology that is setup via the topo.py file inside the tutorial folder (TODO: set exact location). The BGP speakers are Quagga routers and the route collector is an ExaBGP router running a custom script to replicate the behavior of a RIPE route collector.
Fig. 2: The conceptual demo topology. Fig. 3: The full emulated demo topology.
AS65001
Intermediate AS that consists of a BGP speaker (R1), a L2 switch, a host (H1) and an ExaBGP Route Collector (RC).R1: Announces 10.0.0.0/8 and is a neighbor of AS65003 and AS65002. Also, it has the exaBGP RC as an iBGP neighbor and propagates BGP update messages to it.
ExaBGP RC: RC connected to R1 but also to the ONOS controller on the protected AS (in real world this connection is done through the underlying network; the only limitation is that the IP endpoint of ONOS should have a non-hijacked IP address so that the monitor can reach ONOS during the hijack).
H1 / 10.0.0.100: Host which is going to be communicating with the host inside the protected AS. It is used to provide us a visualization of the data-plane behavior when the BGP hijack occurs.
AS65002
Intermediate AS that consists of a BGP speaker (R2) that announces 20.0.0.0/8 and its purpose is to add an additional hop to the AS-PATH so that the protected AS can be hijacked. Although in the demo the attacker announces the exact prefix that belongs to the protected AS and not a more specific one, due to the shortest path attribute of the BGP best path selection algorithm, is able to steal the traffic.AS65003
Hijacker AS that consists of a BGP speaker (R3).R3: By announcing the prefix of the protected AS (40.0.0.0/8) from this BGP speaker, we trigger a BGP hijack, and all traffic generated from AS65001 and directed towards AS65004, will be redirected to the network of AS65003.
AS65004
Protected AS that is employing ONOS. It consists of a BGP speaker, an OVS switch, a host and the ONOS instance.R4: BGP speaker announcing 40.0.0.0/8. It is connected with his neighbor through the OVS switch which is configured by the SDN-IP application to talk with the BGP speaker of AS65002.
OVS: Talks with ONOS on a management interface via 192.168.0.0/24.
ONOS: ONOS is connected with the BGP speaker to retrieve the BGP routing table. Also, it receives the BGP update messages from the ExaBGP router. Also, it has a link with the OVS switch in order to interact with the data plane.
- H4 / 40.0.0.100: Host that receives traffic with the help of the reactive-routing application from the host in AS65001.
JSON Configuration File
The JSON Configuration File is the file that contains the required configuration entries to monitor prefixes and check the validity of neighbors and paths. The following code block shows an example of the JSON configuration format for ARTEMIS which is used in the Demo Topology.
| Code Block | ||
|---|---|---|
| ||
"org.onosproject.artemis" : {
"artemis" : {
"prefixes" : [
{
"prefix" : "40.0.0.0/8",
"paths" : [
{
"origin" : 65004,
"neighbor" : [
{
"asn" : 65002,
"neighbor": [ 65001 ]
}
]
}
],
"moas" : [ ]
}
],
"frequency" : 3000,
"monitors" : {origin
"ripe" : [ ],
"exabgp": [ "192.168.1.2:5000" ]
}
}
} |
Explanation of Fields
prefixes:List consisting of prefixes with their AS-PATH information and (optionally) legitimate MOAS ASes.
prefix: a CIDR representation of the prefix that is monitored/protected.
paths: a list of dictionaries that contain the ASN of the protected AS (origin), along with a list of dictionaries for the neighbors.
neighbor: list of dictionaries that contain each neighbor's ASN and a list of ASNs for the neighbor's neighbor.
For example, in the demo topology the protected (origin) AS65004 sees the AS65002 as a first-hop neighbor, and AS65001 as a second-hop neighbor (resulting in the legitimate announced path AS65004 - AS65002 - AS65001).
Note: While the operator can supply the origin and first-hop neighbor ASNs as ground-truth in the configuration, the N-hop (N > 1) neighbor information is planned to be generated automatically by ARTEMIS in future versions of the tool, based on the received BGP updates.moas: *in-progress*
frequency:Polling interval in milliseconds for the detection mechanism to check batches of BGP update messages (stored in the application cache). In the demo configuration file, it is set to check every 3s (3000ms).
monitors: List of the route collectors that ARTEMIS is using for monitoring. Currently it supports RIPE and ExaBGP route collectors through the socket-io interface, and is extendable to include more monitoring services/APIs.
RIPE Route Collectors have specific identifiers ("rrc17", "rrc18", "rrc19", "rrc20"). You can configure them following this example: "ripe" : ["rrc17", "rrc19"]
An ExaBGP Route Collector (RC) is implemented inside the tutorial folder (TODO: set exact location). You can host such an RC locally by running an ExaBGP instance with the exabgp.conf and server.py files provided (will require modifications in directory paths). In the demo topology we have an ExaBGP speaker running on 192.168.1.2:5000, monitoring the BGP control plane from the perspective of AS65001.
Note: The demo configuration also includes entries for the SDN-IP and the Reactive-Routing application (separate step, not shown in this demo). It specifies where the BGP speaker is located and which are the local prefixes
monitors: List of the route collectors that ARTEMIS is using for monitoring. Right now it supports RIPE and ExaBGP route collectors through socket-io, and is extendable to include more monitoring services.
RIPE Route Collectors have specific identifiers ("rrc17", "rrc18", "rrc19", "rrc20"). You can configure them following this example: "ripe" : ["rrc17", "rrc19"]
An ExaBGP route collector is implemented inside the tutorial folder. You can deploy it by running an ExaBGP instance with the exabgp.conf and server.py files provided (will require modifications in directory paths). In the demo topology we have an ExaBGP speaker running on 192.168.1.2:5000.
Note: The demo configuration also includes configuration for the SDN-IP and the Reactive-Routing application. It specifies where the BGP speaker is located and which are our local prefixes.
Demo Topology
The picture that follows shows the topology that is setup via the topo.py file inside the tutorial folder. The BGP speakers are Quagga routers and the route collector is an ExaBGP router running a custom script to replicate the behavior of a RIPE route collector.
AS65001
Intermediate AS that consists of a BGP speaker (R1), a L2 switch, a host (H1) and an ExaBGP Route Collector (RC).R1: Announces 10.0.0.0/8 and is a neighbor of AS65003 and AS65002. Also, it has the exaBGP RC as an iBGP neighbor and propagates BGP update messages to it.
ExaBGP RC: RC connected to R1 but also to the ONOS controller on the protected AS (in real world this connection is done through the underlying network; the only limitation is that the IP endpoint of ONOS should have a non-hijacked IP address so that the monitor can reach ONOS during the hijack).
H1 / 10.0.0.100: Host which is going to be communicating with the host inside the protected AS. It is used to provide us a visualization of the data-plane behavior when the BGP hijack occurs.
...
AS65003
Hijacker AS that consists of a BGP speaker (R3).
...
AS65004
Protected AS that is employing ONOS. It consists of a BGP speaker, an OVS switch, a host and the ONOS instance.
...
R4: BGP speaker announcing 40.0.0.0/8. It is connected with his neighbor through the OVS switch which is configured by the SDN-IP application to talk with the BGP speaker of AS65002.
...
OVS: Talks with ONOS on a management interface via 192.168.0.0/24.
...
ONOS: ONOS is connected with the BGP speaker to retrieve the BGP routing table. Also, it receives the BGP update messages from the ExaBGP router. Also, it has a link with the OVS switch in order to interact with the data plane.
...
.
Running the Demo
Install the ExaBGP Python library by doing these steps:
...