Comments inline... On 27 September 2016 at 10:07, Peltonen, Janne (Nokia - FI/Espoo) <janne.pelto...@nokia.com> wrote: > 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?
The original Header of the packet will be stored as part of the headroom of the decrypted packet. > > 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. We can add additional API to send the packet to the IpSec offload engine (enhancement to odp_ipsec_send()) where the packet is first received by the application and then passed to the offload engine. In the model in which the packets are received by the application, does the application do SA lookup or is it something which has to be done by the implementation? > > 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? This was not covered in the scope of the initial proposal, but we can add an error queue or notification queue to the session so that the implementation can send notification message through the notification queue. > > 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. This could be part of a notification message, Again since the control part is handled by the application, which part of SA expiry should be initiated by the implementation? Is it possible that the application take care of SA lifetime expiry while the implementation handles/notifies the byte based expiry? > > Should there be support for ordering/prioritization of policy selectors > so that overlapping policies could be supported? Should there be discard > rules? Yes. I had not defined the security accessor selector structure but that should include ordering and prioritisation. > > 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. Is this something required in the first version of the IpSec offload engine? > > 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). The MTU information is available as part of pktio configuration. i.e uint32_t odp_pktio_mtu(odp_pktio_t pktio)) Alternatively if you want this fragmentation information (no.of packets to fragment into ) on a per-packet basis then it can be added to packet metadata. Yes. The crypto keys has to be provided by the implementation. > >> 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? Creating 100 K queues might not be scalable from the application point of view. The idea here was that the application receives the packets directly from the scheduler without going through the classifier engine. Do you have a use-case where each session output is required in different output queues? or we can simply add a context pointer to the session and the same can be copied to the packet meta-data if that would solve your case. > >> 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. Yes. This value should be remove. The sessions will be of type AH or ESP. > >> /* 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? It was discussed in the meeting here and the idea is that the outer header is passed as a parameter during session create by the application. > >> 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. I think adding this to the session makes more sense than being part of packet meta-data. A few packets being sent in the old route shouldn't be a problem I believe. Regards, Bala > > 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
