RARE user and assistance email list

["David Schmitz" <>]

Hi,

I still have some issues with the actual mitigation via Flowspec rules in 
freertr.

Probably I am missing something.


To explain the issues and to allow to reproduce them,
find attached a simple test case to demonstrate and reproduce the issues.
(java -Xmx1024m -jar /rtr/rtr.jar  test tester rtr-ddos1 path ./ temp ./ wait)

It consists of 3 routers: rtr1, host1, and host2.
rtr1 is supposed to perform the FlowSpec filtering of traffic between host1 and 
host2.

rtr1#show version 
freeRouter-rare v23.6.6-cur, done by .


interesting part of the config for rtr1 is:

router bgp4 1
...
 address-family unicast flowspec
 flowspec-install
 flowspec-advert flowspec-pmap"

policy-map flowspec-pmap
 sequence 10 action drop
 sequence 10 match access-group flowspec-rules
 !
 exit

access-list flowspec-rules
 sequence 50 permit 1 10.1.10.1 255.255.255.255 all 10.2.10.2 255.255.255.255 
all
 exit

-

The different issues I am experiencing based on this test case are demonstrated 
in 3 steps:

step 1)

As can be seen above,
the access-list "flowspec-rules" for policy-map "flowspec-pmap" defined by 
local config on rtr1 contains an initial rule: to block icmp traffic from 
10.1.10.1 (host1) to 10.2.10.2 (host2).

So, when the freertr test case rtr-ddos1.tst starts up, the filter rule
is installed as expected and actually also filterting the traffic correctly.
It is also nicely shown with "show policy-map flowspec":

host2# ping 10.1.10.1 vrf CORE
...

rtr1# show policy-map flowspec CORE ipv4
seq  chld  queue  intrvl  byt/int  rxb   rxp  trnsmt 
ace
1    0     0/128  100     0        192   3    tx=0(0) rx=0(0) drp=192(3) 
1-1 10.1.10.1 ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff all 10.2.10.2 
ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff all
2    0     0/128  100     0        5863  118  tx=5863(118) rx=0(0) drp=0(0)


But, if now the filter rule is removed by changing the config, this has no 
immediate effect on the "policy-map flowspec"
and the icmp traffic from host2 to host1 continues to being filtered:

rtr1# conf t
rtr1# access-list flowspec-rules
rtr1# no sequence 50 permit 1 10.1.10.1 255.255.255.255 all 10.2.10.2 
255.255.255.255 all
rtr1# do wr

rtr1# show policy-map flowspec CORE ipv4
seq  chld  queue  intrvl  byt/int  rxb   rxp  trnsmt 
ace
1    0     0/128  100     0        448   7    tx=0(0) rx=0(0) drp=448(7) 
1-1 10.1.10.1 ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff all 10.2.10.2 
ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff all
2    0     0/128  100     0        6357  127  tx=6357(127) rx=0(0) drp=0(0)

Am I maybe missing something here?


step 2) add exabgp peering

Now, the test case can be extended by using exabgp:

In addition to starting the freertr test case (java -Xmx1024m -jar /rtr/rtr.jar 
test tester rtr-ddos1 path ./ temp ./ wait),
some manual additional commands are executed to start exabgp:

# start process for tap1 interface manually  (connected to interface ethernet3 
of rtr1)
/rtr/tapInt.bin tap1 38200 127.0.0.1 38100 127.0.0.1 # running in foreground

# on another terminal:
ifconfig tap1 10.3.10.3/24

# to install exabgp: e.g. : apt-get install exabgp
# start exabgp: will BGP connect to rtr1 (10.3.10.10 on eth3) as 10.3.10.3 (on 
tap1)
exabgp --debug ./rtr-ddos1-exabgp1.conf

Interestingly, as soon as the peering between exabgp and rtr1 is working, the 
rule "sequence 50 permit 1 10.1.10.1 255.255.255.255 all 10.2.10.2 
255.255.255.255 all"
already above having been deleted from the "flowspec-rules"
without formerly having an effect on "policy-map flowspec" listing,
is now immediately gone from "policy-map flowspec":

