Bill Fischofer(Bill-Fischofer-Linaro) 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:
OK
> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
> Please do. While padding is sometimes unavoidable, we should try not to
> introduce it in new structs.
>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>> OK
>>> Balasubramanian Manoharan(bala-manoharan) wrote:
>>> Does this mean the application will create a TFC dummy packet?
>>> I thought we decided that the application will only provide the length and
>>> dummy packet flag and implementation will generate a dummy packet.
>>>
>>>> Balasubramanian Manoharan(bala-manoharan) wrote:
>>>> Does this mean we have to set L3 offset for Dummy packets? Is there any
>>>> use-case for this scenario.
>>>>> Balasubramanian Manoharan(bala-manoharan) wrote:
>>>>> "Confidential information" How does the implementation guarantee this? Do
>>>>> we really need this in the spec?
>>>>>> Petri Savolainen(psavol) wrote:
>>>>>> 3. Also regardless of TFC support. If inner packet is IPv4, but outer is
>>>>>> IPv6 and e.g. flabel has been configured to be copied from inner to
>>>>>> outer - there's no flabel in inner packet to copy. So, application is
>>>>>> able to use this option to pass per packet IPv6 parameters when inner is
>>>>>> IPv4, and vice versa.
>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>> 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_r163061720
updated_at 2018-01-22 20:40:22
