As discussed during yesterdays ODP call, these are the capabilities of Inside Secure IPsec hardware.
First, it's important to establish that we don't have just 1 IPsec solution, we have a whole family of solutions spanning various cost/performance/feature trade-offs. In least-to-most capabilities & performance order: EIP93, EIP94, EIP96, EIP97, EIP198, EIP197, EIP197PP. On top of that we have some very high speed AES-GCM-only combined IPsec/MACsec solutions. 1) TFC padding: none of our solutions currently expose such functionality, deferring both TFC padding insertion and removal to the application. However, for the EIP96 - EIP197PP range of solutions our HW /is/ capable of TFC padding insertion, we would just need to expose this through our driver and firmware. So API-wise you might want to support adding n bytes of TFC padding for outbound. Assuming there's an actual application-independent practical use case for that. 2) No Next Header (NH=59) handling: all of our solutions would handle this the same as any other protocol, encrypting or decrypting it as usual depending on direction. The way I read the RFC, that's probably not the intention(?). I get the impression that the IPsec payload can just be random garbage, i.e. it doesn't have to decrypt to anything that makes sense and it doesn't have to authenticate properly (to facilitate fast generation of such packets by skipping actual cryptographic operations). I guess on outbound that means our HW would be doing unnecessary cryptographic operations, which does not need to be a problem since it doesn't really slow us down. Same on inbound but there our HW would likely be detecting authentication failures. Those would need to be blocked by the ODP driver due to NH=59, or the ODP driver could drop NH=59 packets altogether, not delivering them to the application (I guess you would have to make a decision on that). Should actually be transparent to the API, save perhaps for some switch to enable/disable automatic NH=59 packet dropping (if desired). 3) Checksum offload: none of our solutions do any checksum offloading. They only do /incremental/ IPv4 checksum /updates/ to match any IPv4 header updates they need to do. Our solutions do not modify anything below the IP layer, so they don't bother with UDP/TCP checksums at all. So, if I understand correctly, this means any checksum generation and verification would need to be done in the ODP driver for our engines. This is probably not desirable (performance-wise) in case of a scenario (i.e. IPsec gateway) where the connection is not terminated at our engine. So some method to defer this to the application would be most welcome. Regards, Pascal [http://medias.infostrates.fr/b2c/insidesecure/signatureMail/inside-logo-signature.jpg] Pascal van Leeuwen Silicon IP Architect, Multi-Protocol Engines Tel. : +31 (0)73 65 81 900 www.insidesecure.com<http://www.insidesecure.com/> CONFIDENTIALITY - This e-mail and any attachments hereto are intended only for use by the addressee(s) named herein and may contain confidential information. If you are not the named recipient, please notify the sender immediately and do not disclose the contents to any person, use it for any purpose, or store or copy the information on any medium. Please permanently delete the original copy of this e-mail and/or any attachments thereto and any printout thereof. Thank you.
