Bill Fischofer(Bill-Fischofer-Linaro) replied on github web page:
include/odp/api/spec/ipsec.h
line 47
@@ -382,6 +382,44 @@ typedef struct odp_ipsec_crypto_param_t {
} odp_ipsec_crypto_param_t;
+/** IPv4 header parameters */
+typedef struct odp_ipsec_ipv4_param_t {
+ /** IPv4 source address (NETWORK ENDIAN) */
+ void *src_addr;
+
+ /** IPv4 destination address (NETWORK ENDIAN) */
+ void *dst_addr;
+
+ /** IPv4 Differentiated Services Code Point */
+ uint8_t dscp;
+
+ /** IPv4 Don't Fragment bit */
+ uint8_t df;
+
+ /** IPv4 Time To Live */
+ uint8_t ttl;
+
+} odp_ipsec_ipv4_param_t;
+
+/** IPv6 header parameters */
+typedef struct odp_ipsec_ipv6_param_t {
+ /** IPv6 source address (NETWORK ENDIAN) */
+ void *src_addr;
+
+ /** IPv6 destination address (NETWORK ENDIAN) */
+ void *dst_addr;
+
+ /** IPv6 Differentiated Services Code Point */
+ uint8_t dscp;
+
+ /** IPv6 flow label */
+ uint32_t flabel;
Comment:
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_r163061616
updated_at 2018-01-22 20:39:53
