FAQs
This section provides solutions to common issues faced during NanoSec integration efforts.
Question: Does NanoSec support RFC 3706 Dead Peer Detection (DPD)?
Answer: Yes, the RFC implementation is supported.
The RFC implementation specifies that when IKE SA is alive, all IPsec keys that have been established are also assumed to be alive. The native NanoSec DPD implementation, which is enabled regardless of whether the RFC implementation is enabled, performs additional checks that take into account that IPsec keys can remain active even when an IKE SA becomes inactive, and vice versa. These checks enable the native DPD implementation to differentiate between a problem with the keys and a peer being offline (not alive).
For additional information about the RFC implementation, refer to the following Web page: ftp://ftp.rfc-editor.org/in-notes/pdfrfc/rfc3706.txt.pdf*.
Question: Can I use NAT-T (Network Addresses Translation-Traversal)?
Answer: Yes, NAT-T is supported. To enable this feature, define the __ENABLE_IPSEC_NAT_T__ flag in moptions.h.
In accordance with RFC 3947, only the client (initiator) is behind NAT; the responder has a fixed static IP address. For additional information, refer to the following Web page: ftp://ftp.rfc-editor.org/in-notes/pdfrfc/rfc3947.txt.pdf.
The NanoSec NAT-T implementation is optimized for client applications, and therefore is intended for one end behind NAT. It can be extended, however, to operate on servers needing to manage multiple client devices behind NAT. For instructions, contact the TrustCore SDK Support Team via the TrustCore SDK Helpdesk.
Question: If the security policy is configured to use ANY for both the Phase 1 encryption and Phase 2 authentication algorithm, does TrustCore SDK NanoSec code use combinations of all possible algorithms (MD5, SHA-1 for auth, DES, 3DES, AES for encryption) that it supports (since ANY was selected for both)?
Answer: If the IPsec policy says to use ANY algorithm, as IKE Phase 2 initiator, NanoSec code uses the same encryption/hash algorithm selected for Phase 1.
Note: The ANY keyword is not in the RFC definitions.
Question: How do I know whether certificates or PSK (pre-shared keys) are used for authentication?
Answer: If certificates are configured, they are used for authentication. If no certificates are configured and PSK is available, then PSK is used.
Question: If a certificate is configured but authentication via certificate fails for any reason, does authentication fallback to PSK?
Answer: No; to enhance security, there is no fallback mechanism for renegotiating authentication.
Question: When and how can I enable/disable anti-replay protection?
Answer: The anti-replay feature is enabled/disabled at compile time by setting the IPSEC_REPLAY_SIZE flag in ipsec.h.
Question: My implementation requires multihoming (using multiple host IP addresses for IKE and IPsec); does NanoSec provide the necessary support?
Answer: Yes, NanoSec supports multihoming.
If a device has multiple interfaces but only one is performing IKE negotiation, multihoming is unnecessary. However, the callback function registered (assigned) to the ikeSettings funcPtrIkeGetHostAddr function pointer must be customized so that it returns the required interface’s IP address.
To enable multihoming:
Add the required flag definition:
Open the moptions.h file (in the src/common directory) for editing.
Add the following definition:
#define __IKE_MULTI_HOMING__
Save and close the file.
Assign a serverInstance to each interface. (Usually, the server’s associated host IP address can be used.)
Create a separate socket (for example, UDP port 500) for each interface: bind() each socket with the associated host IP address. The IKE server waits on all such sockets simultaneously.
As messages arrive, call IKE_msgRecv, taking care to set the serverInstance argument based on the socket receiving the message.
Similarly, call
IKE_ikeSettings->funcPtrIkeXchgSendwith the serverInstance argument set to the corresponding socket.Send IPsec events by calling
IKE_ikeSettings‑>funcPtrIkeEvtSendwith the dwHostAddr argument set to the host IP address.To retrieve the host IP address for a given serverInstance, call
IKE_ikeSettings‑>funcPtrIkeGetHostAddr.
Question: How are GPL issues addressed when integrating the proprietary TrustCore SDK NanoSec with the Linux kernel?
Answer: The core of TrustCore SDK NanoSec source code is self-contained; that is, it conforms to RFCs and is not a derivative work of any GPL-covered code. The TrustCore SDK NanoSec code has been integrated with numerous non-Linux platforms. For Linux integration, custom code is likely to interact with the kernel’s network stack, and therefore should be under GPL. See src/examples/ipsec/linux for a sample Linux integration.
Question: I’d like to use hardware acceleration; does the TrustCore SDK software support that?
Answer: Yes, TrustCore SDK NanoSec supports the use of hardware acceleration for Linux and VxWorks target operating systems.
When hardware offload is enabled, the software versions of some crypto operations are turned off, and the corresponding hardware acceleration operation are used instead. As a result, the code dramatically shrinks and performance improves significantly.
To enable hardware acceleration:
Open the moptions.h file (in the src/common directory) for editing.
Add the following definitions:
#define __ENABLE_HARDWARE_ACCEL_ASYNC_CRYPTO__ (or __ENABLE_HARDWARE_ACCEL_SYNC_CRYPTO__ if using synchronous communications) #define __ENABLE_MOCANA_HARDWARE_CRYPTO_ACCEL__
Add the appropriate definition corresponding to the hardware’s offload:
For 8248/8272 and similar PowerQuicc II hardware offloads:
#define __ENABLE_FREESCALE_8248_HARDWARE_ACCEL__
For 875/885 and similar PowerQuicc I hardware offloads:
#define __ENABLE_FREESCALE_875_HARDWARE_ACCEL__
For Broadcom® support:
#define __ENABLE_BCM582x_HARDWARE_ACCEL__
Save and close the file.
Question: How are NanoSec key BLOBs formatted?
Answer: TrustCore SDK components use callback functions during authentication to verify public keys, which are managed as byte string representations of TrustCore SDK TrustCore formatted for version 1 or version 2 key BLOBs.
Key BLOBs for version 1 are formatted as follows:
key BLOBs begin with a 12-byte header, with all bytes set to zero except the following:
header[7] contains the TrustCore SDK TrustCore key BLOB version (1)
header[11] contains the key type (akt_* enumerated values defined in ca_mgmt.h)
For DSA keys, the data following the header is:
4 bytes length of p string
n bytes length of p byte string
4 bytes length of q string
n bytes length of q byte string
4 bytes length of g string
n bytes length of g byte string
4 bytes length of y string
n bytes length of y byte string
4 bytes length of x string
n bytes length of x byte string
For RSA keys, the data following the header is:
4 bytes length of e string
n bytes length of e byte string
4 bytes length of n string
n bytes length of n byte string
4 bytes length of p string
n bytes length of p byte string
4 bytes length of q string
n bytes length of q byte string
4 bytes length of private string #1
n bytes length of private byte string #1
4 bytes length of private string #2
n bytes length of private byte string #2
4 bytes length of private string #3
n bytes length of private byte string #3
4 bytes length of private string #4
n bytes length of private byte string #4
4 bytes length of private string #5
n bytes length of private byte string #5
For ECC keys, the data following the header is:
1 byte OID suffix identifying the curve
4 bytes length of Point string
n bytes length of Point byte string (uncompressed X9-62 format)
4 bytes length of Scalar string
n bytes length of Scalar byte string
Key BLOBs for version 2 are formatted as follows:
4 bytes: all zeros
4 bytes: version number which must be 0x00000002
4 bytes: key type which must be one of the KEYBLOB_TYPE enums
4 bytes: OID type which must be one of the MAlgoOid enums
N bytes: ASN.1 encoded algorithm identifier
4 bytes: reserved
N bytes: reserved
4 bytes: key data length (keyblen)
Keylen bytes: key data (key data formats are mentioned above)
Question: Are IKE settings common across IP addresses or unique per each IP address?
Answer: With two exceptions, IKE settings are common (global); they can be changed at any time and the changes are propagated across every IP address. The exceptions are:
Authentication method: The only setting for which there is no default and must be configured for each IKE instance via IKE_initServer.
PSK: Different pre-shared keys can be used by different IKE peers (by defining the CUSTOM_IKE_GET_PSK flag and customizing the pre-shared key functions. For detailed instructions, contact the TrustCore SDK Support Team via the TrustCore SDK Helpdesk.
Question: What is the purpose of the NanoSec __ENABLE_IPSEC_FLOW__ compilation flag?
Answer: This flag enables fast SPD and SADB lookup using a cache that stores previously used SP/SA for a given flow; that is, a 5-tuple of source IP address, destination IP address, upper layer protocol, source port, and destination port. Using this flag enhances the performance of NanoSec IPsec processing; however, this feature should be used with discretion because of the following limitations:
Flow that matches a drop or bypass rule is not cached.
After a manually keyed SA is cached, it overrides newer SAs because manual keys do not expire (unless explicitly deleted).
After a policy (SPD entry) is cached, newer policies with higher priorities cannot be applied.
To use this flag, add the following to the moptions.h file:
#define __ENABLE_IPSEC_FLOW__ #define IPSEC_FLOW_MAX 4
The default cache size (defined by IPSEC_FLOW_MAX) is 4. You can change the cache size, but choosing a large value defeats the purpose of this feature.
For outbound IPsec processing, call the IPSEC_flowGet function to retrieve a cached SP/SA; see the examples/ipsec/linux/nf_ipsec.c sample module for typical usage.
Question: Can I use a third-party IKE and/or third-party IPsec implementation with NanoSec?
Answer: Yes, either a third-party IKE or a third-party IPsec implementation can be used with TrustCore SDK NanoSec; however, it requires significant extra work and a deep understanding of how the internal NanoSec API functions are used to enable communications between NanoSec IKE and NanoSec IPsec. If assistance is needed, contact the TrustCore SDK Support Team via the TrustCore SDK Helpdesk.
Question: How much memory does NanoSec need to operate smoothly on a system?
Answer: The table below provides the memory requirements for NanoSec IPsec, NanoSec IKE, and each NanoSec IKE SA (Security Association).
Component | Memory (KB) |
|---|---|
IPsec binary | ~100 |
IKE binary | (x86) ~200, (ARM/PPC) ~350, (MIPS) ~400 |
IKE SA | 1-4 per SA, depending on compilation flags |
Question: What is the NanoSEC IKE connection rate?
Answer: The NanoSec IKE connection rate is 25-40 tunnels/second.
Question: Which RFCs are supported by NanoSec?
Answer: For the list of supported RFCs, refer to the IETF RFCs Supported by the TrustCore SDK SoT Platform guide.
Question: Can I build HA support on top of NanoSec IKE?
Answer: Yes, NanoSec supports HA in accordance with RFC 5685, IKEv2 Redirect Mechanism.
Question: Are hardware offload interfaces included with NanoSec?
Answer: Yes, hardware offload interfaces are provided for the following:
Freescale 8248 8272, 8313, 8315, 8323, 8349, 8360, 8379, 8544, 8548, 8555, 8572, ColdFire® CAU (cryptographic acceleration unit)
Cavium CN58xx
Broadcom 5682, 582x
NanoSec is an API-based source code library. Therefore, developers can provide any front-end configuration method. IPC (inter-process communication) is one method for invoking the relevant API functions for peer configuration management. Sample code is provided to demonstrate the use case for a single NanoSec IKE executable with command-line options.
Question: How does the conf file support configuration for multiple NanoSec IKE daemons? Is isolation of certificates, keys, etc., supported?
Answer: As previously explained, NanoSec is an API-based source code library. Developers can provide any front-end configuration method, including IPC to invoke the provided API functions for peer configuration management.
Question: Is multi-tenancy supported, such that a single NanoSec IKE daemon can communicate with multiple namespaces?
Answer: Because NanoSec IKE uses two (2) standard (fixed) UDP ports, there can be only one active open socket for each such port, per host IP address. Multi-tenant NanoSec IKE processing would require a dedicated socket to relay incoming messages to desired namespaces. Outgoing messages (from multiple namespaces) would be routed to the dedicated socket (to be sent out).
Question: Which schemes are supported to communicate between NanoSec IPsec and the NanoSec IKE daemon?
Answer: NanoSec is an API-based source code library that provides a set of interface APIs that enable communication with NanoSec IPsec. A sample implementation is provided via PF_KEY. Sample integrations are also provided for various RTOSes (Linux®, QNX®, Microsoft® Windows®, and others) to demonstrate different mechanisms of implementing the API interfaces.