Balasubramanian Manoharan(bala-manoharan) replied on github web page:
include/odp/api/spec/ipsec.h
line 151
@@ -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. */
+ uint32_t tfc_dummy: 1;
+ } flag;
+
+ /** All flag bits */
+ uint32_t all_flags;
+ };
+
/** Fragmentation mode */
odp_ipsec_frag_mode_t frag_mode;
+ /** Union of IP parameters */
+ union {
+ /** Override IPv4 parameters in outer header creation.
+ * IP addresses are ignored. */
+ odp_ipsec_ipv4_param_t ipv4;
+
+ /** Override IPv6 parameters in outer header creation.
+ * IP addresses are ignored. */
+ odp_ipsec_ipv6_param_t ipv6;
+ };
+
+ /** TFC padding length
+ *
+ * Number of TFC padding bytes added to the packet during IPSEC
+ * processing. Implementation guarantees that the padding does not
+ * contain any confidential information. */
Comment:
"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_r162610488
updated_at 2018-01-22 14:10:40
