JannePeltonen replied on github web page:
include/odp/api/spec/ipsec.h
line 118
@@ -983,9 +983,55 @@ typedef struct odp_ipsec_op_flag_t {
* These may be used to override some SA level options
*/
typedef struct odp_ipsec_out_opt_t {
+ /** Union of all flag bits */
+ union {
+ /** Option flags. Set flag for those options that are
+ * used, all other options are ignored. */
+ struct {
+ /** Use fragmentation mode option */
+ uint32_t frag_mode: 1;
+
+ /** Use IP parameters option */
+ uint32_t ip_param: 1;
+
+ /** Use TFC padding length option */
+ uint32_t tfc_pad: 1;
+
+ /** Tunnel mode TFC dummy packet. In tunnel mode, set
Comment:
That is right, but there is no limitation in this API.
This bit is just for tunnel mode dummy packets that cannot otherwise be sent.
Transport mode dummy TFC packets are sent in the normal way: The input packet
to an oubound IPsec operation is a well formed IP packet just like in the
normal packet case, but the application just sets the protocol field of the IP
header to 59. The ODP implementation needs the IP header to be there since that
IP header is used (after some adjustments) in the resulting ESP/AH packet. This
is different from tunnel mode where the outer IP header is generated based on
the information in the SA.
> JannePeltonen wrote
> Two cases:
> 1) Enabling TFC dummy packet generation for tunnel-mode SAs that have been
> configured to copy the fields from the inner header. This way the input
> packet to the IPsec operation does not have to contain valid IP header for
> the copying to work which would be difficult to specify for dummy packets
> (e.g. how to tell if the inner packet is IPv4 or IPv6). The fields cannot
> just be left to some default values in dummy packets because that could allow
> one to distinguish the dummy packets from normal packets in the wire,
> rendering TFC dummy packets useless.
>
> 2) Making the current API more complete (regardless of TFC support).
> Currently it is possible to set those fields only to the same SA-specific
> value or copy from the inner header, but not set the value depending on the
> packet. I could imagine that for DSCP there could be real use cases where the
> DSCP cannot just be copied (e.g. since if the inner and outer packet belong
> to different QoS domains with different DSCP interpretation) but the DSCP
> cannot also be the same for all packets of an SA (although It would be better
> to you separate SAs in that case).
>> JannePeltonen wrote
>> Why? The rationale goes that if checksumming is requested in the outbound
>> direction the implementation can always calculate in in SW since that is
>> what the application would have to do otherwise. Inbound direction is
>> different since the need for L4 checksum checking (i.e. is the packet
>> destined to this system of just forwarded) is not yet known at the time of
>> reception (so if an implementation sets the inbound capability, it should
>> mean that it can do checksumming clearly more efficiently than pure SW).
>>> Dmitry Eremin-Solenikov(lumag) wrote:
>>> Hmm. I think RFC 4303 does not limit TFC dummy packets to tunnel mode. One
>>> can generate them in transport mode.
>>>> Dmitry Eremin-Solenikov(lumag) wrote:
>>>> What is the use case for these options?
>>>>> Dmitry Eremin-Solenikov(lumag) wrote:
>>>>> There is one indeed.
>>>>>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>>>>>> Is there no need for a corresponding `chksums_out` capability?
>>>>>>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>>>>>>> I assume this is referring to the `odp_packet_has_ipv4()` and
>>>>>>> `odp_packet_has_ipv6()` accessor functions? Since these bits are only
>>>>>>> accessible via these functions, this forces applications to play a
>>>>>>> guessing game with them and their L4 counterparts. Might it be better
>>>>>>> to consider having `odp_packet_l3_proto()` and `odp_packet_l4_proto()`
>>>>>>> functions?
>>>>>>>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>>>>>>>> Can `flabel` be placed after `dst_addr`? This would avoid the pad
>>>>>>>> bytes that would otherwise be inserted between `dspc` and `flabel`.
https://github.com/Linaro/odp/pull/403#discussion_r162552635
updated_at 2018-01-19 07:33:15
