Petri Savolainen(psavol) replied on github web page:
include/odp/api/spec/ipsec.h
line 179
@@ -1210,16 +1256,22 @@ typedef struct odp_ipsec_status_t {
*
* The operation does packet transformation according to IPSEC standards (see
* e.g. RFC 4302 and 4303). Resulting packets are well formed, reconstructed
- * original IP packets, with IPSEC headers removed and valid header field
values
- * restored. The amount and content of packet data before the IP header is
- * undefined.
+ * original IP (or TFC dummy) packets, with IPSEC headers removed and valid
+ * header field values restored. The amount and content of packet data before
+ * the IP header is undefined. TFC padding may follow the IP packet payload,
+ * in which case packet length is larger than protocol headers indicate.
+ * TFC dummy packets have both IPv4 and IPv6 flags cleared, although L3 offset
+ * is set also for those.
*
* Each successfully transformed packet has a valid value for these metadata
* regardless of the inner packet parse configuration
* (odp_ipsec_inbound_config_t):
- * - L3 offset: Offset to the first byte of the (outmost) IP header
- * - pktio: For inline IPSEC processed packets, original packet input
- * interface
+ * - l3_offset: Offset to the first byte of the original IP (or TFC dummy)
+ * packet
+ * - has_ipv4/6: Specifies if the original packet is IPv4 or IPv6. For tunnel
+ * mode TFC dummy packets neither flag is set.
Comment:
Application needs to anyway check if packet is v4 or v6. Today it's checking
that from first byte of the packet. With TFC tunnel mode, first byte is garbage
that cannot be used any more. So, application uses these APIs instead in if -
else if - else fashion. There's no more guessing than before.
> Petri Savolainen(psavol) wrote:
> yes it could. I try to remember that if v2 is needed.
>> Petri Savolainen(psavol) wrote:
>> Actually, today's pktio capa is too permissive as all config options are
>> automatically capas. That should be changed to align this: pkt input
>> checksums have capas, output not. Application does not ask output checksum
>> when not needed. On input application does not have a change to filter
>> packet checksum checking before it sees the packet, but on output it can
>> filter the checksum generation.
>>> JannePeltonen wrote
>>> 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_r162565586
updated_at 2018-01-19 08:55:01
