Balasubramanian Manoharan(bala-manoharan) replied on github web page:
include/odp/api/spec/ipsec.h
line 124
@@ -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
+ * this flag to create a TFC dummy packet. The flag
+ * indicates packet data (at L3 offset) does not
+ * contain an inner packet IP header. If SA is
+ * configured to copy IP header fields from inner
+ * packet, those fields must be passed with
+ * IP parameters option. */
Comment:
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_r162613648
updated_at 2018-01-22 14:10:40
