Ipsec Design

Software Design Document (SDD)
Rev: A5-00
7 Mar 2017
Nokia Access Point Feature Development

Internet Protocol Security (IPSec)
VVDN Contact:
Name: Mathankumar Viswanathan
Contact: +91 9944396943
Email: [email protected]
NOKI_APFD Rev. A5-00
Revision History:
Date Rev No. Description By

16/12/2016 A1-01 Initial Draft VVDN
23/12/2016 A1-02 Updated the following sections VVDN
- Software Architecture Diagram
- IPSec interface(policy and routing ) creation
- Strongswan and IPSecMgr communication
- IPSecMgr and L2TunMgr communication
30/12/2016 A2-00 Updated the D4 Requirements from Nokia VVDN

9/1/2017 A3-00 Updated the D5 Requirements from Nokia VVDN
6/2/2017 A4-00 Updated the D6 and D7 Requirements from Nokia VVDN
7/3/2017 A5-00 Updated the review comments and Drop 10 updates VVDN
2
CONFIDENTIAL
Table of Contents
1. Introduction ...........................................................................................................................................................5
1.1 Purpose ..........................................................................................................................................................5
1.2 Product Overview ..........................................................................................................................................5
1.3 Scope of the Feature ......................................................................................................................................5
1.4 Feature Overview...........................................................................................................................................6
1.4.1 IPSec Overview ...................................................................................................................................7
1.4.2 Requirements Overview .................................................................................................................... 11
2. Architectural Design ............................................................................................................................................ 12
2.1 IPSec Application packages and NSS crypto driver .................................................................................... 14
2.1.1 Strongswan ........................................................................................................................................ 14
2.1.2 IPSecMgr Application ....................................................................................................................... 14
2.1.3 Modification of NWAM to process the IPSec configuration ............................................................ 14
2.1.4 Supported Algorithms ....................................................................................................................... 15
2.1.5 NSS Crypto Offload .......................................................................................................................... 15
3. AP Initialization with cWLC ............................................................................................................................... 16
3.1 Discover cWLC SecGW Parameters ........................................................................................................... 16
3.2 Sub-option formats in DHCP response ........................................................................................................ 21
3.2.1 Sub-option 127 - cWLC IP Address format ...................................................................................... 21
3.2.2 Sub-option 130 – cWLC Security Gateway Profile........................................................................... 22
3.3 Create cWLC IPSec with Primary / Secondary SecGW .............................................................................. 22
4. AP Connects with cWLC..................................................................................................................................... 24
5. WLAN IPSec Configuration from cWLC ........................................................................................................... 27
5.1 Required Configurations .............................................................................................................................. 27
5.1.1 IKE / IPSec Lifetime Calculation ...................................................................................................... 32
5.1.2 IKE / ESP Proposals .......................................................................................................................... 33
5.1.3 Peer Authentication Method .............................................................................................................. 34
5.1.4 Internal source IP/Virtual IP .............................................................................................................. 35
5.1.5 IKE DSCP ......................................................................................................................................... 35
5.1.6 IKE Cookies ...................................................................................................................................... 35
6. IPSec Interface (policy and routing) Configuration ............................................................................................. 35
7. IKE / IPSEC Tunnel Creation .............................................................................................................................. 38
7.1 Strongswan (Charon daemon) and IPSecMgr Communication ................................................................... 39
7.1.1 Message format ................................................................................................................................. 39
7.2 IPSec and L2TunMgr Communication ........................................................................................................ 40
7.2.1 Message format ................................................................................................................................. 40
8. IPC Messages between Nokia Applications ........................................................................................................ 40
3
CONFIDENTIAL
9. Re-keying Tunnel ................................................................................................................................................ 45

10. Dead Peer Detection (DPD) ............................................................................................................................. 45
10.1 Re-connecting to same PrimarySecGW ....................................................................................................... 46
10.2 Link Redundancy - Connecting to SecondarySecGW ................................................................................. 47
11. Perfect Forward Secrecy .................................................................................................................................. 48
12. Anti-Replay Protection and Extended Sequence Number (ESN) .................................................................... 48
13. NAT Traversal ................................................................................................................................................. 48
14. cWLC IPSec configuration via CLI ................................................................................................................. 49
14.1 Show cWLC IPSec configuration via CLI ................................................................................................... 49
14.2 Set / unset cWLC IPSec Configuration via CLI .......................................................................................... 50
14.2.1 SecGW Profile Configuration ........................................................................................................... 50
15. Performance Measurement Counters ............................................................................................................... 53
16. Assumption ...................................................................................................................................................... 54
17. References ....................................................................................................................................................... 54
18. ACRONYMS AND DEFINITIONS ............................................................................................................... 54
Table of Figures
Figure 1 - Nokia Access Point setup environment .........................................................................................................6
Figure 2 - AH Packet Format.........................................................................................................................................8
Figure 3 - ESP Packet Format .......................................................................................................................................9
Figure 4 - IKE_SA_INIT message exchange .............................................................................................................. 10
Figure 5- IKE_AUTH message exchange ................................................................................................................... 10
Figure 6 - CREATE_CHILD_SA message exchange ................................................................................................. 11
Figure 7 - Software Architecture Diagram .................................................................................................................. 13
Figure 8 – AP Boot up Process .................................................................................................................................... 16
Figure 9 – Discover cWLC IP and SecGW Profile via DNS/DHCP ........................................................................... 18
Figure 10 – cWLC IP Discovery process via DNS/DHCP .......................................................................................... 19
Figure 11 – Process IPSec information in DNS/DHCP ............................................................................................... 20
Figure 12 – cWLC SecGW Profile Validation from DNS/DHCP ............................................................................... 21
Figure 13 - Establish IPSec Connection with SecGW for cWLC communication ...................................................... 23
Figure 14 – AP Connection with cWLC ...................................................................................................................... 26
Figure 15 –Processing and validate IPSec Parameters from Registration Response and Set Priority Parameter
Request ........................................................................................................................................................................ 26
Figure 16 - IPSec configuration flow .......................................................................................................................... 28
Figure 17 – Sample IPSec config files......................................................................................................................... 31
Figure 18- Validation of WAN IPSec configuration ................................................................................................... 32
Figure 19 - IPSec tunnel creation flow ........................................................................................................................ 38
Figure 20- Rekeying IKE/IPSec SA flow .................................................................................................................... 45
Figure 21 – Re-Connecting to PrimarySecGW ........................................................................................................... 46
Figure 22- Link Redundancy Sequence flow............................................................................................................... 47
Figure 23 – show ipseccwlc command flow ................................................................................................................ 50
Figure 24 – set ipseccwlc command flow .................................................................................................................... 51
Figure 25 – unset ipseccwlc command flow ................................................................................................................ 52
Figure 26- CLI configuration flow .............................................................................................................................. 53
4
CONFIDENTIAL
1. Introduction
This document describes SW design details of IPSec Feature Development for Nokia Access Points.
This SDD is made for the reference of
• Product managers at VVDN/ NOKIA to confirm the SW design & Architecture before implementation.
• Engineering Team at VVDN for implementation and validation of IPSec Feature.
1.1 Purpose
The purpose of this document is to capture the software design details of IPSec feature implementation for Nokia
4x4 Access Point. Overview of IPSec and requirements provided by Nokia, AP IPSec initialization for cWLC
communication, IPSec tunnel creation, Re-keying the IPSec SA, DPD and NAT-T.
1.2 Product Overview

Nokia supports two variants of Access Points as below,
• Chipset for AP Product - AC200i (2x2), AC210m (2x2)

• SoC (System on Chip)
◦ Low End based of Scorpion SoC (QCA 9557/9550)
• Wi-Fi
◦ Peregrine QCA 9892 - 2x2/2s-80 (802.11ac)
• Memory
◦ 256 MB RAM, 128 MB Flash (NAND) + 1MB (NOR)
• Interfaces
◦ Gig Ethernet ports, PoE
• Support Indoor and Module which goes into FZM PiCo
• Chipset for AP Product - AC400i(4x4), AC400(4x4)

• SoC (System on Chip)
◦ High End based on Akronite SoC (IPQ 8065)
• Wi-Fi
◦ Support for Network Subsystem Cores
◦ Cascade QCA 9994 - 4x4 (802.11ac)
• Memory
◦ 512 MB RAM, 256 MB Flash (NAND) + 4MB (NOR)
• Interfaces
◦ 2 Gig Ethernet ports, PoE
• Support both Indoor and Outdoor
1.3 Scope of the Feature

Nokia Access Points(AP) are controller(cWLC) based solution to provide the network access to the end user via
Security Gateway(SecGW) and Wireless Access Gateway(WAG) as depicted in the below diagram,
5
CONFIDENTIAL
cWLC
Secondary
Without IPSec
SecGW
SecGW
Primary L2TPv3 / L2oGRE
SecGW Tunnel
IPSec Tunnel Secondary
SecGW
SecGW
WLANn
Nokia AP WAG
Primary
SecGW
Only one IPSec tunnel will be available with either

Primary or Secondary SecGW at anytime.
Figure 1 - Nokia Access Point setup environment
The cWLC control traffic and L2oGRE / Soft-L2TPv3 tunnel traffic between the AP and SecGW are plain
(unprotected) and need to be secured in order to provide the Integrity, authentication and confidentiality of the
tunnel traffic.
Following are the Scope of the IPSec Feature provided by Nokia,
• Support IPSec tunnel for user data plane between AP and SecGW.
• Support encrypted IPSec tunnel between AP and SecGW.
• Support Certificate and Pre-Shared Key (PSK) based authentication for IPSec end points
• Support NAT Traversal of IPSec tunnel between AP and SecGW.
• Support IPSec encapsulation of user data for L2oGRE and Soft-L2TPv3 mode.
• Support for disable radio transmission when IPSec tunnel is not active.
• Support configuration and troubleshooting of IPSec from AP CLI.
• Support PM pegs/statistics/alarms for IPSec Tunnel.
• Support detection of dead peer using DPD for,
◦ Reconnecting to same SecGW.
◦ Connecting to Secondary SecGW (backup tunnel).
• Support for,
◦ Perfect Forward Secrecy (PFS).
◦ Anti-Replay protection (Extended Sequence Number).
◦ Handling of MTU to accommodate IPSec header.
◦ QoS - DSCP.
◦ Emergency bypass.
1.4 Feature Overview
6
CONFIDENTIAL
This section covers the overview of IPSec and implementation of IPSec in Nokia Access Points.
1.4.1 IPSec Overview

The IP Security (IPsec) architecture comprises a suite of protocols (IKE, AH, ESP, etc) developed to ensure the
integrity, confidentiality and authentication of data communications over an IP network. Using IPsec, a secure
communication can be provided between client and server, between servers and between different networks. The
process involves hashing and ciphering of network packets.
Features of IPSec
• Offers Confidentiality - IPSec uses various encryption algorithms to keep data confidential and safe from
attackers.
• Data integrity - IPSec uses checksum/hashing (signature) algorithm to maintain integrity of the packet, at
receiver if the checksum/hashing fails, the packet is discarded.
• Authentication - The checksum/hashing will be done based on the pre-shared key and it provides the source
authentication.
• The security is maintained at Network (IP) Layer, all the traffic between two IPs can be protected
regardless of application/transport layer protocols.
1.4.1.1 Operating Modes

