Manual:CAPsMAN

Overview

Controlled Access Point system (CAPs) allows to centralize wireless network management and, if necessary, data processing. When using CAPs feature, network consists of number of Access Points (CAP) that provide wireless connectivity and manager (CAPs Manager) that manages AP configuration, takes care of client authentication and optionally data forwarding.

When CAP is controlled by Manager it only requires configuration that allows it to establish connection with Manager. Functions that were conventionally executed by AP (like access control, client authentication) are now executed by Manager. CAP merely takes care of wireless link layer encryption/decryption. Depending on configuration, data is either forwarded to Manager for centralized processing or forwarded locally at CAP.

CAPs Manager features

• RADIUS MAC authentication
• WPA/WPA2 security
• TBA

MISSING CAPs Manager features

• Nstreme AP support
• Nv2 AP support
• TBA

CAP to CAPs Manager Connection

To operate in CAP system and provide wireleless connectivity, CAP must establish management connection with CAPs Manager. Management connection can be established using MAC or IP layer protocols and is secured using DTLS.

CAP also establishes data connection with Manager, but data connection is not secured. If deemed necessary, other means to secure data need to be used, e.g. IPSec or encrypted tunnels.

CAP to CAPs Manager connection can be established using 2 transport protocols.

• MAC layer connection features:
  • no IP configuration necessary on CAP
  • CAP and Manager must be on the same Layer 2 segment - either physical or virtual (by means of L2 tunnels)
• IP layer (UDP) connection features:
  • can traverse NAT if necessary
  • CAP must be able to reach Manager using IP
  • if CAP is not on the same L2 segment as Manager, it must be provisioned with Manager IP address, because IP multicast based discovery would not work

In order to establish connection with Manager, CAP executes discovery process. During discovery CAP attempts to contact Managers and builds available Manager list. CAP attempts to contact available Managers using:

• configured list of Manager IP addresses
• list of Manager IP addresses obtained from DHCP server
• broadcasting on configured interfaces using both - IP and MAC layer protocols.

When list of available Managers is built, CAP selects Manager based on the following precedence list:

• Managers with MAC layer connectivity
• other Managers.

After Manager is selected, CAP attempts to establish DTLS connection. There are the following authentication modes possible:

• no certificates on CAP and Manager - no authentication
• only Manager is configured with certificate - CAP authenticates Manager
• CAP and Manager are configured with certificates - mutual authentication

CAP Configuration

When AP is configured to be controlled by Manager, configuration of selected wireless interfaces entered on AP is ignored. Instead, AP accepts configuration for selected wireless interfaces from Manager.

CAP behaviour of AP is configured in /interface wireless cap menu. It contains the following settings:

Property	Description
enabled (yes | no; Default: no)	Disable or enable CAP feature
interfaces (list of interfaces; Default: empty)	List of wireless interfaces to be controlled by Manager
certificate (certificate name | none; Default: none)	Certificate to use for authenticating
discovery-interfaces (list of interfaces; Default: empty)	List of interfaces over which CAP should attempt to discover Manager
static-caps-manager-addresses (list of IP addresses; Default: empty)	List of Manager IP addresses that CAP will attempt to contact during discovery
bridge (bridge interface; Default: none)	Bridge to which interfaces should be added when local forwarding mode is used

CAPs Manager Configuration Concepts

Each wireless interface on CAP that is under CAPs Manager control appears as virtual interface on CAPs Manager. This provides maximum flexibility in data forwarding control using regular RouterOS features, such as routing, bridging, firewall, etc.

Multitude of wireless interface settings are grouped in named groups (profiles) that simplifies the reuse of configuration - for example, common configuration settings can be configured in configuration profile and multiple interfaces can refer to that profile. At the same time any setting can be overridden directly in interface configuration for maximum flexibility.

Currently there are the following setting groups:

• channel - channel related settings, such as frequency and width
• datapath - data forwarding related settings, such as bridge to which particular interface should be automatically added as port
• interworking - IEEE 802.11u, Hotspot 2.0 related settings
• security - security related settings, such as allowed authentication types or passphrase
• configuration - main wireless settings group, includes settings such as SSID, and additionally binds together other setting groups - that is, configuration profile can refer to channel, security, etc. named setting groups. Additionally any setting can be overridden directly in configuration profile.

Interface settings bind together all setting groups, but additionally any setting can be overridden directly in interface settings.

By means of setting groups, configuration is organized in hierarchical structure with interface (actual user of configuration) as root. In order to figure out effective value of some setting this structure is consulted in a fashion where higher level setting value overrides lower level value.

For example, when WPA2 passphrase to be used by particular interface needs to be found, the following places are consulted and the first place with WPA2 passphrase configured specifies effective passphrase. "->" denotes referring to setting profile (if configured):

