I agree that looking at protocol offload fresh rather than trying to graft it onto the existing crypto algorithm offload might be a good approach. If after doing that we find convergence possibility then we could look at that as well, or retain the existing crypto APIs for backward compatibility with those apps that are using them.
Bill On Fri, Sep 26, 2014 at 4:25 PM, Rosenboim, Leonid < [email protected]> wrote: > I am afraid my point was misunderstood - here is another way to look at > this: > > > With the approach I proposed, an application that use one of the > standard security protocols, would call a completely new, separate security > API. > > Applications that predate the new security API, or are running a protocol > that is not one of the well known protocols, would use the current cipher > offload API. > > Platforms that implement full-protocol processing would implement both > APIs in HW. > > Platforms that only have cipher hardware will implement the current API in > HW, and the new protocol-level API in software on top of the current Crypto > API. > > > The new protocol-aware API might be called "NetSec API", and could be > part of ODP 2.0. > > > - Leo > > > ------------------------------ > *From:* Job Abraham <[email protected]> > *Sent:* Thursday, September 25, 2014 5:08 AM > *To:* Bill Fischofer > *Cc:* Rosenboim, Leonid; Jacob, Jerin; lng-odp > > *Subject:* Re: [lng-odp] ODP API enhancement porposal for IPsec > > Hi All, > > The current proposal has only the parameters for ipsec proptocol. Yes, > for other protocols the parameter fields need to be enhanced. > > Leo's point to cater for both full protocol & cipher only offload is > valid. We had the same thought process in defining this API. > The protocol type enum has a value "none" (should be set to 0) which can > be used for cipher only offload. So the current applications designed for > cipher only offload can easily migrate to new API with protocol type > "none". > > Regards, > Job > > On Thu, Sep 25, 2014 at 1:23 AM, Bill Fischofer <[email protected] > > wrote: > >> We would be looking at this for ODP v2.0 so I think it's worth starting >> the discussion from that perspective. We discussed the need for ODP >> sprints next year and a "Crypto II" sprint to cover protocol offload might >> be a good candidate. >> >> On Wed, Sep 24, 2014 at 12:56 PM, Rosenboim, Leonid < >> [email protected]> wrote: >> >>> Here are my 2 cents, gents: >>> >>> This API change in my opinion goes counter to the intent of the Crypto >>> API - >>> the API was designed to abstract cryptographic accelerators, either >>> co-processors or instruction set extensions. It was NOT intended to >>> abstract co-processors running specific security protocols. >>> >>> It is my opinion that the abstraction of specific standard security >>> protocols would be better served with a separate API, which deals in >>> security protocols only, as opposed to the detailed operation of certain >>> security protocols. >>> >>> My opinion is based on the fact that applications that are written for >>> the current Crypto API would not be easily portable to use full-protocol >>> accelerators, and would require significant changes. Also, the inverse is >>> true, applications that are designed to take advantage of full-protocol >>> accelerators would not readily translate to platforms that only have >>> conventional cipher acceleration. Since the addition of "protocol >>> awareness" to the Crypto API will not result in application portability, >>> IMHO this addition defeats the purpose of having a standard API. >>> >>> When a full-protocol security API is defined, it would be also >>> implemented in software taking advantage of the present Crypto API, and >>> thence the full-protocol API will be able to run applications that utilize >>> this API on platforms that lack a full-protocol acceleration in hardware. >>> >>> - Leo >>> ________________________________________ >>> From: [email protected] <[email protected]> >>> on behalf of Jacob, Jerin <[email protected]> >>> Sent: Wednesday, September 24, 2014 12:35 AM >>> To: Job Abraham; lng-odp >>> Subject: Re: [lng-odp] ODP API enhancement porposal for IPsec >>> >>> Just my 2 cents. >>> >>> API abstraction seems to be fine but we need to decide on, Are we >>> taking the crypto protocol offload path or not in ODP crypto specification? >>> If we are taking the protocol offload path then we should enumerate all >>> the protocols and find the meta data. >>> >>> Thanks, >>> Jerin. >>> >>> From: [email protected] <[email protected]> >>> on behalf of Job Abraham <[email protected]> >>> Sent: Tuesday, September 16, 2014 3:03 PM >>> To: [email protected] >>> Subject: [lng-odp] ODP API enhancement porposal for IPsec >>> >>> >>> Hi All, >>> >>> >>> Here is a proposal for enhancing ODP crypto APIs to support security >>> protocols like IPsec. >>> >>> >>> As part of the ODP crypto API definitions, the framework for supporting >>> a wide variety of security protocols is defined. The definition of data >>> structures and APIs for crypto functions is defined below. Specifically, a >>> detailed presentation of IPsec related parameters and their usage are >>> defined. IPsec implementation is done by means of specialized offload >>> engines that interface with general cores/other specific cores that perform >>> other network processing functions. >>> >>> >>> >>> Crypto Session Create:- >>> Crypto engine can be used by any of the Security protocols like >>> IPsec/SRTP/SRTCP/TLS etc, hence protocol specific parameters shall be >>> passed during crypto session create. >>> >>> These protocol specific parameters allow accelerator engines to provide >>> more offloaded functionality in NPU. >>> >>> Following APIs are expected to undergo changes during crypto session >>> create: >>> Crypto session create APIs >>> int odp_crypto_session_create(odp_crypto_session_params_t *params, >>> odp_crypto_session_t *session, >>> enum odp_crypto_ses_create_err *status >>> ) >>> >>> >>> int odp_crypto_session_create_async(odp_crypto_session_params_t * >>> params, >>> odp_buffer_t completion_event, >>> odp_queue_t completion_queue ) >>> >>> These API creates the crypto session (blocking/non-blocking). Changes >>> proposed to these API are below. >>> >>> New Enums or Structures:- >>> /** >>> * Crypto protocol - more types can be added based on Security >>> Accelerator capability. >>> */ >>> enum odp_crypto_protocol_type { >>> CRYPTO_IPSEC, >>> CRYPTO_SRTP, >>> CRYPTO_TLS, >>> NONE >>> }; >>> >>> /** >>> * Crypto IPsec direction >>> */ >>> enum odp_ipsec_direction { >>> IPSEC_INBOUND, >>> IPSEC_OUTBOUND >>> }; >>> >>> /** >>> * Crypto IPsec mode >>> */ >>> enum odp_ipsec_mode{ >>> IPSEC_TUNNEL, >>> IPSEC_TRANSPORT >>> }; >>> >>> /** >>> * Crypto IPsec protocol >>> */ >>> enum odp_ipsec_proto{ >>> IPSEC_AH, >>> IPSEC_ESP >>> }; >>> >>> >>> /** >>> >>> * Crypto protocol specific parameters >>> * IPsec parameters >>> * softLifetime: Soft lifetime of an SA, shall be specified either in >>> time or bytes >>> * hardLifetime: Hard lifetime of an SA, shall be specified either in >>> time or bytes >>> * dir: IPsec direction based on operation either INBOUND/OUTBOUND >>> * mode: IPsec mode, can be Tunnel or Transport mode >>> * proto: IPsec Protocol, can be ESP/AH >>> * spi: Security Parameter Index for the IPsec SA session >>> * srcAddr: Source address of tunnel header, (Valid only in Tunnel mode) >>> * dstAddr: Destination address of tunnel header, (Valid only in Tunnel >>> mode) >>> * seqOverFlowFlag: Flag to indicate that the sequence number Over flow >>> is enabled >>> */ >>> struct odp_crypto_protocol_params{ >>> >>> odp_crypto_protocol_type type; >>> >>> union{ >>> /* IPsec Protocol specific parameters */ >>> struct{ >>> uint64_t softLifetime; >>> uint64_t hardLifetime; >>> odp_ipsec_direction dir; >>> odp_ipsec_mode mode; >>> odp_ipsec_proto proto; >>> uint32_t spi; >>> uint32_t srcAddr; >>> uint32_t dstAddr; >>> bool seqOverFlowFlag; >>> }ipsec; >>> >>> >>> /* SRTP Protocol specific parameters */ >>> struct{ >>> }srtp; >>> >>> >>> /* TLS Protocol specific parameters */ >>> struct{ >>> }tls; >>> }; >>> }; >>> >>> >>> Modified Structure:- >>> >>> /** >>> * Crypto API session creation paramters >>> * >>> * TODO: add "odp_session_proc_info_t" >>> */ >>> struct odp_crypto_session_params { >>> enum odp_crypto_op op; /**< Encode versus decode */ >>> enum odp_crypto_combination comb; /**< Operation order */ >>> enum odp_crypto_op_mode pref_mode; /**< Preferred sync vs async */ >>> enum odp_cipher_alg cipher_alg; /**< Cipher algorithm */ >>> odp_key_t *cipher_key; /**< Cipher key */ >>> uint8_t *iv; /**< Cipher Initialization Vector >>> (IV) */ >>> size_t iv_len; /**< Cipher IV length */ >>> enum odp_auth_alg auth_alg; /**< Authentication algorithm */ >>> odp_key_t *auth_key; /**< Authentication key */ >>> odp_queue_t compl_queue; /**< Async mode completion event >>> queue */ >>> odp_crypto_protocol proto_params; /**< ##new Param## Protocol >>> specific params */ >>> }; >>> >>> >>> >>> >>> >>> >>> Crypto Operation in data-path:- >>> int odp_crypto_operation(odp_crypto_op_params_t *params, >>> bool * posted, >>> odp_buffer_t completion_event) >>> >>> This API does the Crypto operation (Encryption/Decryption) in data-path. >>> This API prototype is not changed. But based on crypto protocol defined in >>> crypto session creation, the operation varies. If crypto protocol is none, >>> the existing behavior continues (only the crypto) >>> >>> If the Security protocol is "CRYPTO_IPSEC" during crypto session create, >>> then this API is expected to do following specific IPsec offload >>> functionality. >>> >>> IPsec Encryption:- >>> Plain IP packet with payload is passed to this API to do >>> the IPsec Encryption. API is expected to add the IP tunnel header if >>> required, add the ESP/AH protocol & encrypt the packet. >>> >>> ODP APIs can use crypto accelerators to do the following, else partial >>> functionality can be implemented in CPU & rest can be offloaded to crypto >>> accelerators. >>> >>> o Tunnel IP headers are encapsulated during Tunnel Encryption scenario. >>> o AH/ESP headers are encapsulated during Tunnel/Transport Encryption >>> scenario >>> · Sequence number generation, >>> · Sequence number overflow, >>> · Adding Padding bytes for crypto algorithm block size >>> >>> >>> After completion of crypto operation, application can expect the >>> complete encrypted buffer with Tunnel IP header if any, IPsec protocol >>> ESP/AH & encrypted payload. >>> >>> IPsec Decryption:- >>> Encrypted IP packet with IP header is passed to this API to do the IPsec >>> Decryption. API is expected to remove the IP tunnel header if any, remove >>> the ESP/AH protocol & decrypt the packet. >>> >>> ODP APIs can use crypto accelerators to do the following, else partial >>> functionality can be implemented in CPU & rest can be offloaded to crypto >>> accelerators. >>> >>> o Tunnel IP headers are removed during Tunnel Decryption scenario. >>> o AH/ESP headers removed during Tunnel/Transport Decryption scenario >>> · Anti replay Window mechanism shall be taken care by this API >>> >>> >>> After completion of crypto operation, application can expect the >>> complete decrypted buffer (with removal Tunnel IP header if any, with >>> removal of IPsec protocol ESP/AH). >>> >>> >>> >>> >>> Please share your thoughts on this proposal. >>> >>> >>> >>> >>> Regards, >>> Job >>> >>> >>> >>> >>> >>> _______________________________________________ >>> lng-odp mailing list >>> [email protected] >>> http://lists.linaro.org/mailman/listinfo/lng-odp >>> >>> _______________________________________________ >>> lng-odp mailing list >>> [email protected] >>> http://lists.linaro.org/mailman/listinfo/lng-odp >>> >> >> >
_______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