IPSec operates in two modes,
• Tunnel Mode – The entire IP packet (IP header and payload) is encrypted, authenticated and become the
payload for NEW IP packet after the IPSec header.
• Transport Mode – The Payload of the IP packet is encrypted, authenticated and the IPSec header will be
added in between the IP header and payload.
*Note – Payload is the combination of Transport layer Protocol (TCP, UDP, ICMP, etc.,) header and packet payload.
1.4.1.2 Protocols of IPSec
1.4.1.2.1 Internet Key Exchange
After IPSec configuration, the initiator and receiver try to build a secure tunnel between each other. The building of
this secure tunnel/connection is the job of IKE. IKE uses ISAKMP to exchange data between initiator and receiver
which defines the procedures for authenticating a communicating peer, creation and management of Security
Associations, key generation techniques.
ISAKMP defines packet formats to establish, negotiate, modify and delete Security Associations. It performs the
task of authenticating both end points, handling exchange of keys and manages keys afterward. Therefore, Security
Associations are established using the ISAKMP.
1.4.1.2.1.1 Security Association (SA)
An SA is a logical group of security parameters that enable the secured way of sharing data packets to another
entity.
An SA is a simplex (one-way channel) and logical connection which endorses and provides a secure data connection
between the network devices. Therefore, in normal bi-directional traffic, the flows are secured by a pair of Security
Associations. Each SA can be uniquely identified by following parameters, Security Parameter Index (SPI), IP
destination address and Security protocol (AH or ESP) identifier.
In order to decide what protection is to be provided for an outgoing packet, IPsec uses the Security Parameter Index
(SPI), an index to the security association database (SADB), along with the IP destination address in a packet
header, which together uniquely identify a security association for that packet. A similar procedure is performed for
an incoming packet, where IPsec gathers decryption and verification keys from the security association database.
7
CONFIDENTIAL
1.4.1.2.2 Authentication Header (AH)
AH is one of the two protocols which are used by IPsec for data communication. The features of AH are,
• AH provides connection integrity(truthfulness/accuracy) and data origin authentication for IP
datagrams
• AH provides protection against replay-attacks (One form of attack, where communication is recorded
and played back on later date, for example recording initial authentication and using it later with
different data). AH protect it using sequence number in its header.
• AH operates on top of IP using protocol no 51.
• Depend on how AH is going to be used, AH may be employed in two ways : Transport and Tunnel.
Figure 2 - AH Packet Format

• Transport mode – AH header is inserted after the IP header and before the transport layer protocol, e.g.,
TCP, UDP, ICMP, etc.
• Tunnel mode – the entire IP packet including IP header becomes the payload of the packet that is processed
with IPSec. A new IP header is created that contains IPSec Peer addresses, e.g., gateway IPs. The AH
header is inserted next to the New IP header.
1.4.1.2.3 Encapsulating Security Payload (ESP)
ESP is one of the two protocols which are used by IPsec for data communication. The features of AH are,
• ESP provides all services offed by AH along with data confidentiality.
• ESP operates directly on top of IP, using IP protocol no. 50.
• Depend on how ESP is going to be used; ESP can be employed in two ways: Transport and Tunnel.
8
CONFIDENTIAL
Figure 3 - ESP Packet Format

• Transport mode – ESP in Transport mode does not provide integrity and authentication for the entire IP
packet, in this mode ESP header is inserted after the IP header and before the transport layer protocol, e.g.,
TCP, UDP, ICMP, etc.
• Tunnel mode – In tunnel mode, the “inner” IP header carries the ultimate (IP) source and destination
addresses, while an “outer” IP header contains the address of IPSec “peers”, e.g., addresses of security
gateways. ESP protects the entire IP packet including the inner IP header. The position of ESP in tunnel
mode is relative to the outer IP header, is the same for ESP in transport mode.
1.4.1.3 IPSec Communication
The entire IPSec communication can be classified as -

1. Control communication which involves key exchange, security association negotiation, creation, deletion and
management of secure tunnels, dead peer detection, identifying NAT devices in the network, etc.
2. Data communication which ensures actual user data protection by encrypting payload involving different
authentication and cipher algorithms.
Before any data communication happens, a secure channel should be created between end parties using IKE
protocol. The open-source networking stack Strongswan (IKE daemon) is used for key-exchange purpose.
Strongswan is basically a keying daemon, which uses the Internet Key Exchange protocols (IKEv2) to establish
security associations (SA) between two peers. IKE provides strong authentication of both peers and derives unique
cryptographic session keys (called as IKE_SA). Besides authentication and key material IKE also provides the
means to exchange configuration information and to negotiate IPsec SAs.
IPsec SAs define which network traffic is to be secured and how it has to be encrypted and authenticated. Using
these negotiated security associations, the two end parties can start data communication. The IKE daemon monitors
and manages the created tunnel. The tunnel shall be terminated based on session expiry.
The actual IPsec traffic is not handled by strongswan but instead by the network and IPsec stack of the operating
system kernel. The strongswan establishes a communication path and sets up kernel stack informing what traffics to
secure and manages the same.
1.4.1.3.1 IKEv2 Message Flow

Strongswan performs mutual authentication between the two entities and establishes an IKE security association that
can be used to establish SAs for Encapsulating security payload (ESP) or Authentication header (AH). IKEv2 is the
latest version of the Internet Key Exchange.
All IKE communications consist of pairs of messages, a request and a response. This pair is called as a message
exchange. An entity which starts an exchange (or creates a request) is called initiator and the other entity is called a
responder. IKEv2 defines following four message exchanges for Internet Key Exchange.
• IKE_SA_INIT
• IKE_AUTH
• CREATE_CHILD_SA
• INFORMATIONAL
IKE_SA_INIT and IKE_AUTH forms the first four messages of IKE and are responsible for the creating the first
CHILD_SA which will be used by data plane for SA lookup. Once IKE_SA_INIT and IKE_AUTH are completed,
CREATE_CHILD_SA and INFORMATIONAL exchanges can come in any order.
1.4.1.3.2 IKE_SA_INIT
IKE_SA_INIT is used to exchange list of security association protocols supported by the entities, nonces and diffie-
hellman public value. The IKE_SA_INIT messages are shown below.
9
CONFIDENTIAL
Figure 4 - IKE_SA_INIT message exchange
• IKE Header contains the security parameter indexes (SPIs), version numbers, Exchange type, Message ID and
flags (to decide the initiator and responder).
• SA payload contains the list of IKE SA proposals which the entity supports. Proposals have proposal number
and they are ordered as per the priority.
• KE payload contains the diffie-hellman public value and group number which is essential to form the IKE
security association.
• Nonce payload contains the generated nonces from the respective entities.
• Notify Payload is used to provide notification to the other entity. Example of such notification is whether
fragmentation is supported or not, notifies payload can also be used to determine whether an entity is behind a
NAT or not.
• CERTREQ payload is used to place a request for the entity certificate.
1.4.1.3.3 IKE_AUTH
IKE_AUTH is used to authenticate the first message, assert the respective entity’s identity and create the first
CHILD_SA. All the payloads in the IKE_AUTH exchange is encrypted using the keys created during
IKE_SA_INIT exchange. The IKE_AUTH messages are shown below.
Figure 5- IKE_AUTH message exchange

• Identification payload (IDi and IDr) contains the identification data. Identification data can be an IP address
(either IPv4 or IPv6) or fully qualified domain name (FQDN) or an email address.
• CERT PAYLOAD is used to transmit the one entity certificate to the other entity.
• Each entity uses the AUTH PAYLOAD to protect the integrity of their respective IKE_SA_INIT exchange
messages.
• SA PAYLOAD in IKE_AUTH exchanges contains the list of IPSec SA proposals to create the child SA
between the two entities.
• Traffic Selector payload (TSi and TSr) is used to create security policy database for CHILD SA. TSi
specifies the source address from which the traffic will be forwarded from and TSr specifies the destination
address to which the traffic is forwarded.
10
CONFIDENTIAL
1.4.1.3.4 CREATE_CHILD_SA
CREATE_CHILD_SA exchange can be used to create new CHILD SA and to rekey SAs. An SA will be rekeyed
first and then it will delete the old one. Any entity can initiate the CREATE_CHILD_SA exchange.
Figure 6 - CREATE_CHILD_SA message exchange

1.4.1.3.5 INFORMATIONAL Exchange
At various points during the operation of an IKE SA, peers may desire to convey control messages to each other
regarding errors or notifications of certain events. To accomplish this, IKE defines an INFORMATIONAL
exchange. Informational exchange is used to delete an old IKE SA after rekeying, or to detect the dead peers, etc.
1.4.2 Requirements Overview
Below requirements provided by Nokia to support IPSec feature on AP,

• The Nokia AP supports three bearer modes,
◦ Local Breakout
◦ L2oGRE
◦ Soft-L2TPv3
• IPSec configuration will be available per WLAN if the Bearer mode is configured as either L2oGRE / Soft-
L2TPv3.
◦ If the bearer mode configured as L2oGRE / Soft-L2TPv3, the AP will create the L2oGRE / L2TPv3
tunnel to the WAG which can be reachable via SecGW and the IPSec tunnel to the SecGW and all the
tunneled traffic will be protected by IPSec till the security gateway.
• AP shall support only one IKE SA and one pair of unidirectional IPSec SAs (for bidirectional traffic) per
Security Gateway at all times.
• The traffic between AP and cWLC shall be over IPSec depends on the IPSec SecGW profile configuration
discovered via DNS/DHCP/Static/Set Priority Parameter.
• AP shall always initiate the request to establish IKE / IPSec SA and should not respond to the incoming
IKE / IPSec SA establishment requests.
Following are the Security parameters/protocols to be supported in this feature

• Security protocol – ESP
• Operation Mode – Tunnel mode
• Key Exchange mechanism – IKEv2
• Authentication - Certificate/pre-shared secret based
• Use IKEv2 Config payload feature to request internal IP address from Sec GW
• NAT-T (for NAT traversal)
• Crypto algorithms
◦ Encryption – 3DES-CBC, AES-128-CBC, AES-256-CBC, AES-128-CTR, AES-256-CTR, AES-128
GCM, AES-256 GCM, NULL
◦ Integrity - HMAC_SHA1_96, AES_XCBC_96, HMAC-SHA2-256-128, HMAC-SHA2-384-192
11
CONFIDENTIAL
◦ Diffie-Hellman exchange - group 19 (256-bit elliptic Group), group 20 (384-bit elliptic Group), group
14-18(MODP group). (transform type 4 (DH group) should not be sent in IKE_Auth message to
establish ESP SA)
◦ PRF - HMAC_SHA_256_OR_AES128_CBC_OR_HMAC_SHA1
• IKE/IPSec SA lifetime
• IPSec is a licensed FR.
• IPSec will be supported only on 4x4 models.
Note – the Qualcomm NSS crypto hardware engine will be used to encrypt/decrypt & authenticate the IPSec data
packet if the hardware supported algorithms are selected.
2. Architectural Design
This section describes the design flow of IPSec feature on Nokia AP. It includes software packages required for
IPSec feature, control path flow – how the configuration for IPSec feature coming from cWLC is processed,
maintained on AP as a separate module and modification needed on existing Nokia applications and the following
diagram shows the IPSec architectural design.
12
CONFIDENTIAL
cWLC
Primary / secondary
SecGW
Without IPSec
With IPSec
Nokia AP
UT PM ApGw WAGM
File System
CP FM NWAM CLI
Private Key
files
Heartbeat Strongswan
IPSecMgr
Manager config files
STRONGSWAN IPSec config

L2TunMgr
(IKE Daemon) files
Userspace
Security Policy and Association
Database
Kernel
LINUX Network Stack
NSS Supported
Algorithms
L2oGRE /L2TPv3 Cryptoapi CPU Crypto
Driver Driver Driver
NSS Crypto Ethernet

WIFI Driver Driver Driver
Hardware
NSS HW Engine
Radio Interface Crypto Ethernet Interfaces

NSS FW
Wifi0, Wifi1 Engine Eth0, Eth1
Wireless
Clients
Primary / secondary
SecGW
WAG
Figure 7 - Software Architecture Diagram

The IPSec tunnel (Policy and routing based) will be created with Primary / Secondary SecGW for cWLC
communication during initialization.
13
CONFIDENTIAL
IPSec tunnel (Policy and routing based) will be created with Primary / Secondary SecGW and The L2oGRE /
L2TPv3 tunnel (tap interface) is created between AP and WAG which can be reachable via SecGW for DATA
communication.
Uplink
• The user traffic from the STA is encapsulated with tunnel headers followed by IPSec encapsulation is
added.
• The IPSec will be terminated in SecGW and only the tunneled packet will be send to the WAG
Downlink
• SecGW sends the IPSec protected tunnel traffic to AP.

• AP terminates the IPSec and pass the packet to STA after processed by the tunnel layer.
2.1 IPSec Application packages and NSS crypto driver

The following software packages are required for IPSec support,
Applications - Strongswan IKE Daemon, IPSec Manager
Kernel Drivers - NSS Crypto Driver, Cryptoapi driver
*Note – ApGw application is the one which is going to communicate to cWLC over TLS and which is not mentioned in the
sequence diagram since there is no other modification in ApGw.
2.1.1 Strongswan
Strongswan is basically a keying daemon, which uses the IKEv2 to establish security associations (SA) between AP
and SecGW. The negotiation of IKE SA & IPSec SA creation , deletion, DPD, NAT server detection, maintain and
updating the Security Association details to Network stack will be taken care by the strongswan (charon ) daemon.
The actual IPsec traffic is not handled by strongswan but instead by the network and IPsec stack of the operating
system kernel.
The strongswan will send the event notification (Tunnel creation Failure / Success, Dead Peer is detected, etc.) to
IPSecMgr to indicate the tunnel status over socket communication.
Strongswan daemon/charon logs are stored in the charon.log file. This log will be added for log rotation and
snapshot process.
2.1.2 IPSecMgr Application

