Original Message:
Sent: May 08, 2024 09:31 AM
From: chulcher
Subject: Impact of enabling Enhanced PAPI Security feature
CPSec doesn't mitigate the issue, CPSec is tangential to the issue. The PAPI port is still open regardless of CPSec configuration, PAPI security is required to be enabled so that PAPI received is validated as legitimate.
PAPI security has to be configured through the MCR, I'd always start at the top and move down.
------------------------------
Carson Hulcher, ACEX#110
Original Message:
Sent: May 08, 2024 05:24 AM
From: davidrickard
Subject: Impact of enabling Enhanced PAPI Security feature
@chulcher Thank you for a very clear explanation, I have been struggling to get answers on this for some time and most posts end up unanswered or with vague outcomes. With regard to the security vulnerabilities that recommend enabling enhanced papi security with a non-default key, they never mention that CPSec makes this unnecessary. Do you think this is because although valid PAPI messages in a CPSec tunnnel are secure, it doesn't stop rogue messages beign received outside of the tunnel?
Also what the documentation doesn't seem to say is whether the order that we implement this is important - does it need to be done on the controllers first, then the MM or the other way round, or does it even matter, especially as you say, tunnelled messages don't use it.
Original Message:
Sent: May 01, 2024 04:56 PM
From: chulcher
Subject: Impact of enabling Enhanced PAPI Security feature
In my testing the enabling of PAPI Security, assuming CPsec is already enabled, has zero impact on the network. No bootstrap, no WLAN bounce, no client interruptions.
What enabling PAPI security does:
- If CPsec is enabled then PAPI security between MCR/MD/AP is basically ignored because all PAPI communications should already be within an encrypted tunnel
- If CPsec isn't enabled, the default PAPI security key (regardless of the configuration of a custom key) is used between AP and MD
- Between the MCR and MD the PAPI messages are always within the MCR/MD IPsec tunnels
- If you are utilizing the MCR/MC as a license server for a separate installation (MCR or standalone) then you need to make sure that the key used is common between all
- Enabling PAPI security instructs the devices to ignore PAPI packets with an incorrect key while also inserting said key into the packet for validation by other PAPI consumers (AirWave, ALE, etc.)
- You should enable "Validate PAPI Key" on AirWave in order to drop PAPI messages from untrusted sources
- "Validate PAPI Key" tells AirWave to start checking the key, otherwise any key, or lack of key, will be ignored
PAPI Security is not enabled by default in any version of AOS, regardless of what has been published in documentation previously.
Prior to AOS 8.9 there was a need to manually configure a static route to handle traffic flow for L2 redundant Mobility Conductor pairs (VRRP), with AOS 8.9 or later the route is added automatically.
ip route <MCR VRRP VIP> <host mask> ipsec <map-name, should be 'default-psk-redundant-conductor-ipsecmap'>
------------------------------
Carson Hulcher, ACEX#110
Original Message:
Sent: May 01, 2024 04:18 AM
From: christian.chautems@swisscom.com
Subject: Impact of enabling Enhanced PAPI Security feature
Hello,
I found conflicting information about the impact of enabling the Enhanced PAPI Security feature.
It is a workaround for ARUBA-PSA-2024-004 :: ArubaOS Multiple Vulnerabilities (Rev-1)
- Is there any impact (reboot or registering) of the existing APs when activating this feature
- On some posts it is mentioned that this feature will prevent provisioning of new APs , is it true ?
- On a MCs & MDs installation do we need to activate this feature also to the MCs or only on the MDs ?
Kind regards
Christian Chautems