Balasubramanian Manoharan(bala-manoharan) replied on github web page:
include/odp/api/spec/ipsec.h
line 180
@@ -1224,16 +1224,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 in tunnel mode have both IPv4 and IPv6 flags cleared and
+ * may contain some (dummy) data.
*
* Each successfully transformed packet has a valid value for these metadata
* regardless of the inner packet parse configuration
* (odp_ipsec_inbound_config_t):
- * - L3 offset: Offset to the first byte of the (outmost) IP header
- * - pktio: For inline IPSEC processed packets, original packet input
- * interface
+ * - l3_offset: Offset to the first byte of the original IP packet. The value
+ * is implementation specific for tunnel mode TFC dummy packets.
+ * - has_ipv4/6: Specifies if the original packet is IPv4 or IPv6. For tunnel
+ * mode TFC dummy packets neither flag is set.
Comment:
In tunnel mode not setting ipv4/v6 flag for dummy packet should be fine. But
how do Dummy packets get handled in transport mode? coz if the implementation
does inner packet parsing then transport mode dummy packet will have the valid
ipv4/v6 flag set.
> Dmitry Eremin-Solenikov(lumag) wrote:
> After discussion during the call: this needs to be rephrased to point that
> TFC dummy packets can be truncated by an implementation. Maybe we should not
> mention that "restructured data" is returned for TFC dummy packet.
>> JannePeltonen wrote
>> On January 17 pvanlee...@insidesecure.com wrote in the lng-odp list:
>>
>> "However, for the EIP96 - EIP197PP range of solutions our HW /is/ capable of
>> TFC padding insertion, we would just need to expose this through our driver
>> and firmware. So API-wise you might want to support adding n bytes of TFC
>> padding for outbound. "
>>
>> So apparently such HW exists. And even with pure SW solution, I do not see
>> why buffer space would need to be allocated from application specific pools
>> for the padding data.
>>> Dmitry Eremin-Solenikov(lumag) wrote:
>>> I have mixed feelings towards this option. Allocating additional buffer
>>> space from application-specific pools seems fragile to me. Maybe we can
>>> leave this out for now till there is hardware which actually supports
>>> generating additional TFC padding?
>>>> Dmitry Eremin-Solenikov(lumag) wrote:
>>>> Limiting this option to tunnel mode only seems logical but not that
>>>> effective for an application. Maybe we can allow using this option
>>>> together with L3 header override to create transport mode dummy packets.
>>>> Then it would be just easier to inject dummy packets in transport case.
>>>>> Dmitry Eremin-Solenikov(lumag) wrote:
>>>>> @psavol I don't feel good about the 'if dummy flag is set, only
>>>>> tfc_padding length defines the dummy packet length' proposal. Your
>>>>> current phrase (`packet_len + tfc_padding` seems better to me).
>>>>> @bala-manoharan if we do not provide a packet, how will implementation
>>>>> allocate a packet for SYNC/ASYNC modes?
>>>>>> Dmitry Eremin-Solenikov(lumag) wrote:
>>>>>> Also it should be documented that in INLINE mode hardware might drop
>>>>>> dummy packets on its own, without reporting them to an application.
>>>>>>> Dmitry Eremin-Solenikov(lumag) wrote:
>>>>>>> I'm actually thinking about adding special `is_dummy` flag here.
>>>>>>> Transport mode TFC packets should have `has_ipv4`/`has_ipv6` flag
>>>>>>> according to their headers. However having special flag which can be
>>>>>>> checked by an application will allow one to drop them without going to
>>>>>>> L3 headers.
>>>>>>>> Dmitry Eremin-Solenikov(lumag) wrote:
>>>>>>>> This will cause troubles for NXP hardware, which does not output
>>>>>>>> decrypted TFC packet, if I understand in right. @NikhilA-Linaro could
>>>>>>>> you please comment?
>>>>>>>>> Balasubramanian Manoharan(bala-manoharan) wrote:
>>>>>>>>> We can also decide whether the application has to provide a valid
>>>>>>>>> odp_packet_t handle when "tfc_dummy" flag is set.
>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>> done
>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>> About 2 vs. 3 level capability. Two levels should be enough (no,
>>>>>>>>>>> yes). If there are 3 levels (no, yes in SW, yes in HW), throughput
>>>>>>>>>>> would be optimized if application enables checksumming only when
>>>>>>>>>>> it's done in HW. Application would not request SW checksum for all
>>>>>>>>>>> packets, as it can filter out those that actually need it (e.g.
>>>>>>>>>>> half of the packets) and then do it in SW only for those.
>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>> I think the offset is already known (and possibly set into packet
>>>>>>>>>>>> header) before implementation knows a packet is dummy, since
>>>>>>>>>>>> that's part of decrypt operation (== start of cipher/clear text
>>>>>>>>>>>> data). This spec allows L3 offset to be left at an implementation
>>>>>>>>>>>> specific value, e.g. 0 if HW did drop the dummy content, e.g. 28
>>>>>>>>>>>> if HW does not recognize dummy packets (just another decrypted
>>>>>>>>>>>> packet from HW point of view).
>>>>>>>>>>>>
>>>>>>>>>>>> When dummy content is left there, application can see how much it
>>>>>>>>>>>> is and the content. May be that helps in debugging dummy vs
>>>>>>>>>>>> non-dummy packet, etc.
>>>>>>>>>>>>
>>>>>>>>>>>> Result of an IPSEC decrypt transformation is always the original
>>>>>>>>>>>> packet (== what the sender did send). L3 offset points to the
>>>>>>>>>>>> first byte of the original data. If dummy data was dropped, then
>>>>>>>>>>>> there's no data.
>>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>>> This should be clear for implementers already from RFC, but it's
>>>>>>>>>>>>> also here since it's easy to forget that data cannot be sent out
>>>>>>>>>>>>> from any random address (e.g. end of an buffer). Implementation
>>>>>>>>>>>>> must be sure about the memory content (zeros, rand, counter)
>>>>>>>>>>>>> before including that as padding.
>>>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>>>> We can also decide to write the spec differently. I.e. if dummy
>>>>>>>>>>>>>> flag is set, only tfc_padding length defines the dummy packet
>>>>>>>>>>>>>> length. May be it's better spec and as easy to implement than
>>>>>>>>>>>>>> the one above.
>>>>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>>>>> It has been specified that number of bytes to IPsec encrypt is
>>>>>>>>>>>>>>> always: packet_len - l3_offset + tfc_padding. In all other
>>>>>>>>>>>>>>> cases (than TFC dummy in tunnel mode), L3 offset point to first
>>>>>>>>>>>>>>> byte of IP header. With dummy, application is not required to
>>>>>>>>>>>>>>> form an IP header and also packet data content is ignored. So,
>>>>>>>>>>>>>>> application can e.g. set L3 offset = 0, packet_len = 0 and
>>>>>>>>>>>>>>> tfc_padding = 512, OR L3 offset = 64, packet_len = 320,
>>>>>>>>>>>>>>> tfc_padding = 256, OR L3 offset = 0, packet_len = 512,
>>>>>>>>>>>>>>> tfc_padding= 0.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> All those examples would end up implementation creating a 512
>>>>>>>>>>>>>>> byte dummy packet.
>>>>>>>>>>>>>>>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>>>>>>>>>>>>>>>> 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_r163841006
updated_at 2018-01-25 14:50:43