To maintain the IPSec related configuration from cWLC and communication with strongswan daemon, separate
application called “IPSec Manager (IPSecMgr)” will be maintained under Nokia Applications. IPSecMgr apply the
IPSec configuration received from NWAM and start the strongswan daemon to create the IPSec tunnel between AP
and configured SecGW.
After successful configuration, the IPSecMgr application process the tunnel notifications like, tunnel creation failed/
success, dead peer is detected, etc. from strongswan and update it to the Nokia Proprietary applications over socket
communication.
The IPSecMgr logs are stored in the /usr/log/WifiAPDebug log file.
2.1.3 Modification of NWAM to process the IPSec configuration

NWAM is the AP management application present in Nokia AP to process the AP management related traffic
coming from cWLC e.g. Registration, Software download, Configuration etc.
For IPSec feature requirement, the required configuration from cWLC (refer section 3 and section 5) as per SFS
requirements. Once cWLC push those IPSec related config parameters in the configuration messages to AP, NWAM
14
CONFIDENTIAL
process the same, store it locally on config structure and share that configuration with IPSecMgr application over
socket communication.
2.1.4 Supported Algorithms

The following encryption, authentication, PRF and DH algorithms are supported for IKE and ESP packet
processing,
IKE
The IKE encryption and authentication are done in the CPU.
Encryption – AES-CBC (128 & 256), AES-CTR (128 & 256), 3DES_CBC and AES-GCM (128 & 256)
Integrity – HMAC_SHA2_256, HMAC_SHA2_384, HMAC_SHA1 and AES_XCBC
ESP
Some of the ESP encryption and authentication are done by NSS crypto hardware engine (refer next section) and the
remaining are done in the CPU.
Encryption – NULL, AES-CBC (128 & 256), AES-CTR (128 & 256), 3DES_CBC and AES-GCM (128 & 256)
Integrity – HMAC_SHA2_256 and HMAC_SHA1
Pseudo Random Function (PRF) – HMAC_SHA2_256, AES_XCBC, HMAC_SHA1
Diffie-Hellman (DH) - ECP256 (group 19), ECP384 (group 20), MODP8192 (group 18), MODP6144 (group 17),
MODP4096 (group 16), MODP3072 (group 15), MODP2048 (group 14) and MODP1024 (group 2)
2.1.5 NSS Crypto Offload

The IPQ8065 (akronite processor) SOC has in NSS crypto engine to offload the encryption/decryption and
authentication of IPSec packet. The IKE packets will be encrypted/decrypted in CPU and only the IPSec packet will
get offloaded to crypto engine, the following kernel module drivers provided by qualcomm in the IPQ3.0 SDK are
required to achieve the NSS crypto offload,
• NSS driver (qca-nss-drv.ko) –used to configure the NSS crypto engine

• Core crypto driver (qca-nss-crypto.ko) – used as core crypto driver to communicate to the crypto engine.
• cryptoapi driver (qca-nss-cfi-cryptoapi.ko) – used to register with kernel crypto driver and perform the
Enc./Dec. with authentication of packets.
The following algorithms will be supported by the crypto engine,
Encryption Algorithms - 3DES_CBC, AES_CBC (128 and 256) and AES_CTR (128 and 256)
Integrity Algorithms - HMAC_SHA1 and HMAC_SHA2_256
The crypto core driver supports only the AEAD (cipher and Authentication) method and the cryptoapi support only
the following algorithms,
• 3DES_CBC – HMAC_SHA1
• 3DES_CBC – HMAC_SHA2_256
• AES_CBC(128 and 256) – HMAC_SHA1
• AES_CBC(128 and 256) - HMAC_SHA2_256
*Note – the AES_CTR (128 and 256)-HMAC_SHA1 and AES_CTR (128 and 256)-HMAC_SHA2_256 support is not available in the
current cryptoapi driver and FR is raised to qualcomm add this support.
The cryptoapi driver register the supported algorithms with the kernel and kernel offload the packets to crypto
engine to perform the ciphering and hashing of the packet for the crypto engine and cryptoapi driver supported
algorithms otherwise kernel will use the CPU crypto driver to perform the ciphering and hashing.
15
CONFIDENTIAL
3. AP Initialization with cWLC

The follow flow chart explains the AP boot up procedure and the flow is explained in the sub topics,
Figure 8 – AP Boot up Process
3.1 Discover cWLC SecGW Parameters

Following are the factory default IPSec configurations which will be used to make the IPSec connection with
SecGW for cWLC communicatoin,
• WiFiAP.Default.IKEEncryptionMethod -
16
CONFIDENTIAL
oAES_128_GCM_OR_AES_256_GCM_OR_AES_128_CTR_OR_AES_256_CTR_OR_AES_1
28_CBC_OR_AES_256_CBC_OR_3DES_CBC
• WiFiAP.Default.IKESAMaxLifetime - 86400(sec)
• WiFiAP.Default.IPSecEncryptionMethod
o AES_128_GCM_OR_AES_256_GCM_OR_AES_128_CTR_OR_AES_256_CTR_OR_AES_1
28_CBC_OR_AES_256_CBC_OR_3DES_CBC
• WiFiAP.Default.IPSecSAMaxLifetime - 43200(sec)
• WiFiAP.Default.DPDDelayTime - 20 (sec)
• WiFiAP.Default.IKERetransmitTries - 5
• WiFiAP.Default.IKERetransmitTimeout - 4(sec)
• WiFiAP.Default.IKERetransmitBase - 2
• WiFiAP.Default.IKERetryInitiateInterval - 300
• WiFiAP.Default.IKEDSCPTag - 46
• WiFiAP.Default.EnablePerfectFwdSecrecy - 0 (Disabled)
• WiFiAP.Default.EnableAntiReplayCheck - 1 (Enabled)
• WiFiAP.Default.AntiReplayWindowSize - 1024
• WiFiAP.Default.NATKeepaliveTime - 40(sec)
• WiFiAP.Default.RequestInternalSrcIP - 1(Yes)
The following required IPSec config parameters used to make cWLC IPSec connection will be discovered either
Dynamic (via DNS / DHCP) or Static (Via CLI) depending upon the ApIpDiscoveryMode.
• cWLCIP.
• PrimarySecGWIP.
• SecondarySecGWIP.
• InternalSrcIP.
• PeerAuthMethod.
• PreSharedSecret.
The PrimarySecGWIP, SecondarySecGWIP, InternalSrcIP and PeerAuthMethod parameters

will be stored / maintained in /etc/config/ApIpConfig file and ENV to retain across reboots.
The PreSharedSecret will be encrypted and stored / maintained in /etc/config/.presharedsecret-

ctrl-(1or 2) file to retain across reboots.
If the ApIpDiscoveryMode is AP_DYNAMIC_CTRL_STATIC or AP_STATIC_CTRL_STATIC, the above

parameters will be updated statically via CLI. (Refer cWLC IPSec configuration via CLI )
If the ApIpDiscoverMode is AP_DYNAMIC_CTRL_DYNAMIC (0) then the AP sends DHCP Discovery with
“NokiaWiFi” as Vendor specific data (option 60) then the DHCP server will send the vendor related parameters in
the DHCP ACK response after completion of DHCP process and the above SecGW profile parameter will be
discover either from DNS or DHCP response as follows,
17
CONFIDENTIAL
Figure 9 – Discover cWLC IP and SecGW Profile via DNS/DHCP

Note – the IPSec is enabled check is decided based on the Valid Primary SecGW IP and Controller IPSecFlag
maintained in file /etc/config/.APSetPriorityParameter.conf.validated where the controller
profile get stored.
18
CONFIDENTIAL
Figure 10 – cWLC IP Discovery process via DNS/DHCP
19
CONFIDENTIAL
Figure 11 – Process IPSec information in DNS/DHCP
20
CONFIDENTIAL
Figure 12 – cWLC SecGW Profile Validation from DNS/DHCP
3.2 Sub-option formats in DHCP response

The sub-options provide the corresponding vendor required data in the following format,
<sub-option code> + Length + Value
3.2.1 Sub-option 127 - cWLC IP Address format

sub-option code – 127 (decimal)
Length - number of IP addresses x 4 (IPv4)
Value – IP address(es)
Notes: For ex. if 2 cWLC IP address has to be configured, depending on DHCP server configuration can be depicted
as below-
7F:08:0A:44:43:3d:0A:53:4e:20;
7f080A44433d0A534e20
Option cwlc-ips “10.68.67.61,10.83.78.32”
21
CONFIDENTIAL
3.2.2 Sub-option 130 – cWLC Security Gateway Profile

sub-option code – 130 (decimal)
Length - bytes
Value – <cWLC IP address><;><Primary SecGW IP address><;>[Secondary SecGW IP address]<;>[InternalSource

IP address]<;><PeerAuthMethod (0 or 1)><;>[Encrypted Preshared secret value]<|><Alternate cWLC IP
address><;><Primary SecGW IP address><;>[Secondary SecGW IP address]<;>[InternalSource IP
address]<;><PeerAuthMethod (0 or 1)><;>[Encrypted Preshared secret value]
PeerAuthMethod values:
0 - Certificate
1 - Pre-shared secret
'Secondary SecGW IP address' and 'Internal Source IP Address' are optional. Preshared secret should be in BASE64
encoded encrypted format and set only when PeerAuthMethod is set to '1'.
Maximum 4 SecGW profiles will be supported while discovering via DNS / DHCP.
3.3 Create cWLC IPSec with Primary / Secondary SecGW

The following diagram shows the IPSec establishment sequence with SecGW for cWLC communication,
22
CONFIDENTIAL
IPSec establishment with

cWLC’s SecGW
Try Again IPSec YES Close the existing IPSec

Create Tunnel
NO
secSecGW available and

primaryIPSecAtte YES YES
secondaryIPSecAttempt
mptStatus != true
Status != true?
NO NO
NO secSecGW available and sgwType = PRIMARY sgwType = BOTH

F secondaryIPSecAttempt
Status != true?
YES
sgwType = SECONDARY
Copy the proper controller specific/

default IPSec configuration.
sgwType
PRIMARY BOTH SECONDARY
primaryIPSecAttemptStatus NO
SecGW’s match with secondaryIPSecAttemptStat
= true
lastConnectedSecGW us = true
YES
IPSec Tunnel
NO primaryIPSecAttemptStatus IPSec Tunnle
establish with Matched SecGw’s
F establish with NO
priSecGW IPSecAttemptStatus = true = true F
secSecGW
Success.?
Success.?
YES
YES
IPSec Tunnel IPSec Tunnel
lastConnectedSecGW = establish with YES establish with YES lastConnectedSecGW =
priSecGW lastConnectedSecGW priSecGW secSecGW
Success.? Success.?
Return SUCCESS NO NO
Return SUCCESS
NO
alternateSecGW
F
available.?
YES
Alternate SecGw’s
IPSecAttemptStatus = true
IPSec Tunnle NO
establish with
F
alternateSecGW
Success.?
F
YES
Update corresponding
lastConnecedSecGW
Return FAILURE
Return SUCCESS
Figure 13 - Establish IPSec Connection with SecGW for cWLC communication
23
CONFIDENTIAL
4. AP Connects with cWLC

The AP discovers the AP IP and cWLC with associated Security Gateway profile either from DNS or DHCP or CLI
as per the ApIpDiscoveryMode configuration and start making the IPSec and TLS connection with cWLC in order
to get the current configuration as per the below sequence diagram,
24
CONFIDENTIAL
Primary/Secondary
AP cWLC
SecGW
Discovered the AP IP, cWLC IP addresses with SecGW profile parameters to connect with cWLC Controller and NTP sync is done
IPSec is enabled
Establish IPSec Connection
Establish TLS Connection
Priority
Sequence number = 0
REGISTRATION REQUEST ( Caues = POWER_ON_REGISTRATION ) with [IPSecTunnelInfo (APIPSecInfo)]
Start APRegRespT
TImer
REGISTRATION RESPONSE ( Cause= SUCCESS, [IPSecFlag=Enabled/Preferred, IPSecProfile IE])
Stop APRegRespT
TImer Set alternate
IPSecAttemptStatus=false
Process and validate if the

