I hit reply rather than reply all on this. Sorry, this should have been a reply to the mailing list.
Bill ---------- Forwarded message ---------- From: Bill Fischofer <bill.fischo...@linaro.org> Date: Thu, Sep 29, 2016 at 8:07 AM Subject: Re: [lng-odp] IpSec protocol offload proposal To: "Peltonen, Janne (Nokia - FI/Espoo)" <janne.pelto...@nokia.com> Additional thoughts on this thread... On Thu, Sep 29, 2016 at 1:43 AM, Peltonen, Janne (Nokia - FI/Espoo) < janne.pelto...@nokia.com> wrote: > Hi, > > Comment inline: > > > From: Bala Manoharan [mailto:bala.manoha...@linaro.org] > > 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. > > 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. > Based on discussions we had this week, the intent is that IPsec decrypt takes a full Ethernet packet as input and produces a full Ethernet packet as output. The output packet no longer has an ESP header since it is now decrypted. After decryption, the output packet would be sent back through the classifier and hence all packet metadata associated with that packet would be available as if it arrived unencrypted in the first place. The additional packet metadata needed would allow the application to know that the packet had been decrypted before it was seen by the application. We need detail on exactly what information from the original packet needs to be propagated to the final decrypted packet as metadata, so this is a timely discussion. > > > > > > > > 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. > The intent is to provide both IPsec lookaside as well as offload, so these cases should be possible. If the classifier recognizes the IPsec packet when it is originally received, then it can send it directly to the IPsec decrypt engine for processing. If it cannot be recognized (e.g., it's in a tunnel of some sort that the classifier doesn't understand) then the packet would be sent to a CoS that the application would process. After it decapsulates the packet the packet can then be sent for decryption as a lookaside operation. One of the assumptions we've made (that needs to be use-case validated here) is that input for offload IPsec is a full Ethernet packet, whereas input for lookaside operations is a "partially digested" packet that starts with the ESP header. We need to be precise as to exactly what options are needed for lookaside operation as far as acceptable packet inputs and available output formats/destinations that are possible. > > > > > > > > > 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. > What we discussed is that the classifier would not do any SPI lookups since it doesn't have that knowledge. The intent is that the classifier simply recognizes the ESP header and can then send the packet directly to the IPsec decrypt engine. That engine would then discover that it can't process the packet and forward it to an appropriate output queue that would be input to the application. So the application would see the undecrypted IPsec packet and can then kick off whatever higher-level processing is needed to establish the credentials that would allow future IPsec packets for this SPI to be handled properly. > > > > > > > > > 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. > This requires support from the IPsec decrypt engine since these triggers need to be configurable on a per-SA basis and byte count are typically on a pre-decrypt basis, which the application doesn't see. Rekeying is normally triggered by packet count, byte count, or elapsed time. We need to discuss what configuration options are needed to accommodate these. Another factor is OFP involvement, as it may be providing higher-level services involving IPsec as well, and in that context IKE, rekeying, etc. would fall under its domain. > > > > > > > > > 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. > We definitely want to keep extensibility in mind, but this is definitely the sort of thing I would not expect to see in the initial release. The intent here is that offload will handle the basics first with SW filling in the exceptional cases and based on need the cases that are fully offloaded can be expanded over time. > > > > > > > > > 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. > > 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. > Please suggest a set of APIs or API extensions that cover these use cases, as they are worth discussing in one of the ARCH calls. > > > Yes. The crypto keys has to be provided by the implementation. > Keys are negotiated as part of IKE processing, which is outside the scope of this work for now. The ODP crypto APIs simply take keying material as input, assuming they've been obtained elsewhere. This still doesn't cover the cases involving black keys, HSMs, etc., but to date we've not had any requirements or suggested API changes to cover these areas. > > > > > > > >> 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. > Handling large numbers of related queues is the main reason why we're introducing queue groups. A queue group is the target for a PMR and then distributes individual packets sorted into that CoS among the individual queues belonging to the queue group based on a specified set of hash fields or packet subfield that is used as a queue index. > > > > > > > > >> 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. > > BR, Janne > > > > > 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_J5G8HVCkI > Lmddq0GiJ36qhrfzmpw/edit?usp=sharing > > > > > > Regards, > > > Bala >
