Hi,
A few questions and comments:
Can there be VLAN tags in the received packets? How do I know what L2
headers a received packet originally had and through which interface it
was received?
How do I fall back to look-a-side mode when e.g. an IPsec packet came in
inside other tunnel (e.g. VxLAN, GRE) that I need to terminate first in SW
and then give the packet to ODP for IPsec decapsulation using the same SA
that is also used in inline acceleration? And the same for outbound
processing.
What happens when there is a policy but no session (since IKE has not
negotiated the SA yet and expects a traffic based trigger)? How do I get
to know which SA I need to negotiate?
How do I implement byte based SA lifetimes? I think some sort of advance
notification about impending byte based life time expiry (and also
seqno overflow) would be needed.
Should there be support for ordering/prioritization of policy selectors
so that overlapping policies could be supported? Should there be discard
rules?
Does ODP check that a decapsulated packet matches a policy associated
with the SA the packet used?
Virtual routing and forwarding support (i.e. multiple IPsec instances)
would be nice. That would mean that all lookups should take also VRF ID
(or IPsec context) into account. VRF ID would be derived from network
port plus VLAN tag.
Keys for crypto-algorithms seem to be missing.
Where is MTU information for the fragmentation decision? How can I
control which packets can be fragmented and which not (handling of
locally originated and forwarded traffic may have to be different).
> Application creates an odp_ipsec_session_t handle which is configured
> with [...] and additionally an output queue
Is there any practical scalability limit on the number of queues?
What if I have 100 k inbodund SAs and want to know through which SA each
packet was received? Can I just create 100 k queues and let the scheduler
handle it?
> ODP_IPSEC_PROTO_AH_ESP
Doesn't this need two separate SA (and thus two SPIs etc)? In that case
single session cannot contain the parameters for both.
> /* In tunnel mode source and destination address are copied
> * from inner header to outer header */
> odp_bool_t header_preservation;
I am not sure if this is very useful. How are the tunnel endpoints
specified in the general case when they cannot be copied from the
inner header?
> int odp_ipsec_send(odp_packet_t pkt);
A packet that is sent out needs an ethernet header. Where does it
come from? I suppose it could be part of the session data, but that
would imply that it must be possible to update the session data
on the fly when routes change.
BR,
Janne
-----Original Message-----
From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Bala
Manoharan
Sent: Monday, September 26, 2016 6:51 PM
To: LNG ODP Mailman List <lng-odp@lists.linaro.org>
Subject: [lng-odp] IpSec protocol offload proposal
Hi Team,
Pls find the link to IpSec protocol offload proposal.
https://docs.google.com/document/d/1G6IXm9ydpFZNKU_J5G8HVCkILmddq0GiJ36qhrfzmpw/edit?usp=sharing
Regards,
Bala
