Balasubramanian Manoharan(bala-manoharan) replied on github web page:
include/odp/api/spec/ipsec.h
line 168
@@ -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.
Comment:
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_r162610910
updated_at 2018-01-22 14:10:40