IPSec Paramters received
SUCCESS
Heart Beat Request and Response messages continues...
SET PTIORITY PARAMETER REQUEST (Priority Sequence Number, [IPSecFlag, IPSec Profile IE])
Process the priority seq. number in Set
Prioroty Request.
(PrevPrioSeqNo = 65534 and

CurrentPrioSeqNo = 1) or
(CurrentPriorSeqNo – PrevPrioSeqNo) = 1
then Validate the parameter
(CurrentpriorSeqNo = validate the Received IPSec Paramters

65535) or in set priority request
(CurrentPriorSeqNo –
PRIO_PARAM_VAL_FAILURE
PrevPrioSeqNo) > 1 SUCCESS

SET PTIORITY PARAMETER RESPONSE (Cause = SUCCESS, Priority Sequence Number)
Cause =
CONFIG_SEQUENCE_ IPSEC_RECONNECT /
MISMATCH NOIPSEC_RECONNECT
Priority Sequence number = 65535

SET PTIORITY PARAMETER RESPONSE (Cause = IPSEC_RECONNECT / NOIPSEC_RECONNECT /
IPSEC_RECONNECT / CONFIG_SEQUENCE_MISMATCH / PRIO_PARAM_Val_FAILURE, Priority Sequence Number)
NOIPSEC_RECONNECT
CONFIG_SEQUENCE_MISMATCH /
Start APSessionT
Timer AP INFORMATION UPDATE (CAUSE= PRIO_PARAM_VAL_FAILURE)
UPLOAD AP INFORMATION ACK

Stop APSessionT IPSEC_RECONNECT /
Timer NOIPSEC_RECONNECT
Move AP to REGISTERED_UNLOCK
state if current state is ACTIVE
Heart Beat Request and Response messages continues...
DEREGISTRATION REQUEST ( Cause= IPSEC_RECONNECT / NOIPSEC_RECONNECT / CONFIG_SEQUENCE_MISMATCH /

PRIO_PARAM_VAL_FAILURE)
Start APDeregRespT
TImer
DEREGISTRATION RESPONSE
Stop APDeregRespT
TImer
Reboot Failure
Success
25
CONFIDENTIAL
Figure 14 – AP Connection with cWLC

The below flow diagram explains the processing of IPSec parameters received form cWLC in
Registration Response or Set Priority Parameter Request,
Received cWLC IPSec Parameters from
cWLC via Registration Response or Set
Priority Parameter Req.
Received Parmeters NO Return

Validation as per DM
success?
YES
cWLC IPSec
parameters
avalaible.? NO
YES
Store IPSec Parameters in

File except SecGW IP
addresses
NO IPSecFlag is
Return NO cWLC connected
Diabled /
IPSEC_RECONNECT over IPSec.?
Preferred.?
YES YES
IPSecFlag is Mark the controller

NO Rerturn
Enabled / IPSec profile(IPSecFlag
NOIPSEC_RECONNECT
Preferred.? in file) as disabled
YES
Received IPSec
parameters are same NO Return
with current parmaters IPSEC_RECONNECT
except SecGW IPs.?
YES
Return
SUCCESS
Figure 15 –Processing and validate IPSec Parameters from Registration Response and Set
Priority Parameter Request
The lastConnectedSecGW for cWLC IPSec connection is maintained in the

/etc/config/lastConnectedSecGW.conf file in following format,
<WLCIP>:<lastConnectedSecGWIP>
The controller provided configuration via Registration Response / Set Priority Parameter Request will be maintained
in /etc/config/.APSetPriorityParameter.conf.validated file as follows,
26
CONFIDENTIAL
WiFiAP.cWLC.<1/2>.ProfileValid
WiFiAP.cWLC.<1/2>.IPSecFlag
WiFiAP.cWLC.<1/2>.IPSecProfile.IPSecProfileID
• EnableLInkRedundancy
• PeerAuthMethod
• PreSharedSecret
• RequestInternalSrcIP
• IKEEncryptionMethod
• IKESAMaxLifetime
• IPSecEncryptionMethod
• IPSecSAMaxLifetime
• DPDDelayTime
• IKERetransmitTries
• IKERetransmitTimeout
• IKERetryInitiateInterval
• IKERetransmitTries
• IKEDSCPTag
• EnablePerfectFwdSecrecy
• EnableAntiReplayCheck
• AntiReplayWindowSize
• NATKeepaliveTime
• DPDDelayTime
The PreSharedSecret for cWLC and WLAN ipsec profiles will be encrypted and stored / maintained in
/etc/config/.presharedsecret-<profile-id> file to retain across reboots. The stored file name will
be mentioned in the PreSharedSecret option in the DB validated file (as well as in ipsec.secrets file).
5. WLAN IPSec Configuration from cWLC

5.1 Required Configurations
The following parameters are required from cWLC for IPSec feature support,
• WLAN config
• WIFIAP.WLAN.<WlanId>.BearerMode
• WIFIAP.WLAN.<WlanId>.PrimaryWAG
• WIFIAP.WLAN.<WlanId>.SecondaryWAG
• WIFIAP.WLAN.<WlanId>.APAccessGateway.<PrimaryWAG>.WAGIPAddress
• WIFIAP.WLAN.<WlanId>.APAccessGateway.<SecondaryWAG>.WAGIPAddress
• WIFIAP.WLAN.<WlanId>.IPSecFlag
• WIFIAP.WLAN.<WlanId>.IPSecProfile
▪ IPSecProfileID
▪ PrimarySecGWIPAddress
▪ EnableLInkRedundancy
▪ SecondarySecGWIPAddress
▪ PeerAuthMethod
▪ PreSharedSecret
▪ RequestInternalSrcIP
▪ IKEEncryptionMethod
▪ IKESAMaxLifetime
▪ IPSecEncryptionMethod
▪ IPSecSAMaxLifetime
27
CONFIDENTIAL
▪ DPDDelayTime
▪ IKERetransmitTries
▪ IKERetransmitTimeout
▪ IKERetryInitiateInterval
▪ IKERetransmitTries
▪ IKEDSCPTag
▪ EnablePerfectFwdSecrecy
▪ EnableAntiReplayCheck
▪ AntiReplayWindowSize
▪ NATKeepaliveTime
The following sequence diagram shows the IPSec configuration flow from cWLC,
cWLC FM NWAM IPSecMgr
TLS connection is established and Software

download is done if necessary
Configuration Download /
SetParamReq Validate the IPSec config
Update the IPSec config

Raise Alarm - 612003 Apply the
Invalid IPSec config received IPSec
Invalid IPSec config configuration
Alarm addlInfo – apMacId,
existingIPSecProfileID and
failedIPSecProfileID Start/update the
IPSec Daemon
Failure
Success
Figure 16 - IPSec configuration flow

All the communication between Nokia AP and cWLC is encoded by Noika proprietary protocol called NWAM and
transferred over TLS connection.
• Nokia AP sends Registration Request (with AP software version, Config version, etc.) to cWLC after
establish the TLS connection with cWLC. The AP active software version is checked with cWLC AP
software version and updated if AP has different version than cWLC.
• Configuration file is downloaded from the cWLC and the NWAM application parse and validate the IPSec
configurations as per the below flowchart. If any configuration is invalid, the Invalid configuration message
is sent to cWLC.
• After validation, The IPSec configurations stored in local structure are given to the IPSec manager by
NWAM. The IPSec manager calculates the IKE/IPSec SA lifetime, IKE / ESP algorithms and add the
28
CONFIDENTIAL
IPSec connection parameters as per the received configuration in strongwan configuration file (ipsec.conf)
and starts the IPSec process which in turn starts the strongswan (starter and charon) daemon.
As per the ICD the following IPSecProfile structure will be used to process the IPSec configuration from
cWLC,
/* IPSEC */
#define IPSEC_PROF_TYPE 0x008D
#define DELETE_IPSEC_PROF_TYPE 0x008E
#define PRESHARED_SECRET_MAX_LEN 128
#define PRESHARED_SECRET_MIN_LEN 8
typedef struct
{
uint8_t addOrModify;
uint8_t numOfWlans;
uint8_t wlanId[MAX_WLAN];
uint8_t ipsecProfileId;
char primarySecGWIPAddress[MAX_IP_ADDRESS_LENGTH + 1];
uint8_t enableLinkRedundancy;
char secondarySecGWIPAddress[MAX_IP_ADDRESS_LENGTH + 1];
uint8_t peerAuthMethod;
char preSharedSecret[PRESHARED_SECRET_MAX_LEN + 1];
uint8_t requestInternalSrcIP;
uint8_t ikeEncryptionMethod;
uint32_t ikeSAMaxLifetime;
uint8_t ipsecEncryptionMethod;
uint32_t ipsecSAMaxLifetime;
uint16_t dpdDelayTime;
uint8_t ikeretransmitTries;
uint8_t ikeretransmitTimeout;
uint8_t ikeretransmitBase;
uint16_t retryInitiateInterval;
uint8_t ikeDSCPTag;
uint8_t enablePerfectFwdSecrecy;
uint8_t enableAntiReplayCheck;
uint8_t antiReplayWindowSize;
uint16_t natKeepaliveTime;
} ipsecObjType;
typedef struct
{
uint8_t addOrModify;
uint8_t numOfWlans;
uint8_t wlanId[MAX_WLAN];
} deleteipsecObjType;
Sample ipsec.conf and strongswan.conf files are given below
29
CONFIDENTIAL
strongswan.conf - strongSwan configuration file

