A pool-operator in XAPI-based hypervisors (XenServer, XCP-ng) can disable Open vSwitch in-band management on any OVS bridge by writing vswitch-disable-in-band=true to Network.other_config. The value is passed through network_server.ml:1142-1155 to Ovs.create_bridge, which sets other_config:disable-in-band=true on the OVS bridge via ovs-vsctl. In-band management allows OVS to communicate with an SDN controller through the same network the bridge manages. Disabling it severs SDN controller connectivity when no out-of-band management path exists. The Network.other_config field has no map_keys_roles entries for infrastructure keys - only UI keys (folder, XenCenter.CustomFields.*, XenCenterCreateInProgress) are protected.
Network.other_config is a Map(String, String) field defined at datamodel.ml:1998-2007 with ~writer_roles:_R_POOL_OP. The vswitch-disable-in-band key is consumed by two code paths:
xcp-networkd at network_server.ml:1142-1155 reads the key during bridge creation and passes it to Ovs.create_bridge with ?disable_in_band:Some(Some "true").
openvswitch-config-update plugin at line 118 reads the key and applies it to the OVS bridge configuration.
The data flow:
pool-operator writes Network.other_config:vswitch-disable-in-band = "true"
|
v
XAPI stores to database (no validation)
|
v
network_server.ml:1142-1155 reads value during bridge creation
|
v
Ovs.create_bridge sets other_config:disable-in-band=true on OVS bridge
|
v
OVS disables in-band management on the bridge
The key is validated only for "true" or "false" string values in xcp-networkd, but XAPI performs no validation at write time. The impact depends on the deployment: environments relying on in-band SDN controller connectivity lose controller communication when the key is set.
Missing RBAC protection. Network.other_config has no map_keys_roles entries for infrastructure keys. The vswitch-disable-in-band key is writable by any pool-operator.
Missing write-time validation. XAPI stores the value without checking whether disabling in-band management is safe for the network's OVS configuration.
No impact assessment at write time. XAPI does not check whether an out-of-band management path exists before allowing in-band management to be disabled.
set_other_config RBAC bypass. The set_other_config method replaces the entire map atomically and bypasses map_keys_roles per-key checks.
| Scenario | Impact | Pre-conditions | Status |
|---|---|---|---|
| SDN controller disconnection | Controller loses connectivity to OVS bridge; flow table not updated | pool-operator, OVS bridge with SDN controller, no out-of-band path | Source-traced |
| Combined with NOC-2 fail-mode | In-band disabled + fail_mode=secure causes total traffic drop | pool-operator, OVS bridge with SDN controller | Modeled |
| BOC-1 chain | vm-admin disables in-band management across all bridges via RBAC collapse | vm-admin, BOC-1 | Source-traced |
fail_mode=secure (NOC-2) creates a complete network isolation condition. Without in-band management, the controller is unreachable; with secure fail mode, all traffic without explicit flow rules is dropped.Network.other_config for the vswitch-disable-in-band keydisable-in-band settingsdisclosure/vendor-detection-guidance.mdNetwork.other_config entries for the vswitch-disable-in-band keyother_config:disable-in-band stateAdd map_keys_roles protection. Restrict vswitch-disable-in-band to _R_POOL_ADMIN in datamodel.ml. This prevents pool-operators from modifying OVS management behavior.
Add impact assessment. Before allowing in-band management disablement, verify that an out-of-band management path exists for the SDN controller.
Upstream patches exist. They are held privately pending coordinated disclosure.
Disclosure:
datamodel.ml:1998-2007 (Network.other_config field definition), network_server.ml:1142-1155 (in-band management consumption), openvswitch-config-update:118 (OVS plugin consumption)disclosure/advisories/noc-security-advisory.md (NOC-5)research/investigations/network-other-config.mdDiscovered and reported by Jakob Wolffhechel, Moksha.