• interface passphrase
• interface->security passphrase
• interface->configuration passphrase
• interface->configuration->security passphrase

There are 2 types of interfaces on CAPs Manager - "master" and "slave". Master interface holds configuration for actual wireless interface (radio), while slave interface links to master interface and is intended to hold configuration for Virtual-AP (multiple SSID support). There are settings that are meaningful only for master interface, mainly hardware setup related settings such as radio channel settings. Note that in order for radio to be accepting clients, its master interface needs to be enabled. Slave interfaces will become operational only if enabled and master interface enabled.

Interfaces on CAPs Manager can be static or dynamic. Static interfaces are stored in RouterOS configuration and will persist across reboots. Dynamic interfaces exist only while particular CAP is connected to CAPs Manager.

CAPs Manager Global Configuration

Settings to enable CAPs Manager functionality are found in /caps-manager manager menu:

Property	Description
enabled (yes | no; Default: no)	Disable or enable CAPs Manager functionality
certificate (certificate name | none; Default: none)	Device certificate
require-peer-certificate (yes | no; Default: no)	Require all connecting CAPs to have valid certificate

Radio Provisioning

CAPs Manager distinguishes between CAPs based on identifier. Identifier is generated based on the following rules:

• if CAP provided certificate, identifier is set to Common Name field in certificate
• otherwise identifier is based on Base-MAC provided by CAP in form: '[XX:XX:XX:XX:XX:XX]'.

When DTLS connection with CAP is successfully established (which means that CAP identifier is known and valid), CAPs Manager makes sure there is no stale connection with CAP using the same identifier. Currently connected CAPs are listed in /caps-manager remote-cap menu:

[admin@CM] /caps-manager> remote-cap print
 # ADDRESS                                    IDENT           STATE               RADIOS
 0 00:0C:42:00:C0:32/27044                    MT-000C4200C032 Run                      1

CAPs Manager distinguishes between actual wireless interfaces (radios) based on their builtin MAC address (radio-mac). This implies that it is impossible to manage two radios with the same MAC address on one CAPs Manager. Radios currently managed by CAPs Manager (provided by connected CAPs) are listed in /caps-manager radio menu:

[admin@CM] /caps-manager> radio print
Flags: L - local, P - provisioned 
 #    RADIO-MAC         INTERFACE                               REMOTE-AP-IDENT
 0  P 00:03:7F:48:CC:07 cap1                                    MT-000C4200C032

When CAP connects, CAPs Manager at first tries to bind each CAP radio to CAPs Manager master interface based on radio-mac. If appropriate interface is found, radio gets set up using master interface configuration and configuration of slave interfaces that refer to particular master interface. At this moment interfaces (both master and slaves) are considered bound to radio and radio is considered provisioned.

If no matching master interface for radio is found, CAPs Manager executes provisioning rules. Provisioning rules is ordered list of rules that contains settings that specify what radio to match and settings that specify what action to take if radio matches. Provisioning rules are configured in /caps-manager provisioning menu:

[admin@CM] /caps-manager provisioning> print
Flags: X - disabled 
 0   radio-mac=00:00:00:00:00:00 action=create-enabled master-configuration=main-cfg 
     slave-configurations=virtual-ap-cfg 

Radio can be matched by provisioning rule based on the following settings:

• radio-mac - MAC address of radio, empty MAC (00:00:00:00:00:00) means match all MAC addresses
• TBA more matchers

Action to take if rule matches is specified by the following settings:

• action
  • create-disabled - create disabled static interfaces for radio, as a interfaces will be bound to radio, but radio will not be operational until interface will be manually enabled;
  • create-enabled - create enabled static interfaces, as a result interfaces will be bound to radio, and radio will be operational;
  • create-dynamic-enabled - create enabled dynamic interfaces, as a result interfaces will be bound to radio, and radio will be operational;
  • none - do nothing, leaves radio in non-provisioned state;
• master-configuration - if action specifies to create interfaces, new master interface with its configuration set to this configuration profile is created
• slave-configurations - if action specifies to create interfaces, new slave interface for each configuration profile in this list is created.

If no rule matches radio, implicit default rule with action create-enabled and no configurations set is executed.

For user's convenience there are commands that allow to re-execute provisioning process for some radio or all radios provided by some AP:

[admin@CM] > caps-manager radio provision 0

and

[admin@CM] > caps-manager remote-cap provision 0

Interface Configuration

CAPs Manager interfaces are managed in /caps-manager interface menu:

