Bill Fischofer(Bill-Fischofer-Linaro) 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:
The implementation simply needs to ensure that it doesn't reuse application
buffers, as they may contain residual confidential information. This can be
done by inserting zeros or random bytes as the implementation chooses. Given
the importance of security, it's appropriate to put this caveat in the spec as
a reminder to implementations.
> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
> 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_r163062905
updated_at 2018-01-22 20:46:01
