Inline responses.
Regards
Nikhil
-----Original Message-----
From: lng-odp [mailto:[email protected]] On Behalf Of Peltonen,
Janne (Nokia - FI/Espoo)
Sent: Tuesday, September 27, 2016 9:24 PM
To: [email protected]; [email protected]
Subject: Re: [lng-odp] [PATCH] api:crypto: Adding IPSEC protocol APIs.
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?
[NA] This effort is towards both having look-a-side as well as the inline
IPSEC offload. For look-a-side application can offer packets to engine using
same APi odp_crypto_operation. Also for look-aside only SA info needs to be
offloaded to engine as policy matching will be done in GPP.
Should there be support for "discard" policies/sessions that just drop the
packets?
[NA] Yes there needs to be. Currently that can be supported through
Classification APIs.
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.
[NA] Yes. That area needs to be looked into yet.
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.
[NA] Yes. I would like to add option for user to configure that wether to do
inbound SPD verification. By default it would do that.
> +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.
[NA] Agree. Will change that in next version.
> +typedef struct odp_ipsec_params {
There is no information about the used crypto-algorithms and their keys here.
[NA] This info already exist in odp_crypto_session_params_t. For creating ipsec
session user needs to provide both session params. This is to avoid duplication
of same params again.
> + odp_bool_t auto_iv; /** Auto IV generation for each operation. */
What if this is false? Is the IV provided with the packet?
How?
Yes. In odp_crypto_session API there is an option of providing IV per packet IV
or you may also choose per session IV.
> + 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?
[NA] Nope. It will not remove ESP AH header as well. In this case it will just
decrypt the packet contents, and verify the ICV.
> +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?
[NA] This is done in a view that ESP and AH may have seprate set of params. It
can be included as well.
> +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.
[NA] Yes this may be included in next version. We may specify the location
where this policy needs to be inserted.
> + 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.
[NA] for Autonomous IPSEC , i.e. full offload it will be fetched from the
interface on which the packet is outgoing.
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
