Project

General

Profile

Actions

Bug #429

open

BLA: Frame with a new VLAN breaks broadcast for 30 seconds

Added by Linus Lüssing 24 days ago. Updated 24 days ago.

Status:
New
Priority:
Normal
Target version:
-
Start date:
11/28/2024
Due date:
% Done:

0%

Estimated time:

Description

A bridged-in host can DoS broadcast/multicast traffic on the according batman-adv node with a single packet every 30 seconds when BLA is enabled.

For that such a bridged-in host simply needs to transmit a frame with a new VLAN ID every 30 seconds.

Explanation:

Even though TT rejects unknown VIDs in batadv_interface_tx()->batadv_tt_local_add() BLA still processes it even earlier in batadv_interface_tx()->batadv_bla_tx() without rejecting it. When batadv_bla_tx() sees a new VID then it allocates a new backbone_gw with the own orig address and this new VID and increases bat_priv->bla.num_requests. This in turn fully blocks all broadcast/multicast traffic, no matter if tagged or not, in batadv_interface_tx()->batadv_bla_tx() here.

Reproducer:

Script:

  • bla-vlan-test.sh (requires mausezahn from the package netsniff-ng)
  • -> creates bat0 + bat1, connects them with a veth pair

Current behaviour/output:


$ ./bla-vlan-test.sh setup
# Waiting 30 seconds for initial BLA brodcast blocking to stop
$ timeout 30 ./bla-vlan-test.sh run
# Without background mausezahn ---
# Expecting continuous ICMPv6 Echo replies
PING ff02::1:ff33:4412%bat0 (ff02::1:ff33:4412%bat0) 56 data bytes
64 bytes from fe80::11:22ff:fe33:4412%bat0: icmp_seq=1 ttl=64 time=0.609 ms
64 bytes from fe80::11:22ff:fe33:4412%bat0: icmp_seq=2 ttl=64 time=1.47 ms
64 bytes from fe80::11:22ff:fe33:4412%bat0: icmp_seq=3 ttl=64 time=0.884 ms
64 bytes from fe80::11:22ff:fe33:4412%bat0: icmp_seq=4 ttl=64 time=1.04 ms
64 bytes from fe80::11:22ff:fe33:4412%bat0: icmp_seq=5 ttl=64 time=0.768 ms
64 bytes from fe80::11:22ff:fe33:4412%bat0: icmp_seq=6 ttl=64 time=0.997 ms
64 bytes from fe80::11:22ff:fe33:4412%bat0: icmp_seq=7 ttl=64 time=0.922 ms
64 bytes from fe80::11:22ff:fe33:4412%bat0: icmp_seq=8 ttl=64 time=0.778 ms
64 bytes from fe80::11:22ff:fe33:4412%bat0: icmp_seq=9 ttl=64 time=0.919 ms
64 bytes from fe80::11:22ff:fe33:4412%bat0: icmp_seq=10 ttl=64 time=1.13 ms
64 bytes from fe80::11:22ff:fe33:4412%bat0: icmp_seq=11 ttl=64 time=0.887 ms
64 bytes from fe80::11:22ff:fe33:4412%bat0: icmp_seq=12 ttl=64 time=1.02 ms
$ timeout 30 ./bla-vlan-test.sh run_broken
# With background mausezahn ---
# Expecting continuous ICMPv6 Echo replies
PING ff02::1:ff33:4412%bat0 (ff02::1:ff33:4412%bat0) 56 data bytes
64 bytes from fe80::11:22ff:fe33:4412%bat0: icmp_seq=1 ttl=64 time=0.874 ms
64 bytes from fe80::11:22ff:fe33:4412%bat0: icmp_seq=7 ttl=64 time=1.02 ms
$ ./bla-vlan-test.sh teardown

Expected behaviour/output:

  • The same, continuous output of replies no matter if mausezahn runs in the background or not.

Suggested Change?

Keep track of in flight BLA requests per VLAN per bat_priv, instead of just per bat_priv.

This would avoid that a bridged-in host could interfere / break broadcast traffic of other hosts with simply a single packet (every 30 seconds).


Files

bla-vlan-test.sh (1.48 KB) bla-vlan-test.sh Linus Lüssing, 11/28/2024 02:23 AM
Actions #1

Updated by Linus Lüssing 24 days ago

  • Subject changed from Frame with a new VLAN breaks broadcast for 30 seconds to BLA: Frame with a new VLAN breaks broadcast for 30 seconds
Actions

Also available in: Atom PDF