charon {
initiator_only=yes
load_modular = yes
plugins {
include strongswan.d/charon/*.conf
}
}
include strongswan.d/*.conf
30
CONFIDENTIAL
Sample ipsec.conf file:

config setup
charondebug="cfg 4, dmn 4, ike 3, net 4"
conn %default
reauth=no
mobike=no
keyingtries=1
type=tunnel
auto=add
keyexchange=ikev2
leftfirewall=yes
conn WLAN<IPSecProfile.IPSecProfileID>
left=AP_br-wan_IPAddress
right=IPSecProfile.PrimarySecGWIPAddress
rightsubnet=APAccessGateway.PrimaryWAG.WAGIPAddress/32,
APAccessGateway.SecondaryWAG..WAGIPAddress/32
ikelifetime=as per IKE lifetime calculation
keylife=as per IPSEC lifetime calculation
rekeymargin=as per IKE/IPSEC lifetime calculation
esp=as per IPSEC SA Proposal
authby=IPSecProfile.PeerAuthMethod
ikedscp = IPSecProfile.IKEDSCPTag
dpdaction=clear
dpddelay=<dpdDelayTime>
replay_window=<window size>
retransmit_base=<IKERetransmitBase>
retransmit_timeout=<IKERetransmitTimeout>
retransmit_tries=<IKERetransmitTries>
ike=as per IKE SA Proposal
conn WLAN<IPSecProfile.IPSecProfileID>_Sec
left=AP_br-wan_IPAddress
right=IPSecProfile.SecondarySecGWIPAddress
rightsubnet=APAccessGateway.PrimaryWAG.WAGIPAddress/32,
APAccessGateway.SecondaryWAG..WAGIPAddress/32
ikelifetime=as per IKE lifetime calculation
keylife=as per IPSEC lifetime calculation
rekeymargin=as per IKE/IPSEC lifetime calculation
esp=as per IPSEC SA Proposal
authby=IPSecProfile.PeerAuthMethod
ikedscp = IPSecProfile.IKEDSCPTag
dpdaction=clear
dpddelay=<dpdDelayTime>
replay_window=<window size>
retransmit_base=<IKERetransmitBase>
retransmit_timeout=<IKERetransmitTimeout>
retransmit_tries=<IKERetransmitTries>
ike=as per IKE SA Proposal
Figure 17 – Sample IPSec config files
31
CONFIDENTIAL
IPSec config Validation
NO
If IPSecFlag is set
YES
NO If IPSec Profile ID
is valid
YES
NO If SecGW IP
Addresses are
valid
YES
If
NO If PreShared YES PeerAuthMethod
Secret is Valid is PreShared
Secret
YES NO
Different profile ID
Raise an Alarm to YES with Same Primary
inform Invalid IPSec
or Secondary SecGW
config
IPAddress
NO
Clear the Alarm if

already raised
Apply the IPSec

configuration
Return Failure Return Success
Figure 18- Validation of WAN IPSec configuration

5.1.1 IKE / IPSec Lifetime Calculation
The keys negotiated for IKE and IPSec SAs should only be used for a limited amount of time. Each SA should
expire after a specific time (maximum key lifetime). Time when rekeying is initiated is called as rekeying time. The
rekeying time is calculated by the following expression
32
CONFIDENTIAL
Rekeytime = lifetime – (margintime + random (0, margintime * rekeyfuzz))
The following parameter will be configured to define the rekeying functionality of IKE / IPSec SA in strongswan,
• ikelifetime
• lifetime
• margintime
• rekeyfuzz (is in percentage)
*Note – margintime and rekeyfuzz parameters are common for both IKE and IPSec SA rekeytime calculation.
The above parameters will be configured as follows to make sure that IPSEC rekeying will be initiated at the 80% of
the IPSecSAMAXLifetime,
Ikelifetime = <IKESAMaxLifetime>s
Lifetime = <IPSecSAMaxLifetime>s
rekeyfuzz = 0%
margintime = (0.2 * IPSecSAMaxLifetime)s
5.1.2 IKE / ESP Proposals

The AP sends set of ENCR, AUTH, DH & PRF algorithms to SecGW via IKE_SA_INIT and IKE_AUTH
REQUEST in order to negotiate the corresponding IKE and IPSec SA algorithms. The SecGW selects one of the
algorithm combinations and respond via IKE_SA_INIT and IKE_AUTH RESPONSE.
The encryption algorithms given by IPSec configuration are paired with integrity, DH group and PRF and proposed
in the ipsec.conf,
Sample IKE/IPSec proposals given in ipsec.conf file are
• ike = aes128-sha1-prfsha1-modp1024
• esp = aes256-sha256 (Does not support Perfect Forward secrecy (PFS))
• esp = aes256-sha256-modp1536 (Supports Perfect Forward secrecy (PFS))
The following part of configuration will be added in ipsec.conf file according to the IKEEncryiptionMethod
and IPSecEncryiptionMethod,
#define IKE_INTEGRITY_ALGORITHMS “sha256-sha384-sha1-aesxcbc”

#define ESP_INTEGRITY_ALGORITHMS “sha256-sha1”
#define IKE_PRF_ALGORITHMS “prfsha256-prfaesxcbc-prfsha1”
#define DH_ALGORITHMS “ecp256-ecp384-modp8192-modp6144-modp4096-\
modp3072-modp2048-modp1024”
IKE Proposal Table:
IKEEncryptionMethod IKE Configuration in ipsec.conf File
0 ike=aes128-aes256-3des-<IKE_INEGRITY_ALGORITHMS>-
<IKE_PRF_ALGORITHMS>-<DH_ALGORITHMS>!
1 ike=aes128ctr-aes256ctr-<IKE_INEGRITY_ALGORITHMS>-<IKE_PRF_ALGORITHMS>-
<DH_ALGORITHMS>!
2 ike=aes128ctr-aes256ctr-aes128-aes256-3des-
<IKE_INEGRITY_ALGORITHMS>-<IKE_PRF_ALGORITHMS>-<DH_ALGORITHMS>!
3 ike=aes128gcm16-aes256gcm16-<IKE_PRF_ALGORITHMS>-<DH_ALGORITHMS>!
33
CONFIDENTIAL
4 ike=aes128gcm16-aes256gcm16-<IKE_PRF_ALGORITHMS>-
<DH_ALGORITHMS>,aes128ctr-aes256ctr-aes128-aes256-3des-
<IKE_INEGRITY_ALGORITHMS>-<IKE_PRF_ALGORITHMS>-<DH_ALGORITHMS>!
ESP (IPSec) Proposal Table:
IPSecEncryptionMethod ESP (IPSec) Configuration in ipsec.conf File
0 esp=null-<ESP_INEGRITY_ALGORITHMS>-[<DH_ALGORITHMS>]!
1 esp=aes128-aes256-3des-<ESP_INEGRITY_ALGORITHMS>-
[<DH_ALGORITHMS>]!
2 esp=aes128ctr-aes256ctr-<ESP_INEGRITY_ALGORITHMS>-
[<DH_ALGORITHMS>]!
3 esp=aes128ctr-aes256ctr-aes128-aes256-3des-
<ESP_INEGRITY_ALGORITHMS>-[<DH_ALGORITHMS>]!
4 esp=aes128gcm16-aes256gcm16-[<DH_ALGORITHMS>]!
5 esp=aes128gcm16-aes256gcm16-[<DH_ALGORITHMS>],aes128ctr-
aes256ctr-aes128-aes256-3des-<ESP_INEGRITY_ALGORITHMS>-
[<DH_ALGORITHMS>]!
The [<DH_ALGORITHMS>] will be added in the IPSec proposals only if EnablePerfectFwdSecrecy Flag is
set.
5.1.3 Peer Authentication Method

The Peer Authentication mode is selected based on the peerAuthMethod parameter in the IPSec configuration, 0 -
Certificate method and 1 - Pre-Shared Secret,
• Certificate Method - The IPSec will use the following certificates in PEM format to authenticate the peer
while creation IPSec tunnel and which will be available in /etc/ipsec.d path.
o The Cerificate Authority (CA) certificate and Private Key.
o AP’s certificate and private key files.
o The files are created with the help of “openssl”.
o The AP private key must be configured in the /etc/ipsec.secrets file
o Format - : RSA <privateKey file name>
• Pre-Shared Secret
o The PreSharedSecret for cWLC and WLAN ipsec profiles will be encrypted and stored /
maintained in /etc/config/.presharedsecret-<profile-id> file to retain across
reboots.
o The IPSec will decrypt and use the pre-shared secret encrypted file mentioned in the
/etc/ipsec.secrets file entry to authenticate the peer while creation IPSec tunnel.
o Ipsec.secrets file entry Format
o <peer IP Address> : PSK <encrypted pre-shared-secret stored file path>
TBD – IPSec Certificate creation from existing Nokia certificate
34
CONFIDENTIAL
5.1.4 Internal source IP/Virtual IP

An initiator can request responder to provide an additional IP address (virtual IP) to use as source address of IPSec
tunnel inner IP header and this will be handled by strongswan.
• AP requests the SecGW to provide an internal source IP or virtual IP by configuration payload which is
exchanged along with IKE_AUTH messages. The AP’s source IP is replaced by the internal source IP
provided by SecGW in the inner IPSec IP header and the internal source IP gets added to the br-wan
interface.
• The Virtual IP can be configured in ipsec.conf file using leftsourceip, both config need to be
supported by SecGW
o leftsourceip=%config - If the RequestInternalSrcIP is enabled(1), discover
from SecGW
o leftsourceip option will not be added to the connection, If the RequestInternalSrcIP
is disabled(0) then the br-wan IP address will be used as source IP in the internal IP header.
5.1.5 IKE DSCP

Differentiated Services Code Point (DSCP) is a packet header value that can be used to indicate the level of
service requested for traffic, such as high priority or best effort delivery. IPSec supports to tag the DSCP value
for IKE packets.
DSCP value tagging for IKE packet is enabled by adding “ikedscp" configuration parameter in
/etc/ipsec.conf file as follows.
ikedscp = 101010
5.1.6 IKE Cookies

IPSec will send cookies for ikev2 establishment when such notification is received from the IKE remote peer.
• If the responder detects a large number of half-open Ike-SAs, it sends the IKE_SA_INIT requests
containing the COOKIE notification.
• AP will resend the IKE_SA_INIT request including the COOKIE notification containing the received data
as the first payload and all other payloads are unchanged.
Sample configuration for number of half open IKE_SAs that activate the cookie mechanism,
Cookie_threshold = 5
*Note: this will be triggered from Remote Peer.
6. IPSec Interface (policy and routing) Configuration

The IPSec policy and routing based tunnel is created with the peer as per the connection configuration in ipsec.conf
file and use the ipsec.secret file for identification,
Sample config connections in ipsec.conf file,
# ipsec.conf - strongSwan IPsec configuration file
# basic configuration
config setup
charondebug="cfg 4, dmn 4, ike 3, net 4"
# Add connections here.
conn %default
reauth=no
35
CONFIDENTIAL
ikelifetime=1h
keylife=30m
rekeymargin=1m
keyingtries=1
mobike=no
keyexchange=ikev2
authby=psk
conn WLAN_0
left=192.168.102.99 ---- AP br-wan IP
leftsourceip=%config ---- Req. internal src IP from peer.
leftfirewall=yes ---- SecGW IP
right=192.168.102.83 ---- WAG IP
rightsubnet=10.42.1.20/32
ike=aes128-sha1-prfsha1-modp1024!
esp=aes128-sha1
type=tunnel
auto=add
Sample ipsec.secret file contents,
# ipsec.secrets
192.168.102.83 : PSK 1234
The following steps (this will be done by IPSecMgr) will start the tunnel creation,
root@OpenWrt:/# ipsec start – start the ipsec daemon starter and charon with current configurations.
root@OpenWrt:/# ipsec up WLAN_0 – start the WLAN_0 connection tunnel creation.
Upon successful connection, the discovered internal source IP will be assigned to br-wan interface and the
following policy and SA's will be created,
Internal src IP,
root@OpenWrt:/# ip addr list br-wan
br-wan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP

link/ether d8:ef:cd:5d:d3:40 brd ff:ff:ff:ff:ff:ff
inet 192.168.102.99/22 brd 192.168.103.255 scope global br-wan
inet 10.4.1.1/32 scope global br-wan - Received src IP assigned to br-lan
inet6 fe80::daef:cdff:fe5d:d340/64 scope link
valid_lft forever preferred_lft forever
IPSec Status,
root@OpenWrt:/# ipsec statusall

Status of IKE charon daemon (strongSwan 5.5.1, Linux 3.4.103, armv7l):
uptime: 64 seconds, since Nov 14 13:42:11 2016
malloc: sbrk 344064, mmap 0, used 244936, free 99128
worker threads: 10 of 16 idle, 6/0/0/0 working, job queue: 0/0/0/0,
scheduled: 2
loaded plugins: charon test-vectors ldap pkcs11 aes des blowfish rc2 sha2
sha1 md4 md5 random nonce x509 revocation constraints pubkey pkcs1y
Listening IP addresses:
192.168.102.99
Connections:
36
CONFIDENTIAL
WLAN_0: 192.168.102.99...192.168.102.83 IKEv2

WLAN_0: local: [192.168.102.99] uses pre-shared key authentication
WLAN_0: remote: [192.168.102.83] uses pre-shared key authentication
WLAN_0: child: dynamic === 10.42.1.20/32 TUNNEL
Security Associations (1 up, 0 connecting):
WLAN_0[1]: ESTABLISHED 33 seconds ago,
192.168.102.99[192.168.102.99]...192.168.102.83[192.168.102.83]
WLAN_0[1]: IKEv2 SPIs: 49bbda54deb050f2_i* 249770c4a74c6f5c_r, rekeying
in 57 minutes
WLAN_0[1]: IKE proposal:
AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
WLAN_0{1}: INSTALLED, TUNNEL, reqid 1, ESP SPIs: cffe7187_i c92e0c0f_o
WLAN_0{1}: AES_CBC_128/HMAC_SHA1_96, 1008 bytes_i (12 pkts, 8s ago),
1008 bytes_o (12 pkts, 8s ago), rekeying in 27 minutes
WLAN_0{1}: 10.4.1.1/32 === 10.42.1.20/32
IPSec state – Security Associations,
root@OpenWrt:/# ip xfrm state

src 192.168.102.99 dst 192.168.102.83
proto esp spi 0xc92e0c0f reqid 1 mode tunnel
replay-window 0 flag af-unspec
auth-trunc hmac(sha1) 0x75d0869efa2687d1b91db8792196cd95fe29133f 96
enc cbc(aes) 0xc684e9e1f59701fda366fb426de1b94c
src 192.168.102.83 dst 192.168.102.99
proto esp spi 0xcffe7187 reqid 1 mode tunnel
replay-window 32 flag af-unspec
auth-trunc hmac(sha1) 0xadbbc84c71ca949f203d6aefc580ef63c344d8f0 96
enc cbc(aes) 0x4dc7ee2a3d0f9bf2b68b45f381b67760
IPSec policy – Routing details
root@OpenWrt:/# ip xfrm policy

src 10.42.1.20/32 dst 10.4.1.1/32
dir fwd priority 183616
tmpl src 192.168.102.83 dst 192.168.102.99
proto esp reqid 1 mode tunnel
src 10.42.1.20/32 dst 10.4.1.1/32
dir in priority 183616
tmpl src 192.168.102.83 dst 192.168.102.99
src 10.4.1.1/32 dst 10.42.1.20/32
dir out priority 183616
tmpl src 192.168.102.99 dst 192.168.102.83
37
CONFIDENTIAL
7. IKE / IPSEC Tunnel Creation

Nokia AP
Primary
L2TunMgr NWAM FM IPSec mgr STRONGSWAN
SecGW
Process the config
download/update
from cWLC
Pass the IPsec Configuration
Apply the IPsec

Configuration
IPSEC start Start the IPSec

Start the strongswan tunnel creation
as per config.
IKE_SA_INIT Request
No response After configure no of

IKE SA FAILURE transmitTries
-Peer Down/ not reachable
- NO_PROPOSAL_CHOSEN IKE_SA_INIT Response
IKE failed with IKE SUCCESS

IPSecProfileId
Raise alarm - 612062
Stop SSID Transmission
Raise alarm - 612157 If disableSSIDOnGWDown = 1
Return Tunnel Failed with
IPSecProfileId
Process the
Secure Channel is established (IKE SA/ISAKMP Tunnel
tunnel failure is established)
IKE_AUTH Request
IPSEC SA FAILURE
--NO_PROPOSAL_CHOSEN IKE_AUTH Response
--Authentication failed.
IPSEC failed with

IPSecProfileId
Raise alarm - 612062
Raise alarm - 612157 If disableSSIDOnGWDown = 1
IPSEC SUCCESS
Return Tunnel Failed with
--Update the
Process the IPSecProfileId IPSEC success with Kernel IPSec SA
tunnel failure IPSecProfileId
Clear the alarm
Clear alarm - 612062
612062 IPSEC TUNNEL is established
Clear alarm - 612157 if already raised.
If disableSSIDOnGWDown = 1
Return Tunnel is created with
IPSecProfileId
IPSec Success with InternalSrcIP and WlanId
L2TPv3/ L20GRE
Tunnel Creation
Alarm 612062
Failure
addlInfo – apMacId and SecGWIPAddress with following cause,
Success Based on the cause for which this alarm is raised, one of the below cause will be filled,
1. IKE parameters proposed during IKE SA establishment doesn't match with the remote peer proposal.
2. Authentication failure for the remote IKE peer.
3. Remote IKE peer is down/not reachable.
4. IPSec parameters proposed during IPSec SA establishment doesn't match with the remote peer proposal.
Alarm 612157 – SSID transmission failed
Figure 19 - IPSec tunnel creation flow

• IPSec manager gets the IPSec configurations fromNWAM. After all the IPSec configurations are applied to
the IPSec configuration files (ipsec.conf, strongswan.conf, ipsec.secrets) by IPSec manager, IPSec manager
starts the strongswan.
• AP sends an IKE_SA_INIT request to the primary SecGW. SecGW receives IKE_SA_INIT request and
process the payload. It chooses the IKE encryption, integrity, Pseudo random function algorithms and DH
group from the proposals received from AP.
38
CONFIDENTIAL
• SecGW sends the IKE_SA_INIT response to AP. AP receives the IKE_SA_INIT response from SecGW. If
it receives NO_PROPOSAL_CHOSEN as notify payload in SA_INIT response error, strongswan informs
the IPsec Manager which will raise the alarm 612062 and return IKE failed error value with IPSecProfileId
to the NWAM. Otherwise the ISAKMP tunnel is created successfully.
• Then AP sends the IKE_AUTH request to the SecGW. SecGW sends the IKE_AUTH response message to
the AP after it verifies the peer authentication.
• AP receives the IKE_AUTH response. If authentication error or NO_PROPOSAL_CHOSEN error is
received, strongswan informs the IPsec Manager which will raise the alarm 612062 and return IPSec failed
error value with IPSecProfileId to the NWAM. If the IPSec Tunnel is established successfully the
strongswan will sends SUCCESS message to IPSec Manager and it will return success to the NWAM
process.
• If the IPSec tunnel is established towards the active SecGW, will encapsulate the ‘softL2TP or L2oGRE’
packets in the corresponding IPSec tunnel.
• If the IPSecFlag is enabled but IPSec tunnel is not established towards the active SecGW, will discard the
‘softL2TP or L2oGRE’ packet.
• If the IPSec tunnel is established towards the active SecGW for the WLAN to which the client is associated
to, will terminate the IPSec tunnel of the received packet encapsulated within IPSec from SecGW.
• If IPSec tunnel is not established towards the active SecGW for the WLAN to which the client is associated
to, will discard the received IPSec encapsulated packets from SecGW.
7.1 Strongswan (Charon daemon) and IPSecMgr Communication

The following Strongswan Events will be communicated to IPSecMgr process with IPSecProfileId via socket.
• TUNNEL CREATION SUCCESS

• TUNNEL CREATION FAILED
• DEAD PEER DETECTED
• HEART_BEAT_RESPONSE
7.1.1 Message format
The following message data will be send to IPSecMgr from strongswan as per the event detected.
typedef struct
{
uint8_t messageType; /* Message Type */
uint8_t causeForFailure; /* Error Code if the messageType is TUNNEL
CREATION FAILED , 0 Otherwise */
uint8_t ipsecProfileID; /* IPSecProfileID */
uint8_t connType; /*Primary or Secondary*/
char InternalSrcIP[MAX_IP_ADDRESS_LENGTH + 1]; /* IP address which is used to create
L2Tun interface */
} strongswanIPSecMgrIpcData;
typedef enum
{
TUNNEL CREATION SUCCESS = 1,
TUNNEL CREATION FAILED = 2,
DEAD PEER DETECTED = 3,
INVALID_TYPE = 255
} STRONGSWAN_MESSAGE_TYPE;
typedef enum
{
PRIMARY = 1,
SECONDARY = 2
39
CONFIDENTIAL
} IPSEC_CONN_TYPE;
causeForFailure Description
0x14 IKE / IPSEC parameters proposed during IKE/IPSEC SA establishment doesn't match with
the remote peer proposal.
0x24 Authentication failure for the remote IKE peer.
0xFF Remote IKE peer is down/not reachable.
0x38 TS_UNACCEPTABLE
Note – the cause (Failure reason) will be updated as per the strongswan error codes.
7.2 IPSec and L2TunMgr Communication

The following Events will be communicated to L2TunMgr with IPSecProfileId and WlanId by IPSecMgr via socket.
• TUNNEL CREATION SUCCESS

• DEAD PEER DETECTED
The event received from strongswan with IPSecProfileID will be matched with wlan id and send to L2TunMgr
process with WlanId and cause.
7.2.1 Message format
The following message data will be send to L2TunMgr form IPSecMgr as per the event detected.
typedef struct
{
uint8_t messageType; /* Message Type */
uint8_t wlanId[MAX_WLAN]; /* Multiple WLAN’s can have same IPSecProfile. WLAN[ID] 0 -
disabled, 1 -enabled */
char internalSrcIP[MAX_IP_ADDRESS_LENGTH + 1]; /* IP address which is used to create
L2Tun interface */
} ipsecL2TunMgrIpcData;
*Note – the messageType 0x02 is not applicable for this events.
8. IPC Messages between Nokia Applications

The Nokia processes are communicating via socket using tlsPayLoad structure format as follows,
typedef struct
{
tlsPayLoadHeader tlsMsgHeader;
tlsPayLoadBody tlsMsgBody;
} tlsPayLoad;
typedef struct
{
tlsPayloadProtocolIdentifier protocolIdentifier;
uint16_t payLoadLength;
} tlsPayLoadHeader;
typedef struct
40
CONFIDENTIAL
{
uint8_t protocolType;
uint8_t messagePlane;
} tlsPayloadProtocolIdentifier;
typedef struct
{
nwamHeaderMsg nwamMsgHeader;
nwamPayload nwamMsgBody;
uint8_t ipcData[IPC_LEN];
} tlsPayLoadBody;
typedef union
{
/* Message types that can be received by AP from WLC */
registrationResponsePayLoad registrationResponse;
softwareDownloadRequestPayLoad softwareDownloadRequest;
softwareActivationRequestPayLoad softwareActivationRequest;
configDownloadRequestPayLoad configDownloadRequest;
setParameterRequestPayLoad setParameterRequest;
runRequestPayLoad runRequest;
alarmNotificationAckPayLoad alarmNotificationAck;
syncPayLoad sync;
resetRequestPayLoad resetRequest;
pmNotificationAckPayLoad pmNotificationAck;
zoneUpdatePayload zoneUpdate;
userAuthStatusUpdatePayLoad userAuthStatusUpdate;
asyncEventInfoPayLoad asyncEventInfo;
eventControlPayLoad eventControl;
cliPassUpdatePayLoad cliPassUpdate;
snapshotPayLoad snapshot;
unlockRequestPayLoad unlockRequest;
callReleasePayLoad callRelease;
callReleaseWLCtoAPAckPayLoad callReleaseWLCtoAPAck;
traceControlPayload traceControl;
neighborReportUpdatePayLoad neighborReportUpdate;
cWLCMovementPayLoad cWLCMovement;
userPMKUpdatePayLoad userPMKUpdate;
createUserSessionAckPayLoad createUserSessionAck;
setPriorityParameterPayLoad setPriorityParameterRequest;
/* Message types that can be sent from AP to WLC */

registrationRequestPayLoad registrationRequest;
deRegistrationRequestPayLoad deRegistrationRequest;
softwareDownloadResponsePayLoad softwareDownloadResponse;
softwareActivationResponsePayLoad softwareActivationResponse;
configDownloadResponsePayLoad configDownloadResponse;
setParameterResponsePayLoad setParameterResponse;
runResponsePayLoad runResponse;
lockResponsePayLoad lockResponse;
unlockResponsePayLoad unlockResponse;
alarmNotificationPayLoad alarmNotification;
manualClearAlarmAckPayLoad manualClearAlarmAck;
manualClearAlarmPayLoad manualClearAlarm;
infoEvent eventNotification;
configUpdatePayLoad configUpdate;
syncAlarmPayLoad syncAlarm;
41
CONFIDENTIAL
resetResponsePayLoad resetResponse;
pmNotificationPayLoad pmNotification;
authQueryPayLoad authQuery;
zoneUpdatePayload zoneUpdateAck;
authQueryUpdateAckPayLoad authQueryUpdateAck;
syncUserSessionPayLoad syncUserSession;
cliPassUpdateAckPayLoad cliPassUpdateAck;
asyncEventInfoAckPayLoad asyncEventInfoAck;
snapshotAckPayLoad snapshotAck;
callReleaseAckPayLoad callReleaseAck;
callReleaseAPtoWLCPayLoad callReleaseAPtoWLC;
traceCompletePayload traceComplete;
traceStartedAckPayload traceStartedAck;
neighborReportPayLoad neighborReport;
neighborReportUpdateAckPayLoad neighborReportUpdateAck;
cWLCMovementAckPayLoad cWLCMovementAck;
userPMKQueryPayLoad userPMKQuery;
userPMKUpdateAckPayLoad userPMKUpdateAck;
createUserSessionPayLoad createUserSession;
channelUpdatePayLoad channelUpdate;
setPriorityParameterPayLoad setPriorityParameterRequest;
uploadAPInformationPayLoad uploadAPInformationRequest;
}
• NWAM to IPSecMgr
Following messages are send to IPSecMgr,
o IPSEC CONFIGURATION UPDATE

o CREATE IPSEC TUNNEL
o CLOSE IPSEC TUNNEL
messagePlane
IPSEC_CONFIGURATION_UPDATE = 0x82
CREATE_IPSEC_TUNNEL = 0x83
CLOSE_IPSEC_TUNNEL = 0x86
typedef struct
{
uint8_t ipsecConfigType; /* Add/ Modify / Delete*/
uint8_t wlanConfigInfo[MAX_WLAN];
wlanIPSecConfig wlanConfig;
} ipcNwamToIPSecReadConfig;
ipsecConfigType
----------------------
ADD_OBJECT 1
MODIFY_OBJECT 2
DELETE_OBJECT 3
UNMIDIFIED_OBJECT 4
typedef struct
{
timerInfo timer[MAX_IPSEC_TIMER];
char primarySecGW[MAX_IP_ADDRESS_LENGTH + 1];
42
CONFIDENTIAL
char secondarySecGW[MAX_IP_ADDRESS_LENGTH + 1];

char preSharedSecret[PRESHARED_SECRET_MAX_LEN + 1];
char primaryWAG[MAX_IP_ADDRESS_LENGTH + 1];
char secondaryWAG[MAX_IP_ADDRESS_LENGTH + 1];
uint8_t wlanId;
uint8_t ipsecFlag;
uint8_t profileId;
uint8_t ikeEncryptionMethod;
uint8_t ipsecEncryptionMethod;
uint8_t retransmitTries;
uint8_t retransmitTimeout;
uint8_t retransmitBase;
uint8_t dscpTag;
uint16_t dpdDelayTime;
uint16_t retryInitiateInterval;
uint16_t natKeepaliveTime;
uint16_t rekeymargin;
uint32_t ikeSAMaxLifetime;
uint32_t ipsecSAMaxLifetime;
bool enableLinkRedundancy;
bool peerAuthMethod;
bool requestInternalSrcIP;
bool enablePerfectFwdSecrecy;
bool enableAntiReplayCheck;
bool antiReplayWindowSize;
} wlanIPSecConfig;
typedef struct
{
uint8_t isDpd;
int timerFD[MAX_IPSEC_TIMER];
} timerInfo;
typedef struct
{
uint8_t wlan[MAX_WLAN];
uint8_t valid;
uint8_t status;
uint8_t connType;
} ipsecMgrProfile;
typedef struct
{
wlanIPSecConfig ipsecWlanConfig[MAX_WLAN]; /* WLAN IPSec Config */
ipsecMgrProfile ipsecProfileStatus[MAX_WLAN]; /* IPSec Profile Conifg */
/* server socket descriptor */

int ipsecMgrFd;
char APIPAddress[MAX_IP_ADDRESS_LENGTH + 1];
uint16_t ipsecAlarmStatus[MAX_WLAN][MAX_IPSEC_ALARM];
} ipsecMgrData;
• IPSecMgr to NWAM
The Following messages are send to NWAM from IPSecMgr,
43
CONFIDENTIAL
o CREATE IPSEC TUNNEL SUCCESS

o CREATE IPSEC TUNNEL FAILURE
IPSEC_TUNNEL_SUCCESS = 0x84,
IPSEC_TUNNEL_FAILURE = 0x85
typedef struct
{
uint8_t causeForFailure; /* Error Code if the messageType is TUNNEL
CREATION FAILED , 0 Otherwise */
uint8_t ipsecProfileID; /* IPSecProfileID */
uint8_t connType; /*Primary or Secondary*/
} NwamIpcIPSecMgrData;
• IPSecMgr to FM
The following ipcAlarmInd structure will be given in the ipcData in tlsPayLoadBody.
typedef struct
{
uint32_t alarmNumber;
uint16_t alarmSeqNum;
/*Set or clear alarm*/
uint8_t alarmAction;
uint8_t alarmSeverity;
timeStampDataStruct timeStamp;
char alarmAdditionalInfo[ALARM_BUF_LEN + 1];
} ipcAlarmInd;
• HeartBeatMgr to IPSecMgr
The tls payload will be send without any tlsPayLoadBody.
tlsPayLoadHeader options,
protocolType = HEARTBEAT_MGR;
messagePlane = HEART_BEAT_REQ_INTERNAL
payLoadLength = htons(0);
• IPSecMgr to HeartBeatMgr
If HEART_BEAT_REQ_INTERNAL is received from HeartBeatMgr,
• The IPSecMgr will check the Strongswan running status using HEART_BEAT_REQ_INTERNAL and
HEART_BEAT_RESP_INTERNAL pair messages and send the following
HEART_BEAT_RESP_INTERNAL message to HeartBeatMgr as follows,
tlsPayLoadHeader options,
protocolType = IPSEC_MGR;
messagePlane = HEART_BEAT_RESP_INTERNAL
payLoadLength = htons(0);
ipcData = pidof(IPSecMgr);
44
CONFIDENTIAL
9. Re-keying Tunnel
Figure 20- Rekeying IKE/IPSec SA flow

Once IPSec tunnel is established, the IKE/IPSec SAs are always rekeyed by creating new SAs and deleting the old
SAs. Strongswan Charon daemon handles the rekeying of IKE/IPSec process.
• Once the rekeying time of IKE/IPSec expires (rekeying time is less than maximum key lifetime), the AP
sends a CREATE_CHILD_SA request to primary SecGW to create new IKE/IPSec SAs.
• AP then receives a CREATE_CHILD_SA response from primary SecGW. New IKE/IPSEC SA is created.
The old SA IKE/IPSEC is deleted by INFORMATIONAL message exchanges.
10.Dead Peer Detection (DPD)

The AP verifies the current existence and availability of the connected SecGW (PrimarySecGW or
SecondarySecGW) by sending the INFORMATIONAL message (notification payload) and getting response from
the SecGW at every DPDDelayTime interval.
If the AP does not receive any response from SecGW after configured no of retransmission times, AP marks the
peer as Dead and clear the corresponding SA’s. This activity is taken care by the Strongswan (Charon) daemon and
the strongswan DPD parameters are configured in ipsec.conf as follows,
45
CONFIDENTIAL
• dpdaction=clear - It enable the DPD and delete the SA’s upon dead peer is detected.
• dpddelay=DPDDelayTime - the period time interval with which INFORMATIONAL exchanges are
sent to the peer.
Once the dead peer is detected, AP does either one of the following functionality as per the
EnableLinkRedundancy configuration option,
• Re-connecting to same PrimarySecGW – if EnableLinkRedundancy is disabled (0).

• Link Redundancy - Connecting to SecondarySecGW – if EnableLinkRedundancy is enabled (1).
10.1 Re-connecting to same PrimarySecGW
FM IPSecMgr Strongswan Primary SecGw
IPSEC TUNNEL is established
DPD delay timer start
DPD delay timer expires INFORMATIONAL Request

Retransmit timer start
INFORMATIONAL Response
Retransmit timer stop
Retransmit timer expires

INFORMATIONAL Request
Continue till configured no of IKE Retransmits
Last Retransmit timer

expires
Raise Alarm 612063 Intimate PrimarySecGW is Delete the corresponding
applInfo
dead with connection IKE/IPSEC SAs
- apMacId
- SecGWIPaddress name and IPSecProfileID
If disableSSIDOnGWDown = 1 PrimarySecGW
Raise Alarm 612157 Retry timer start
ipsec up WLAN<IPSecProfileID>
PrimarySecGW
Retry timer expires Start the Tunnel creation procedure
Success
Failure
Figure 21 – Re-Connecting to PrimarySecGW
46
CONFIDENTIAL
10.2 Link Redundancy - Connecting to SecondarySecGW
FM IPSecMgr Strongswan Primary SecGw Secondary SecGw
IPSEC TUNNEL is established

DPD delay timer start
DPD delay timer expires INFORMATIONAL Request

Retransmit timer start
INFORMATIONAL Response
Retransmit timer stop
Retransmit timer expires
INFORMATIONAL Request
Continue till configured no of IKE Retransmits
Last Retransmit timer expires
Raise Alarm 612063
applInfo Intimate PrimarySecGW is dead
- apMacId with connection name and Delete the corresponding
- SecGWIPaddress IPSecProfileID IKE/IPSEC SAs
Raise Alarm 612157
If disableSSIDOnGWDown = 1
PrimarySecGW Retry timer start

If Link Redundancy Enabled ipsec up WLAN<IPSecProfileID>_Sec
Stop the PrimarySecGW Retry timer Tunnel creation success

and Start the respective SSID
transmission Start the Tunnel creation with SecondarySecGW
Clear Alarms
Tunnel creation Failure
SecondarySecGW Retry timer start
PrimarySecGW Retry
Stop the tunnel creation with timer expires
SecondarySecGW
Start the tunnel creation with ipsec up WLAN<IPSecProfileID>
PrimarySecGW
Stop the SecondarySecGW Retry Tunnel creation success

timer and Start the respective SSID Start the Tunnel creation procedure with
transmission PrimarySecGW
Clear Alarms
Tunnel creation Failure
SecondarySecGW
Stop the tunnel creation with Retry timer expires
PrimarySecGW
Start the tunnel creation with ipsec up WLAN<IPSecProfileID>_Sec
SecondarySecGW
The same procedure will continue till make tunnel with either Primary/Secondary SecGW and the DPD procedure starts with the
connected SecGW
Success
Failure
Figure 22- Link Redundancy Sequence flow

IPSec Tunnel is established between AP and PrimarySecGW.
• The AP keeps on sending the keep alive messages (INFORMATIONAL messages) to PrimarySecGW and
receives the response from primary SecGW.
• If AP doesn’t receive any response messages from Primary SecGW after the configured no of retransmit
tries, the strongswan clears the corresponding IKE/IPSec SA’s and intimate the IPSec manager. IPSec
manager starts the PrimrySecGW retry timer and make the strongswan to establish an IPSec tunnel between
AP and Secondary SecGW.
• If the SecondarySecGW tunnel is created successfully, then the IPSecMgr stop the PrimarySecGW timer
and the DPD procedure starts with SecondarySecGW.
• If the SecondarySecGW tunnel creation failed or PrimarySecGW retry timer expired while tunnel creation
with SecGW, the IPSecMgr will stop the tunnel creation with SecondarySecGW, start the
47
CONFIDENTIAL
SecondarySecGW retry timer and make the strongswan to establish an IPSec tunnel between AP and
PrimarySecGW.
The above procedure will continue till the AP make tunnel with either PrimarySecGW or SecondarySecGW and the
DPD procedure will start with the connected SecGW.
11.Perfect Forward Secrecy

The cryptographic keys may either derived from IKE key material or with a separate DH exchange (done along with
CREATE_CHILD_SA). The latter is known as Perfect Forward Secrecy (PFS).
• If EnablePerfectFwdSecrecy Flag is set, the DH group is added with the ESP proposals for IPSec
SA (DH group is added with esp parameter in ipsec.conf file).
The Group 2 and Group 14 – 20 DH groups support the PFS in IKEv2.
Sample ESP parameter configuration to support PFS,
• esp = 3des-sha1-modp1536
12.Anti-Replay Protection and Extended Sequence Number (ESN)

The IPSec anti-replay protection feature uses a sliding window of sequence numbers to drop packets which arrive
out of order as a method of preventing replay attacks, where an "attacker" captures and resends the same packets
multiple times. This process has been taken care by the Linux IPSec(Xfrm) kernel and the strongswan only sends the
configured anti-replay window size via netlink socket to kernel.
The Anti-Replay Protection window size is selected by following option in ipsec.conf,
• replay_window=AntiReplayWindowSize - if EnableAntiReplayCheck is enabled (1).

• replay_window=0 - if EnableAntiReplayCheck is disabled (0).
*Note – the linux kernel should support the selected replay window size.
The IPSec uses the 32bit or 64 bit sequence number. The extended sequence number (64 bit sequence number) is
enable by adding “esn” keyword with esp parameter in ipsec configuration.
Sample ESP parameter configuration to support ESN,
• esp = 3des-sha1-modp1536-esn-noesn
ESN will be enabled when peer supports the ESN, otherwise the 32-bit sequence will be used.
13.NAT Traversal
NAT Traversal is used to detect NAT devices in the transmission path and switch to UDP encapsulation for IPSec
ESP packets. Strongswan supports the NAT Traversal.
• The existence of NAT device can be detected with IKE_SA_INIT exchanges

• The ESP packets will be encapsulated with UDP header and the received UDP encapsulated packets will be
processed.
• Source and destination ports are assigned as 4500 for all subsequent IKE/IPSEC traffic.
• AP will send the NAT-keepalive packets to NAT server with the interval NATKeepaliveTime to keep
the NAT mappings alive at the NAT server.
• AP will discard the NAT- keepalive packets with source/destination ports as 4500 received outside of
IKE/IPSec SA.
48
CONFIDENTIAL
Sample configuration for NAT keepalive interval,
keep_alive = NATKeepaliveTime
14. cWLC IPSec configuration via CLI

Nokia AP supports, that the user/operator to get/set the cWLC IPSec configuration via the CLI commands.
• All the IPSec configurations can be able to get with the help of CLI commands.
• The operator can able to show / set / unset the following IPSec configurations through CLI,
o SecGW Profile
▪ PrimarySecGWIPAddress.
▪ SecondarySecGWIP Address
▪ InternalSrcIPAddress
▪ PeerAuthMethod
o Pre-shared key.
• All the set parameters will be validated as per the Data Model before gets applied.
14.1 Show cWLC IPSec configuration via CLI

Command format,
show ipseccwlc config
The above command will display,
• The SecGW Profile parameters associated with the given cWLCIP, if available.
• CLI will prompt for CLI login password for displaying pre-shared secret in clear text.
• If entered password is correct, the Pre-shared secret is displayed in plain text, otherwise “****” will be
displayed.
• If pre-shared secret is not supplied yet, will display “Not Supplied” for the pre-shared secret value.
• The default values for the secgw-profile, if there is no secgw-profile is associated for the given cWLCIP.
49
CONFIDENTIAL
Show ipseccwlc config
Get the CLI password from user
Read Hash value of password (apadmin)

from the file (/etc/shadow)
Parse Salt from the Hash
Calulate SHA256 Hash for given Password +

with discovered Salt
Compare the apadmin No

(/etc/shadow) Hashed Show the preshared
value with the given password hashed secret as “****”
value for matching
Yes
Decrypt and Show the preshared secret in

plain text
Figure 23 – show ipseccwlc command flow
14.2 Set / unset cWLC IPSec Configuration via CLI

14.2.1 SecGW Profile Configuration
Command Format,
set ipseccwlc cwlc <cwlc1 or cwlc2> primarysecgw-ip <ipaddress>

[secondarysecgw-ip <ipaddress>] [internalsrc-ip <ipaddress>] peerauthmethod
<0 or 1> [psk-format <plain or cipher>] [preshared-secret <value>]
peerauthmethod value,
0 – Certificate
1 – Pre-Shared Secret
secondarysecgw-ip, internalsrc-ip, psk-format and preshared-secret settings

are optional.
The above command,
• Will check all the mandatory and optional parameters, if peerauthmethod is selected as (1) but psk-format
and preshared-secret value are not provided, display below warning message to user "Psk-format and
Preshared-secret value are required when peerauthmethod is selected as (1)."
• Will validate the given parameters as per the DM, if validation failed, display error message “Invalid
parameter(s), please set and try again” to operator.
50
CONFIDENTIAL
• If psk-format is selected as ‘Cipher’, will decode or decrypt the received BASE64 encrypted preshared-
secret using encryption algorithm AES-128-CBC with “dhfcdk$#dse58#” as a passphrase.
• If decryption of PreSharedSecret fails, will display the error message “Unable to decrypt the entered
PreSharedSecret, please try again”
• If psk-format is selected as ‘plain’, will validate the received preshared-secret value as pre DM, if
validation fails, will display the error message “Invalid parameter(s), please set and try again”
• If the validation success, the preSharedSecret (in encrypted format) will be stored in the database. The
preSharedSecret will be decrypted and used using aes-128 with “dhfgvk$#dse78#<AP-MAC>”
passphrase.
• Display the following statement,
• “The configured Pre-shared secret will be shared for both SecGWs associated to this cWLC. The
SecGW IP(s) are srimarySecGWIPAddress and secondarySecGWIPAddress”
• Upon receipt of multiple SecGW IP Addresses, if they are identical, display error message "Identical IPs
cannot be set. Try again by setting different IPs." to operator.
• If all the validations are success, then update the PrimarySecGWIPAddress, SecondarySecGWIPAddress,
InternalSrcIPAddress and PeerAuthMethod of the associated cWLC to the database.
• Display the following message to user "The setting will take into effect only after a reboot. Set cWLC
IP and/or Wi-Fi AP IP before initiating a reboot.”
Set ipseccwlc B C
Check cWLC, Compare and check the

No Check Secondary No
Primary SecGW IP address and PSK-Format is cipher
SecGW IP address/Internal Src IP
peerAuthMethod value are
address provided
provided Yes
Return
Yes Decode the PreSharedSecret using base64
Yes
encoding
Plain
No
Is PeerAuthMethod
Return
value is 1? No
Is IP address valid? Return Decrypt the decoded
PreSharedSecret using No
Yes
aes-128-cbc encryption algorithm
with passphrase as
Verify PSK-format No dhfcdk$#dse58# Return
and PreSharedSecret are Return
provided C
Yes
Yes
Validate the
If cWLC is cWLC1/ No PreSharedSecret plain text as No
Return per DM (Allowed characters: a-z,A-
cWLC2?
Z,0-9,_-+.,;/!@#$%^
Yes Len: 8-128) Return
Get corresponding cWLC IP address
Yes
from the Database (ApIp Config file)
Get the MAC address of the No

No device bond0
Is cWLC IP
Return Return
address valid? Yes
Yes
Encrypt and Store the preshared secret in /
Is Primary No etc/config/.presharedsecret-ctrl-(10r2) file
SecGW IP address Return using aes-128 encryption algorithm with
valid? passphrase as dhfgvk$#dse78#<MAC>
B Return
Figure 24 – set ipseccwlc command flow

Command Format,
unset ipseccwlc cwlc <cwlc1 or cwlc2>
51
CONFIDENTIAL
The above command will set the following values to the secgw-profile associated with given cWLC and Display
"The setting will take into effect only after a reboot. Set cWLC IP and/or Wi-Fi AP IP before initiating a
reboot.” message to user.
primarySecGWIPAddress = NULL
secondarySecGWIPAddress = NULL
internalSrcIPAddress = NULL
peerAuthMethod = 0
perSharedSecret = “nokia123”
Unset Command
No
Check the CWLC is valid
(cwlc1/cwlc2)
Return
Yes
Remove SecGW profile configuration for

associated cWLC
(Set NULL value to Primary SecGW IP address,
Secondary SecGW IP address, Internal Src IP
address
Set 0 to PeerAuthMethod)
Write PreSharedSecret as nokia123 in the

file
(/etc/config/.preSharedSecret-ctrl-X),
where X is the CWLC
Set the U-boot environment Variables for the

associtated CWLC
Display the message

“The setting will take into effect only after a
reboot.
Unset cWLC IP and/or Wi-Fi AP IP before
initiating a reboot.”
Figure 25 – unset ipseccwlc command flow
52
CONFIDENTIAL
User/Operator CLI
show / set / unset secGW profile

Configuration
Parse and Validate
Error Messaage the config
Process the show

Display SecGW profile command
Update the
configuration
Database for
Update the User set / unset
commands
Failure
Success
Figure 26- CLI configuration flow
15.Performance Measurement Counters

The following 8 counters will be maintained for ipsec profile and these counters are unique for Primary and
Secondary Security gateway connections of IPSecProfileId.
#define MAX_IPSEC_PROFILE 16
typedef struct
{
uint16_t measurementId;
uint16_t ipsecProfileId;
uint16_t numberOfCounters;
ipsecCounter priSecGwCounters;
ipsecCounter secSecGwCounters;
} tableForM6016;
tyepdef struct
{
uint32_t failedSaEstablishment; /* Failed to establish IPSec Tunnel */
uint32_t saNotFoundError; /* Received SPI not found */
uint32_t discardedNonEspPackets; /* No of Discarded packets */
uint32_t receivedEspPackets; /* No of Received ESP packets */
uint32_t sentEspPackets; /* No of sent ESP packets */
uint32_t antiReplayErrors; /* No of times packet seq no does not match */
uint32_t espCryptographicError; /* NSS Cryptography error */
uint32_t tsMismatchError; /* TS_UNACCEPTABLE error count */
} ipsecCounters;
The above counters are maintained in shared memory and some of them are discovered from kernel via Netlink.
TBD- Counter collection flow will be updated.
53
CONFIDENTIAL
16.Assumption
• Strongswan Daemon runs on SecGW and SecGW can able to perform the IPSec termination for the packets
coming from Nokia AP.
• cWLC provide the required IPSec configurations for IPSec tunnel establishment.
• To protect the tunnel traffic between AP and SecGW, the Host (AP) to Net (SecGW) topology will be used
where the Tunnel packets from AP to WAG are protected by IPSec till SecGW and vice versa.
17.References
• RFC 4301 – Security Architecture for the Internet Protocol – IETF Tools
• RFC 2408 - ISAKMP
• RFC5996 and 7296 – Internet Key exchange Protocol Version 2
• RFC 4303 – IP Encapsulating Security Payload(ESP) – IETF Tools
18.ACRONYMS AND DEFINITIONS

S.No Term Definition
1. AP Access Point
2. SecGW Security Gateway
3. cWLC Cloud Wireless LAN Controller
4. WAG Wireless Access Gateway
5. UE User Equipment
6. IKE Internet Key Exchange
7. ISAKMP Internet Security Association and Key Management protocol
8. IPSec Internet Protocol Security
9. ESP Encapsulating Security Payload
10. SA Security Association
11. WLAN Wireless Local Area Network
12. GUI Graphical User Interface
13. NWAM Nokia Wireless Access Management
14. PM Performance Manager
15. FM Fault manager
16. UT User Tracer
54
CONFIDENTIAL

Ipsec Design

Uploaded by

Copyright:

Available Formats

Ipsec Design

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Ipsec Design

Uploaded by

Copyright:

Available Formats

Software Design Document (SDD)

Nokia Access Point Feature Development

Date Rev No. Description By

30/12/2016 A2-00 Updated the D4 Requirements from Nokia VVDN

9. Re-keying Tunnel ................................................................................................................................................ 45

This SDD is made for the reference of

1.2 Product Overview

• Chipset for AP Product - AC200i (2x2), AC210m (2x2)

• Chipset for AP Product - AC400i(4x4), AC400(4x4)

1.3 Scope of the Feature

Only one IPSec tunnel will be available with either

Figure 1 - Nokia Access Point setup environment

Following are the Scope of the IPSec Feature provided by Nokia,

1.4 Feature Overview

1.4.1 IPSec Overview

1.4.1.1 Operating Modes

1.4.1.2 Protocols of IPSec

1.4.1.2.1 Internet Key Exchange

1.4.1.2.1.1 Security Association (SA)

1.4.1.2.2 Authentication Header (AH)

Figure 2 - AH Packet Format

1.4.1.2.3 Encapsulating Security Payload (ESP)

Figure 3 - ESP Packet Format

1.4.1.3 IPSec Communication

The entire IPSec communication can be classified as -

1.4.1.3.1 IKEv2 Message Flow

Figure 4 - IKE_SA_INIT message exchange

Figure 5- IKE_AUTH message exchange

Figure 6 - CREATE_CHILD_SA message exchange

1.4.2 Requirements Overview

Below requirements provided by Nokia to support IPSec feature on AP,

Following are the Security parameters/protocols to be supported in this feature

STRONGSWAN IPSec config

LINUX Network Stack

NSS Crypto Ethernet

Radio Interface Crypto Ethernet Interfaces

Figure 7 - Software Architecture Diagram

• SecGW sends the IPSec protected tunnel traffic to AP.

2.1 IPSec Application packages and NSS crypto driver

2.1.2 IPSecMgr Application

The IPSecMgr logs are stored in the /usr/log/WifiAPDebug log file.

2.1.3 Modification of NWAM to process the IPSec configuration

2.1.4 Supported Algorithms

Integrity – HMAC_SHA2_256, HMAC_SHA2_384, HMAC_SHA1 and AES_XCBC

Integrity – HMAC_SHA2_256 and HMAC_SHA1

Pseudo Random Function (PRF) – HMAC_SHA2_256, AES_XCBC, HMAC_SHA1

2.1.5 NSS Crypto Offload

• NSS driver (qca-nss-drv.ko) –used to configure the NSS crypto engine

The following algorithms will be supported by the crypto engine,

3. AP Initialization with cWLC

Figure 8 – AP Boot up Process

3.1 Discover cWLC SecGW Parameters

The PrimarySecGWIP, SecondarySecGWIP, InternalSrcIP and PeerAuthMethod parameters

The PreSharedSecret will be encrypted and stored / maintained in /etc/config/.presharedsecret-

If the ApIpDiscoveryMode is AP_DYNAMIC_CTRL_STATIC or AP_STATIC_CTRL_STATIC, the above

Figure 9 – Discover cWLC IP and SecGW Profile via DNS/DHCP

Figure 10 – cWLC IP Discovery process via DNS/DHCP

Figure 11 – Process IPSec information in DNS/DHCP