rtr1# show policy-map flowspec CORE ipv4
seq  chld  queue  intrvl  byt/int  rxb   rxp  trnsmt 
ace
1    0     0/128  100     0        6357  127  tx=6357(127) rx=0(0) drp=0(0)

So, the change in the BGP connection status seems to cause an update of the 
"policy-map flowspec".


step 3) announce rule via exabgp

Going on, let's dispatch a FlowSpec rule from exabgp to rtr1 via BGP:

# example to announce a rule (same as in step 1) by local exabgp, exabgpcli 
announce flow route source-ipv4 10.1.10.1/32 destination-ipv4 10.2.10.2/32 
protocol =icmp

# for verification: show rules currently announced by local exabgp
exabgpcli show adj-rib out

The new rule announced is spread to rtr1, as shown in "show policy-map 
flowspec".
But the icmp traffic from host1 (10.1.10.1) to host2 (10.2.10.2) is not blocked 
at all,
which is also reflected in the drop counter staying at zero.


I also tried to further extend the scenario by adding another tap2 interface 
for rtr1 router and attaching an extra instance of exabgp peering with rtr1.
But with no success. Basically same issue, rules announced by exabgp are 
immediately listed under dynamic policy-map flowspec, but do not drop the 
traffic as expected. And unfortunately restarting the second exabgp instance in 
order to cause a bgp connection status within rtr1 do not help to remedy the 
situation unlike it helped at step 2 for locally emitted rules via 
policy-map/access-list defined by local config.

--

To sum it up:
- locally deleted rules (via policy-map/access-list defined in config) do not 
show up immediately after config change,
but only after a change of connection status of some BGP peering
(same seems to be happening with adding rules added via local 
policy-map/access-list)

- FlowSpec rules added via a peering of exabgp show up immediately in the 
dynamic "policy-map flowspec", but do not actually drop the traffic as 
expected.


What am I missing in the BGP config or somewhere else?


Thanks in Advance.


Best Regards
David


--

David Schmitz

Boltzmannstrasse 1, 85748 Garching
Telefon:   +49 89 35831-8765
Leibniz-Rechenzentrum, Germany
Mail:  


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#1371): https://groups.io/g/freertr/message/1371
Mute This Topic: https://groups.io/mt/99364239/6413194
Group Owner: 
Unsubscribe: https://groups.io/g/freertr/unsub []
-=-=-=-=-=-=-=-=-=-=-=-


neighbor 10.3.10.10 {
        router-id 10.3.10.3;
        local-address 10.3.10.3;
        local-as 3001;

        peer-as 1001;
        peer-address 10.3.10.10;

        #family {
        #    ipv4 unicast;
        #    #ipv4 multicast;
        #    #ipv4 nlri-mpls;
        #    #ipv4 mpls-vpn;
        #    #ipv4 flow;
        #    #ipv4 flow-vpn;
        #    #ipv6 unicast;
        #    #ipv6 flow;
        #    #ipv6 flow-vpn;
        #}

        #static {
        #        route 10.10.0.0/32 next-hop self;
        #        route 10.100.0.0/32 next-hop self;
        #}
}

Attachment: rtr-ddos1-host2-sw.txt
Description: Binary data

Attachment: rtr-ddos1-host1-sw.txt
Description: Binary data

Attachment: rtr-ddos1-sw.txt
Description: Binary data

!---------- rtr1 ----------

addrouter rtr1 extcfg ./rtr-ddos1-sw.txt
int eth1 eth 0000.0001.1111 $1a$ $1b$
int eth2 eth 0000.0001.2222 $2a$ $2b$
int eth3 eth 0000.0001.3336 127.0.0.1 38100 127.0.0.1 38200
!
!

!---------- host1 ----------

addrouter host1 extcfg ./rtr-ddos1-host1-sw.txt
int eth1 eth 0000.0002.1111 $1b$ $1a$
!
!

!---------- host2 ----------

addrouter host2 extcfg ./rtr-ddos1-host2-sw.txt
int eth1 eth 0000.0003.1111 $2b$ $2a$

!

proc tapint1 tapInt.bin tap1 38200 127.0.0.1 38100 127.0.0.1