[admin@CM] > /caps-manager interface print          
Flags: M - master, D - dynamic, B - bound, X - disabled, I - inactive, R - running 
 #      NAME                                 RADIO-MAC         MASTER-INTERFACE                               
 0 M BR cap2                                 00:0C:42:1B:4E:F5 none                                           
 1   B  cap3                                 00:00:00:00:00:00 cap2                   

Datapath Configuration

Datapath settings control data forwarding related aspects. On CAPs Manager datapath settings are configured in datapath profile menu /caps-manager datapath or directly in configuration profile or interface menu as settings with datapath. prefix.

There are 2 major forwarding modes:

• local forwarding mode, where CAP is locally forwarding data to and from wireless interface
• manager forwarding mode, where CAP sends to CAPs Manager all data received over wireless and only sends out ver wireless data received from CAPs Manager. In this mode even client-to-client forwarding is controlled and performed by CAPs Manager.

Forwarding mode is configured on per-interface basis - so if one CAP provides 2 radio interfaces, one can be configured to operate in local forwarding mode and other in manager forwarding mode. The same applies to Virtual-AP interfaces - each can have different forwarding mode from master interface or other Virtual-AP interfaces.

Most of datapath settings are used only when in manager forwarding mode, because in local forwarding mode CAPs Manager does not have control over data forwarding.

There are following datapath settings:

• bridge -- bridge interface to which add interface as port when enabled
• bridge-cost -- bridge port cost to use when adding as bridge port
• bridge-horizon -- bridge horizon to use when adding as bridge port
• client-to-client-forwarding -- controls if client-to-client forwarding between wireless clients connected to interface should be allowed, in local forwarding mode this function is performed by CAP, otherwise it is performed by CAPs Manager.
• local-forwarding -- controls forwarding mode
• openflow-switch -- OpenFlow switch to which add interface as port when enabled
• vlan-id -- VLAN ID to assign interface if vlan-mode enables use of VLAN tagging
• vlan-mode -- VLAN tagging mode specifies if VLAN tag should be assigned to interface (causes all received data to get tagged with VLAN tag and allows interface to only send out data tagged with given tag)

Local Forwarding Mode

In this mode wireless interface on CAP behaves as normal interface and takes part in data forwarding. Wireless interface will accept/pass data to networking stack on CAP. CAPs Manager will not participate in data forwarding and will not process any of data frames, it will only control interface configuration and client association process.

Wireless interface on CAP will change its configuration to enabled and its state and some relevant parameters (e.g. mac-address, arp, mtu) will reflect that of interface on CAPs Manager. Note that wireless related configuration will not reflect actual interface configuration as applied by CAPs Manager:

[admin@CAP] /interface wireless> pr
Flags: X - disabled, R - running 
 0  R ;;; managed by CAPs Manager
      ;;; channel: 5180/20-Ceee/ac, SSID: master, local forwarding
      name="wlan2" mtu=1500 mac-address=00:03:7F:48:CC:07 arp=enabled 
      interface-type=Atheros AR9888 mode=ap-bridge ssid="merlin" 
      frequency=5240 band=5ghz-a/n channel-width=20/40mhz-eC scan-list=default
      ...

Virtual-AP interfaces in local forwarding mode will appear as enabled and dynamic Virtual-AP interfaces:

[admin@CAP] /interface> pr
Flags: D - dynamic, X - disabled, R - running, S - slave 
 #     NAME                                TYPE         MTU L2MTU  MAX-L2MTU
 ...
 2  RS ;;; managed by CAPs Manager
       ;;; channel: 5180/20-Ceee/ac, SSID: master, local forwarding
       wlan2                               wlan        1500  1600
 3 DRS ;;; managed by CAPs Manager
       ;;; SSID: slave, local forwarding
       wlan6                               wlan        1500  1600
 ...
[admin@CAP] /interface> wireless pr   
Flags: X - disabled, R - running 
 ...
 2  R ;;; managed by CAPs Manager
      ;;; SSID: slave, local forwarding
      name="wlan6" mtu=1500 mac-address=00:00:00:00:00:00 arp=enabled 
      interface-type=virtual-AP master-interface=wlan2 

The fact that Virtual-AP interfaces are added as dynamic, somewhat limits static configuration possibilities on CAP for data forwarding, such as assigning addresses to Virtual-AP interface. This does not apply to master wireless interface.

To facilitate data forwarding configuration, CAP can be configured with bridge to which interfaces are automatically added as ports when interfaces are enabled by CAPs Manager. This can be done in /interface wireless cap menu.

Manager Forwarding Mode

