[strongSwan] Augment the "esp cipher suites" with foreign not standard ciphers

[Martin Willi]

> The IP data flow is not IPsec-ed by Linux but by an external NPU.

I see. I assume you're using our PF_KEY kernel interface plugin, then.

> Then, probably only the items 3) and 4) from your list are required.

You'll need 5), too. Your NPU probably provides a PF_KEY algorithm
identifier (such as SADB_X_EALG_XY) for your cipher. You'll have to map
the IKEv2 specific identifier to the PF_KEY identifier in [1].

> Concerning the item 3, if we choose an IKEv2 algorithm identifier
> then how we can specify it with strongSwan?

IKEv2 algorithm identifiers for ciphers are defined at [2]. Above 1024
are private use identifiers not managed by IANA.

> what should be done for the item 4 ("proposal configuration option").

Sets of algorithm identifiers are encoded into proposals, these are used
the negotiate an algorithm set to use. The proposals are attached to
configurations and must be configured. Without your algorithm in the
proposal, you won't have a chance to negotiate it with your peer.
To configure a connection with a proposal using your algorithm
identifier via the ipsec.conf esp= option, you'll need a keyword. 

These keywords are defined in [3] and mapped to your defined identifier.

> A simple but not elegant solution is to negotiate a well-known/supported
> Cipher but, by convention, to apply to the both ends of the tunnel the
> new cipher (not related to negotiated one).

Is the simplest option, but might be very confusing. Using private use
identifiers is the clean way. strongSwan currently requires the
strongSwan vendor ID for private use identifiers, as an other
implementation might use a different algorithm for the same private use
identifier.

Regards
Martin

[1]http://git.strongswan.org/?p=strongswan.git;a=blob;f=src/libhydra/plugins/kernel_pfkey/kernel_pfkey_ipsec.c;h=f5786447b1c8b827e9b62331d7145111a500693f;hb=HEAD#l517
[2]http://git.strongswan.org/?p=strongswan.git;a=blob;f=src/libstrongswan/crypto/crypters/crypter.h;h=3bf039681f7b9148d926708a18cdcc1148741ed5;hb=HEAD#l33
[3]http://git.strongswan.org/?p=strongswan.git;a=blob;f=src/libstrongswan/crypto/proposal/proposal_keywords.txt;h=208c6715b193bca5c6d6847220300fefac54721a;hb=HEAD#l32