Hi,
Is this work toward a look-a-side IPsec offload or toward inline
IPsec offload?
How would the application offer packets to IPsec processing and how
would it get the processed packets back and how would it know which
policy and session was applied to the packet? What happens when
an outbound packet matches a policy for which there is no session?
Should there be support for "discard" policies/sessions that just
drop the packets?
It would be nice to have support for multiple instances of SPD and SAD
so that one would e.g. be able to do IPsec with virtual routing and
forwarding (or network namespaces) even when addresses etc overlap.
Does the API promise to do inbound policy check for decapsulated
packets, i.e. check that the clear text packets match a policy
associated with the SA that was used in the decapsulation,
or is it something that the application has to do itself?
IOW, I want to check that packets came through a tunnel they
were supposed to come and not through some unrelated tunnel.
> +typedef enum odp_ipsec_ar_ws {
> + ODP_IPSEC_AR_WS_NONE, /**< Anti-replay is not enabled */
> + ODP_IPSEC_AR_WS_32, /**< Anti-replay window size 32 */
> + ODP_IPSEC_AR_WS_64, /**< Anti-replay window size 64 */
> + ODP_IPSEC_AR_WS_128, /**< Anti-replay window size 128 */
> +} odp_ipsec_ar_ws_t;
I do not see why this would be better than specifying the
anti-replay window as an integer. The implementation would
then be free to select any window size greater or equal to
what was requested. The proposed API would impose somewhat
artificial a restriction and would need to be updated
if/when bigger window sizes would be supported.
> +typedef struct odp_ipsec_params {
There is no information about the used crypto-algorithms
and their keys here.
> + odp_bool_t auto_iv; /** Auto IV generation for each operation. */
What if this is false? Is the IV provided with the packet?
How?
> + odp_bool_t remove_outer_hdr; /** remove outer header - tunnel mode
> decap */
What happens if this is false? ESP/AH gets removed and the
packet appears as IPIP-tunneled packet? Something else?
> +int odp_crypto_ipsec_session_create(odp_crypto_session_params_t *ses_params,
> + odp_ipsec_proto_t ipsec_proto,
> + odp_ipsec_params_t *ipsec_params,
> + odp_crypto_session_t *session_out,
> + odp_crypto_ses_create_err_t *status);
The first parameter looks redundant and the type has not been
defined. I wonder why ipsec_proto is a separate parameter and
not included in ipsec_params like all the other stuff?
> +struct odp_ipsec_spd_params{
How do I put the policies in priority order in case I have
overlapping policies? Not supporting overlapping policies
at all would of course be simpler but a bit restrictive.
> + enum odp_ipsec_policy_redside_fragmentation redside;
> + /**< Fragmentation before Encapsulation option: TRUE/FALSE */
Where does the MTU value come from? I suppose it could be
part of session or policy so that the application could
update it e.g. based on the current idea of PMTU.
I suppose the application needs to control, on per-packet basis,
to which packets fragmentation is applied. I suppose normally one
might want to apply it to locally generated packets regardless of
DF and to forwarded packets with DF not set.
BR,
Janne
