Regards, Bala
On 29 September 2016 at 01:43, Peltonen, Janne (Nokia - FI/Espoo) <[email protected]> wrote: > Hi, > > Comment inline: > >> From: Bala Manoharan [mailto:[email protected]] >> Comments inline... >> >> On 27 September 2016 at 10:07, Peltonen, Janne (Nokia - FI/Espoo) >> <[email protected]> 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. > > Having some sort of port id available might be quite useful. > Deducing the actual port from just the packet header may be > difficult or even impossible with e.g. link aggregation. We can add the pktio interface (similar to port ID) as part of the packet metadata. > >> >> > >> > 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? > > Just to be clear, I was referring to input processing in the case > that application first receives a packet (say, a VxLAN packet), > processes it (say, strips VxLAN header) resulting in an IPsec > packet. The IPsec packet is then given to the ODP implementation > for IPsec inbound processing (i.e. decapsulation) and the ODP > implementation later gives the clear text packet back to the > application for the application specific processing of the higher > layers. > > So, an API function with "send" in the name would not sound > right. The SA lookup based on the SPI of the received packet > could be done by ODP or maybe in some cases by the application. > > In the output path (when sending a packet for which IPsec > encapsulation needs to be done), something analogous is > needed. Maybe the packet needs some additional tunneling > encapsulation that needs to be done by the application > after IPsec encapsulation. > > At the risk of stating the obvious, the use cases I have in > mind always involve application specific processing in SW by > the ODP application. In receive and transmit paths of those > packets IPsec processing (decapsulation and encapsulation, > respectively) may be needed. > > Ideally, in inline-case, the application receives the clear text > packet after IPsec decapsulation and sends a clear text > packet that gets IPsec encapsulated and sent out by ODP. > Sometimes this will not be possible and the application must > fall back to look-a-side style acceleration. But in both cases > the application does process the packets as it terminates > the higher protocol layers. Yes I understand the scenario perfectly. The naming of "send" could be renamed to "enqueue" so that there are two different API between application and offload engine one in each direction. > >> >> > >> > 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. > > Yes, something like that is needed, since I think on-demand negotiation > of SAs is an important use case. > >> >> > >> > 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? > > Yes, I think it would be reasonable to let the application be > responsible of handling time based lifetimes and have > a notification mechanism for the byte based SA 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? > > Maybe not, but I think it is something that would eventually be > useful. There are some use cases out there that would need it. > I think it would be good to at least keep the feature in mind > when designing the first version of the API. Makes sense. > >> >> > >> > 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. > > Having MTU info in pktio config would not work if I had multiple > VLANs with different MTUs (a bit weird, but I think possible case). > > It would also not work if I wanted to fragment the packet based > on PMTU, which would be quite reasonable a requirement > especially with red-side fragmentation. Then it would be responsibility of the application to make sure it does not configure an MTU greater than the MTU configured in the packet IO interface. Adding to session is Okay I guess. > > Maybe there could be (P)MTU info in the session or in the policy > and application could keep it up to date as it changes. > >> 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. > > I think a context pointer or some such would be quite ok. > >> >> > >> >> 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. > > Since the L2 header may change when routing changes, it must > then be possible to update that part of the session (as well as > the associated output port) without destroying the session. > > Now I started thinking if there would be a need to change the next > hop even on per-packet basis. Perhaps not in practice (in theory > one could think of a use case of ECMP forwarding based on the > inner packet without replay protection, but I suppose one should > just use multiple SAs in such case). > >> A few packets being sent in the old route shouldn't be a problem I believe. > > A few packets is probably not a problem, but the SA must stay alive. Yes. SA will be alive until the application explicitly changes the SA. Regards, Bala > > BR, Janne > >> >> Regards, >> Bala >> > >> > BR, >> > Janne >> > >> > >> > -----Original Message----- >> > From: lng-odp [mailto:[email protected]] On Behalf Of Bala >> > Manoharan >> > Sent: Monday, September 26, 2016 6:51 PM >> > To: LNG ODP Mailman List <[email protected]> >> > 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