In this mode CAP sends all data received over wireless to CAPs Manager and only sends out over wireless data received from CAPs Manager. CAPs Manager has full control over data forwarding including client-to-client forwarding. Wireless interface on CAP is disabled and does not participate in networking:

 ...
 1 X  ;;; managed by CAPs Manager
      ;;; channel: 5180/20-Ceee/ac, SSID: master, manager forwarding
      name="wlan2" mtu=1500 mac-address=00:03:7F:48:CC:07 arp=enabled 
      interface-type=Atheros AR9888 mode=ap-bridge ssid="merlin" 
 ...

Virtual-AP interfaces also are created as disabled and do not take part in data forwarding on CAP.

Access List

Access list on CAPs Manager is ordered list of rules that is used to allow/deny clients to connect to any CAP under CAPs Manager control. When client attempts to connect to CAP that is controlled by CAPs Manager, CAP forwards that request to CAPs Manager. As a part of registration process, CAPs Manager consults access list to determine if client should be allowed to connect.

Access list rules are processed one by one until matching rule is found. Then action in particular rule is executed. If action specifies that client should be accepted, client is accepted, potentially overriding its connection parameters with ones specified in access list rule.

Access list is configured in /caps-manager access-list menu. There are the following parameters for access list rules:

• client matching parameters:
  • address - MAC address of client
  • mask - MAC address mask to apply when comparing client address
  • interface - optional interface to compare with interface to which client connects
  • time - time of day and days when rule matches
  • signal-range - range in which client signal must fit for rule to match
• action parameter - specifies action to take when client matches:
  • accept - accept client
  • reject - reject client
  • query-radius - query RADIUS server if particular client is allowed to connect
• connection parameters:
  • ap-tx-limit - tx speed limit in direction to client
  • client-tx-limit - tx speed limit in direction to AP (applies to RouterOS clients only)
  • client-to-client-forwarding - specifies whether to allow forwarding data received from this client to other clients connected to the same interface
  • private-passphrase - PSK passphrase to use for this client if some PSK authentication algorithm is used
  • radius-accounting - specifies if RADIUS traffic accounting should be used if RADIUS authentication gets done for this client
  • vlan-mode - VLAN tagging mode specifies if traffic coming from client should get tagged (and untagged when going to client).
  • vlan-id - VLAN ID to use if doing VLAN tagging.

Registration Table

Registration table contains list of clients that are connected to radios controlled by CAPs Manager and is available in /caps-manager registration-table menu:

[admin@CM] /caps-manager> registration-table print
 # INTERFACE                   MAC-ADDRESS       UPTIME                RX-SIGNAL
 0 cap1                        00:03:7F:48:CC:0B 1h38m9s210ms                -36

Examples

Create security profile for WPA2 PSK, without specifying passphrase:

[admin@CM] /caps-manager security>add name="wpa2psk" authentication-types=wpa2-psk encryption=aes-ccm

Create configuration profile to be used by master interface

• specify WPA2 passphrase in configuration
• specify channel settings in configuration:

[admin@CM] /caps-manager configuration> add name=master-cfg ssid=master security=wpa2psk
security.passphrase=12345678 channel.frequency=5180 channel.width=20 channel.band=5ghz-a

Create configuration profile to be used by virtual AP interface

• specify different WPA2 passphrase in configuration:

[admin@CM] /caps-manager configuration> add name=slave-cfg ssid=slave security=wpa2psk
security.passphrase=87654321

Create provisioning rule that matches any radio and creates dynamic interfaces using master-cfg and slave-cfg:

[admin@CM] /caps-manager provisioning> add action=create-dynamic-enabled master-configuration=master-cfg
slave-configurations=slave-cfg

Now when AP connects and is provisioned 2 dynamic interfaces (one master and one slave) will get created:

[admin@CM] /caps-manager interface> print detail 
Flags: M - master, D - dynamic, B - bound, X - disabled, I - inactive, R - running 
 0 MDB  name="cap1" mtu=1500 l2mtu=2300 radio-mac=00:0C:42:1B:4E:F5 master-interface=none 
        configuration=master-cfg 

 1  DB  name="cap2" mtu=1500 l2mtu=2300 radio-mac=00:00:00:00:00:00 master-interface=cap1 
        configuration=slave-cfg 

Consider that AP, that does not support configured frequency connects and can not become operational:

[admin@CM] /caps-manager interface> pr
Flags: M - master, D - dynamic, B - bound, X - disabled, I - inactive, R - running 
 #      NAME                                 RADIO-MAC         MASTER-INTERFACE                               
 0 MDB  ;;; unsupported band or channel
        cap3                                 00:0C:42:1B:4E:FF none    
 ...

We can override channel settings for this particular radio in interface settings, without affecting master-cfg profile:

[admin@CM] /caps-manager interface> set cap3 channel.frequency=2142 channel.band=2ghz-b/g