Dmitry Eremin-Solenikov(lumag) replied on github web page:
include/odp/api/spec/ipsec.h
line 36
@@ -1223,9 +1223,12 @@ typedef struct odp_ipsec_status_t {
* 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 (outmost) IP header
+ * - IPv4/IPv6 flags: These flags can be used to determine packet contents.
+ * If neither IPv4 nor IPv6 flag are set, received packet is
+ * TFC dummy packet and should be dropped by an application
+ * - pktio: For inline IPSEC processed packets, original packet input
+ * interface
Comment:
`odp_ipsec_in_enq()` just refers to `odp_ipsec_in()` function. As for inline
processing, an application should be prepared to receive them, because some
hardware can not drop them.
> Dmitry Eremin-Solenikov(lumag) wrote:
> I moved it to a separate comment, because of `ESP_TFC_PADDING_NOT_SUPPORTED`
> notification. I can still drop it.
>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>> Is this not equally applicable to `odp_ipsec_in_enq()`? And what about
>> packets received inline? Are we assuming that TFC dummy packets are dropped
>> by the inline RX path? That should also be documented if yes. If not then
>> application must be prepared to receive them that way as well.
>>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>>> I thought we discussed removing these capabilities from Tiger Moth?
>>>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>>>> @JannePeltonen I think @lumag's latest wording is concise. Any application
>>>> using TFC should be familiar with it's requirements and we shouldn't have
>>>> to repeat the RFC here.
>>>>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>>>>> OK. Agree with this approach for Tiger Moth.
>>>>>> JannePeltonen wrote
>>>>>> > I see no harm in keeping it
>>>>>>
>>>>>> I understand you refer to the tfc_padding_truncate capability. Note that
>>>>>> the proposal to get rid of it and discussion on that (with comments from
>>>>>> Petri too) are located elsewhere in this tool.
>>>>>>
>>>>>> That said, the harm of keeping the capability (in addition to growing
>>>>>> the API) is that the capability makes a promise that may (depending on
>>>>>> what value zero means) unnecessarily restrict implementations where the
>>>>>> fate of the padding is not the same globally in the whole system and at
>>>>>> all times (e.g. NIC based IPsec offload where padding is removed or not
>>>>>> depending no through which NIC the packet came in, or a system where
>>>>>> removal of the padding depends somehow on the packet).
>>>>>>
>>>>>> If the capability is kept, its meaning needs to be documented better,
>>>>>> including specifying what kinds of TFC padding it applies to (see other
>>>>>> comments regarding that).
>>>>>>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>>>>>>> @bala-manoharan @NikhilA-Linaro Please provide input here.
>>>>>>>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>>>>>>>> This is useful information for the application to know about how the
>>>>>>>> implementation will behave. Applications are free to ignore this if
>>>>>>>> they wish, but I see no harm in keeping it.
>>>>>>>>> Dmitry Eremin-Solenikov(lumag) wrote:
>>>>>>>>> @psavol Yes, but it requires to call `odp_ipsec_result()` (which can
>>>>>>>>> be quite heavyweight). Currently it is possible to forward packets
>>>>>>>>> right after calling `odp_packet_has_error()` and
>>>>>>>>> `odp_packet_has_ipv4()`, which can be inlined to just bit checks.
>>>>>>>>>
>>>>>>>>> Anyway, this is now a question to @bala-manoharan and @NikhilA-Linaro
>>>>>>>>> if it would be easy to add next_header field to
>>>>>>>>> `odp_ipsec_packet_result_t`
>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>> Application needs to anyway check if
>>>>>>>>>> * packet/ipsec operation result has errors
>>>>>>>>>> * IP version of packet (== what's in the tunnel)
>>>>>>>>>>
>>>>>>>>>> If we add result.next_header field, application can use that for
>>>>>>>>>> both checking IP version and NONH in one switch case. There's no
>>>>>>>>>> extra check for NONH.
>>>>>>>>>>
>>>>>>>>>> if (result.status != 0)
>>>>>>>>>> goto error;
>>>>>>>>>>
>>>>>>>>>> switch (result.next_header) {
>>>>>>>>>> case IPV4:
>>>>>>>>>> ....
>>>>>>>>>> case IPV6:
>>>>>>>>>> ....
>>>>>>>>>> case NONH:
>>>>>>>>>> odp_packet_free(pkt);
>>>>>>>>>> break;
>>>>>>>>>> default:
>>>>>>>>>> goto error;
>>>>>>>>>>
>>>>>>>>>>> Dmitry Eremin-Solenikov(lumag) wrote:
>>>>>>>>>>> @psavol I agree with your arguments. However I'm worried about
>>>>>>>>>>> fast-forwarding use case. Do you think it will make sense to make
>>>>>>>>>>> tfc-packet warning (or even just flag) but still require that
>>>>>>>>>>> `odp_packet_has_error()` returns true for such packets?
>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>> From IPSEC operation point of view a successfully decrypted dummy
>>>>>>>>>>>> packet is a successful operation (SA matched, hash was OK, decrypt
>>>>>>>>>>>> was OK, protocol headers were OK, no replay issues, etc). Just the
>>>>>>>>>>>> payload format is different than usual. If TFC is really used to
>>>>>>>>>>>> hide traffic pattern, all spare capacity of the connection could
>>>>>>>>>>>> be filled by dummy packets. So, it would be more common for
>>>>>>>>>>>> application to receive these vs. the normal packet (as long as HW
>>>>>>>>>>>> is not dropping dummies).
>>>>>>>>>>>>
>>>>>>>>>>>> So, I'd like to reserve error/warning bits for the cases when
>>>>>>>>>>>> there's really a problem (SA configuration miss-match, attack,
>>>>>>>>>>>> broken sender implementation, etc).
>>>>>>>>>>>>> Dmitry Eremin-Solenikov(lumag) wrote:
>>>>>>>>>>>>> We might add next_proto field to packet_result. @NikhilA-Linaro
>>>>>>>>>>>>> how hard would it be to get this field on your platform?
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'm against using warning bit for dummy packets. From ODP packet
>>>>>>>>>>>>> flow point of view, dummy packet is clearly an errorneous packet.
>>>>>>>>>>>>>> Balasubramanian Manoharan(bala-manoharan) wrote:
>>>>>>>>>>>>>> Hmm... I misread the specification so LOOKUP_DSTADDR_SPI only
>>>>>>>>>>>>>> uses ip addr and proto field for lookup and does not validate
>>>>>>>>>>>>>> the src/dst ip address or proto filed after decryption. I
>>>>>>>>>>>>>> believe this validation of IP addr and version can be done by
>>>>>>>>>>>>>> the HW and could be something to add as an enhancement to the
>>>>>>>>>>>>>> spec in the future.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Yes, we could add this SA to packet result but since the RFC
>>>>>>>>>>>>>> specifies in the implementation note to discard the dummy packet
>>>>>>>>>>>>>> after the reception I was inclined towards not updating these
>>>>>>>>>>>>>> structures for dummy packets.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> What is your opinion on updating the next protocol field in
>>>>>>>>>>>>>> odp_packet_result vs adding a warning bit for dummy packet?
>>>>>>>>>>>>>>> JannePeltonen wrote
>>>>>>>>>>>>>>> ODP_IPSEC_LOOKUP_DSTADDR_SPI means that for an SA to match a
>>>>>>>>>>>>>>> received packet, both the SPI and the destination IP address of
>>>>>>>>>>>>>>> the received ESP/AH packet must match those configured in the
>>>>>>>>>>>>>>> SA. This lookup must happen before IPsec processing
>>>>>>>>>>>>>>> (decryption), i.e. before it is even possible to know that the
>>>>>>>>>>>>>>> packet is actually a dummy TFC packet. You have to find the
>>>>>>>>>>>>>>> correct SA and perform decryption before you can tell whether a
>>>>>>>>>>>>>>> received packet is a genuine data packet or a dummy TFC packet.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> An application expects the used SA to be set in the packet
>>>>>>>>>>>>>>> result and, IMHO, dummy packets should not be any different
>>>>>>>>>>>>>>> since they got processed using the SA.
>>>>>>>>>>>>>>>> Balasubramanian Manoharan(bala-manoharan) wrote:
>>>>>>>>>>>>>>>> I was referring to ODP_IPSEC_LOOKUP_DSTADDR_SPI. This cannot
>>>>>>>>>>>>>>>> be matched in case of NH = 59. Actually, this raises
>>>>>>>>>>>>>>>> another question. Do you really need the SA from which this
>>>>>>>>>>>>>>>> Dummy packet was received in the application? Like do we have
>>>>>>>>>>>>>>>> to fill the SA value in the odp_ipsec_packet_result_t field?
>>>>>>>>>>>>>>>>> JannePeltonen wrote
>>>>>>>>>>>>>>>>> What selector checks are you referring to? Traffic selectors
>>>>>>>>>>>>>>>>> are handled fully in the application side. The ODP
>>>>>>>>>>>>>>>>> implementation does not know the traffic selectors and cannot
>>>>>>>>>>>>>>>>> do any checks anyway.
>>>>>>>>>>>>>>>>>> Balasubramanian Manoharan(bala-manoharan) wrote:
>>>>>>>>>>>>>>>>>> We added this capability mainly coz NXP were removing the
>>>>>>>>>>>>>>>>>> padding and Cavium was not removing the padding. If from the
>>>>>>>>>>>>>>>>>> application point of view you are fine with the wording you
>>>>>>>>>>>>>>>>>> have suggested above then this capability can be removed.
>>>>>>>>>>>>>>>>>>> Balasubramanian Manoharan(bala-manoharan) wrote:
>>>>>>>>>>>>>>>>>>> In case if we update the warning bit when the dummy packet
>>>>>>>>>>>>>>>>>>> is found then there will not be much impact on the
>>>>>>>>>>>>>>>>>>> application side since odp_ipsec_status_t consists both
>>>>>>>>>>>>>>>>>>> error and warning bits. Updating next proto field in
>>>>>>>>>>>>>>>>>>> ipsec_op_packet_result_t requires implementation to process
>>>>>>>>>>>>>>>>>>> and update this field for every packet.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The only API change required is to specify clearly that
>>>>>>>>>>>>>>>>>>> in-case of a dummy packet the implementation will not do
>>>>>>>>>>>>>>>>>>> any selector checks on the received packets.
>>>>>>>>>>>>>>>>>>>> JannePeltonen wrote
>>>>>>>>>>>>>>>>>>>> I was just pointing out that from functional completeness
>>>>>>>>>>>>>>>>>>>> perspective API changes are not strictly needed. But as
>>>>>>>>>>>>>>>>>>>> was discussed in the Wednesday meeting, having the next
>>>>>>>>>>>>>>>>>>>> header field in the packet result could be useful and
>>>>>>>>>>>>>>>>>>>> convenient anyway.
>>>>>>>>>>>>>>>>>>>>> Dmitry Eremin-Solenikov(lumag) wrote:
>>>>>>>>>>>>>>>>>>>>> The issue with transport mode ESP and NONH is that we
>>>>>>>>>>>>>>>>>>>>> should never forward NOHN packets even in transport mode.
>>>>>>>>>>>>>>>>>>>>> So both transport and tunnel NONH packets should raise
>>>>>>>>>>>>>>>>>>>>> same exceptions.
>>>>>>>>>>>>>>>>>>>>>> JannePeltonen wrote
>>>>>>>>>>>>>>>>>>>>>> I do not think it is necessary. The next header field
>>>>>>>>>>>>>>>>>>>>>> can be anything (like TCP) in transport mode, but in
>>>>>>>>>>>>>>>>>>>>>> transport mode this API delivers the application and IP
>>>>>>>>>>>>>>>>>>>>>> packet and inserts the protocol value from the next
>>>>>>>>>>>>>>>>>>>>>> header field in the protocol field of the IP header. For
>>>>>>>>>>>>>>>>>>>>>> tunnel mode SAs other next header values than those for
>>>>>>>>>>>>>>>>>>>>>> IPv4, IPv6 and dummy packets should not appear.
>>>>>>>>>>>>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>>>>>>>>>>>>> Maybe a generic solution would be to add the IPSEC next
>>>>>>>>>>>>>>>>>>>>>>> header field value into odp_ipsec_packet_result_t. I
>>>>>>>>>>>>>>>>>>>>>>> guess all implementations should be able to return that
>>>>>>>>>>>>>>>>>>>>>>> after decrypt as RFCs mention also TCP as one possible
>>>>>>>>>>>>>>>>>>>>>>> value. So, payload could be at least IPv4, IPv6, TCP or
>>>>>>>>>>>>>>>>>>>>>>> NONH.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> " The value of this
>>>>>>>>>>>>>>>>>>>>>>> field is chosen from the set of IP Protocol Numbers
>>>>>>>>>>>>>>>>>>>>>>> defined on the
>>>>>>>>>>>>>>>>>>>>>>> web page of Internet Assigned Numbers Authority
>>>>>>>>>>>>>>>>>>>>>>> (IANA). For example,
>>>>>>>>>>>>>>>>>>>>>>> a value of 4 indicates IPv4, a value of 41 indicates
>>>>>>>>>>>>>>>>>>>>>>> IPv6, and a
>>>>>>>>>>>>>>>>>>>>>>> value of 6 indicates TCP."
>>>>>>>>>>>>>>>>>>>>>>>> JannePeltonen wrote
>>>>>>>>>>>>>>>>>>>>>>>> Currently the API promises to give the original packet
>>>>>>>>>>>>>>>>>>>>>>>> back to the application in case of any error. This
>>>>>>>>>>>>>>>>>>>>>>>> would apply to dummy packets too. Maybe the API should
>>>>>>>>>>>>>>>>>>>>>>>> be so that such preservation of the original packet is
>>>>>>>>>>>>>>>>>>>>>>>> not required in the case of dummy packets to reduce
>>>>>>>>>>>>>>>>>>>>>>>> the overhead of handling dummy packets.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Reporting dummy packet through an error is a bit
>>>>>>>>>>>>>>>>>>>>>>>> misleading since no error happened. An application
>>>>>>>>>>>>>>>>>>>>>>>> cannot e.g. have a global IPsec error counter without
>>>>>>>>>>>>>>>>>>>>>>>> first filtering out dummy packets.
>>>>>>>>>>>>>>>>>>>>>>>>> JannePeltonen wrote
>>>>>>>>>>>>>>>>>>>>>>>>> A dummy packet in transport mode could be delivered
>>>>>>>>>>>>>>>>>>>>>>>>> to an application in the normal way. The result
>>>>>>>>>>>>>>>>>>>>>>>>> packet would be an IP packet with protocol 59. But it
>>>>>>>>>>>>>>>>>>>>>>>>> is true that in tunnel mode there is no way to
>>>>>>>>>>>>>>>>>>>>>>>>> deliver the packet to the application in the current
>>>>>>>>>>>>>>>>>>>>>>>>> API. In my interpretation of the current API a tunnel
>>>>>>>>>>>>>>>>>>>>>>>>> mode dummy packet would result in a proto error
>>>>>>>>>>>>>>>>>>>>>>>>> (since the decapsulated packet is neither IPv4 nor
>>>>>>>>>>>>>>>>>>>>>>>>> IPv6).
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> So some warning/error/flag bit is indeed needed if
>>>>>>>>>>>>>>>>>>>>>>>>> one does not want to confuse dummy packets with
>>>>>>>>>>>>>>>>>>>>>>>>> protocol errors.
>>>>>>>>>>>>>>>>>>>>>>>>>> JannePeltonen wrote
>>>>>>>>>>>>>>>>>>>>>>>>>> This is in conflict with this existing statement a
>>>>>>>>>>>>>>>>>>>>>>>>>> little earlier:
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> "Additionally, input IP packet length
>>>>>>>>>>>>>>>>>>>>>>>>>> (odp_packet_len() minus odp_packet_l3_offset()) must
>>>>>>>>>>>>>>>>>>>>>>>>>> match values in protocol headers. Otherwise esults
>>>>>>>>>>>>>>>>>>>>>>>>>> are undefined."
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> It could be reworded like this:
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> "Additionally, input L3 packet length
>>>>>>>>>>>>>>>>>>>>>>>>>> (odp_packet_len() minus odp_packet_l3_offset()) must
>>>>>>>>>>>>>>>>>>>>>>>>>> not be smaller than the IP packet lenght indicated
>>>>>>>>>>>>>>>>>>>>>>>>>> by the IP header. Otherwise results are undefined.
>>>>>>>>>>>>>>>>>>>>>>>>>> If the input L3 packet length is bigger than the IP
>>>>>>>>>>>>>>>>>>>>>>>>>> packet length, the additional packet data is used as
>>>>>>>>>>>>>>>>>>>>>>>>>> TFC padding."
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> And I think that would be sufficient about TFC here.
>>>>>>>>>>>>>>>>>>>>>>>>>>> JannePeltonen wrote
>>>>>>>>>>>>>>>>>>>>>>>>>>> I suggest rewording like this (after dropping
>>>>>>>>>>>>>>>>>>>>>>>>>>> tfc_padding_truncate capa):
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> An inbound ESP packet may contain TFC padding.
>>>>>>>>>>>>>>>>>>>>>>>>>>> odp_ipsec_in() might or might not remove the
>>>>>>>>>>>>>>>>>>>>>>>>>>> padding. When TFC padding is not removed, the
>>>>>>>>>>>>>>>>>>>>>>>>>>> resulting ODP packet will extend beyond the end of
>>>>>>>>>>>>>>>>>>>>>>>>>>> the IP packet it contains or the resulting IP
>>>>>>>>>>>>>>>>>>>>>>>>>>> packet will extend beyond the end of the IP payload
>>>>>>>>>>>>>>>>>>>>>>>>>>> protocol. An ODP application can detect and remove
>>>>>>>>>>>>>>>>>>>>>>>>>>> such padding by inspecting the length fields of the
>>>>>>>>>>>>>>>>>>>>>>>>>>> relevant protocol headers in the result packet.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Dmitry Eremin-Solenikov(lumag) wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> I prefer to have this bit as an error to keep very
>>>>>>>>>>>>>>>>>>>>>>>>>>>> simple constraint. No error => app may forward
>>>>>>>>>>>>>>>>>>>>>>>>>>>> packet (if it is not interested in details). Error
>>>>>>>>>>>>>>>>>>>>>>>>>>>> => packet must be threated separately and must not
>>>>>>>>>>>>>>>>>>>>>>>>>>>> be forwarded.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Dmitry Eremin-Solenikov(lumag) wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> True.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Dmitry Eremin-Solenikov(lumag) wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Fine, I'll drop this and add a phrase that an
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> implementation might have removed the padding.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Dmitry Eremin-Solenikov(lumag) wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> They can not come as "normal" packets. An
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> application will have no way to determine that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the package was dummy after receiving it. NH
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> field will be gone in case of tunnel packets.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I suggest that when implementation does not
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> drop "no next header" packets, those come
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> through as any other successfully transformed
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> packets: no error/warning bits set. However,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> when HW has dropped a no NH packet it
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> generates a dummy packet (length zero, etc)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> with a warning or operation flag bit on
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> telling that this is not a normal packet, but
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> an indication that a no NH packet was dropped.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Errors/warnings indicate a failure and may
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> require some specific action (SA negotiation).
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> This instead could be could be just a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> odp_ipsec_op_flag_t bit, as the operation was
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> successful and does not need specific action
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (other than drop packet after finding out that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> it does not contain any data). So, application
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> could ignore the bit and drop packet as part
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of normal processing of too short packets.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Also this capa is not strictly needed. A
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> portable application will need to handle also
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the case where inline input does not drop NH
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> packets.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I still vote for minimal TFC specific API
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> changes at this point. This capa is not
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> strictly needed. A portable application
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> would need to implement the length checks
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> anyway.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Dmitry Eremin-Solenikov(lumag) wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I have to think about it.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Dmitry Eremin-Solenikov(lumag) wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> This will allow fast-path forwarding for
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> some applications. If this flag is set, an
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> application can skip header checks/lookups
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and forward ready packet.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Dmitry Eremin-Solenikov(lumag) wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I will update wording to match RFC. Noted
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that ODP does not touch TFC padding in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> transport mode.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> JannePeltonen wrote
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> So you are saying that my interpretation
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> was not the intended one. I think it is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> important to make it clear whether we
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> mean that there might of might not be
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> padding in the received packet in the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> first place or whether the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> implementation might or might not strip
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> said padding when present.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I was thinking it would be good to not
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> make any promises on whether the padding
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is removed or not, i.e. specify that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> there may or may not be padding left in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the result packet that the application
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> gets. This would work with any
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> implementation, even those that do not
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> always do the same thing for every
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> packet (e.g. depending on the input
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> port).
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Not promising anything about the padding
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> would be similar to how the API
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> currently leaves it up to the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> implementation whether there is any L2
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> or other bytes in front of the IP header
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> in the ODP packet data.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Anyway, I will not attempt better
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wording before it is clear what the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> intended semantics are.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Dmitry Eremin-Solenikov(lumag) wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> @psavol @JannePeltonen for async the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> major issue is the packet metadata/user
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> pointer here. I think we might need to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> give some thought to this area anyway
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> because of fragmentation handling. We
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> might need additional
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> copy_udata/free_udata function pointers
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to sa config.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> JannePeltonen wrote
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Yes, but is it needed? With this, an
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> application could check if the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> capability was set instead of checking
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> if packet length is bigger than the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> header indicates for deciding whether
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to trim padding. I just wonder if that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is beneficial enough to justify yet
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> another capability flag.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Dmitry Eremin-Solenikov(lumag) wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Well. RX side has no way to know in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> advance if there will TFC padding or
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not in the packet. That is why I used
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "might" here. Could you please
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> suggest better wording?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Dmitry Eremin-Solenikov(lumag) wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> @JannePeltonen
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Basically it is there to describe
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> hardware behaviour. NXP SEC
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> truncates packets according to L4
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> length, our hardware does not.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Dmitry Eremin-Solenikov(lumag)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Updating to specifically mention
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "inline" mode. We can add drop/etc.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> settings to sync/async modes later.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> JannePeltonen wrote
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ... my point being, the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> description should be improved to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> make it more accurate and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> unambiguous.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> JannePeltonen wrote
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The term "TFC padding" in this
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> API proposal seems to differ from
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that in the RFC. It appears that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> here TFC padding refers only to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> padding after IP payload in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> tunnel mode.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> TFC padding, as defined in the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> RFC, is not restricted to tunnel
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> mode. Transport mode which
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> carries e.g. UDP or IP or other
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> suitable protocol can have TFC
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> padding but that can not be
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> recognized by ODP in the general
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> case (e.g. with proprietary IP
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> protocols).
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> JannePeltonen wrote
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I interpret the "might be
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> present" so that if there was
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> TFC padding in a received
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> packet, it might or might not be
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> present after ODP IPsec
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> processing. Is that the intended
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> interpretation and does it need
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to be made clearer?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> JannePeltonen wrote
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Is the tfc_padding_truncate
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> capability even needed? It is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> an optimization for
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> applications that would benefit
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> from knowing in advance that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the padding is always
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> truncated, but is there a good
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> use case for that?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> JannePeltonen wrote
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The documentation of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> odp_ipsec_in() says:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "Outputted packets with error
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> status have not been
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> transformed but the original
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> packet is returned."
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Maybe it is too much promised
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> for TFC packets (and the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> application should not need
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the original packet in that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> case anyway). It would anyway
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> be good to clarify in the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> comments how exactly
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> odp_ipsec_in() behaves with
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> TFC packets.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> JannePeltonen wrote
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I understood that we wanted
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the automatic dropping only
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> in inline processing mode and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not in other modes.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Petri Savolainen(psavol)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> We should minimize the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> number of configuration
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> options at this time. I
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> think it's not important for
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> application to control dummy
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> packet dropping. So, it can
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> be implementation defined in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> inline. For sync/async we
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> must defined how many
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> packets can be expected back
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> from each IPSEC operation.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The simplest would be that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> each input packet produces
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> an output packet, and it's
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> implementation specific what
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the output packet contains
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (NONH packet or just a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> warning flag telling that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the packet was dropped since
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> it was NONH). Application
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> would not need to control
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> dropping but notice if that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> happened. Async interface
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> would be problematic for
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> application if it's possible
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that nothing comes back from
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> an operation (all packets
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> silently dropped).
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Dmitry
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Eremin-Solenikov(lumag)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hmm. What about
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> `tfc_dummy_packet_drop_sync/async/inline_configurable`
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> capabilities and three
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> flags
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> `tfc_dummy_packet_drop_sync/async/inline`?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> NikhilA-Linaro wrote
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> This configuration option
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is a bit confusing. We
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> need to specifically
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> mention inline and look
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> aside cases. It may not be
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> configurable in many
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> hardwares.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Bill
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Fischofer(Bill-Fischofer-Linaro)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Some implementations may
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> be able to configure this
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> behavior in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> `odp_ipsec_config()`, in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> which case
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> `odp_support_t` would be
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> useful. We can make that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> change later, but it just
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> looks more consistent
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> here. Not a big deal,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> however.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Dmitry
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Eremin-Solenikov(lumag)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ok, updated.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Dmitry
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Eremin-Solenikov(lumag)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Because it's not a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> declaration of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> supporting a feature
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> but rather a statement
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> how implementation
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> handles this case. It
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is not possible to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> switch it. So I
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> preferred to have
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> odp_bool_t here.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Bill
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Fischofer(Bill-Fischofer-Linaro)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> `tfc_dummy_packets_drop`
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> would be clearer.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Bill
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Fischofer(Bill-Fischofer-Linaro)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Since you're
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> referencing
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> `tfc_padding_truncate`,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the TFC prefix would
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> seem consistent here.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> So
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> `tfc_dummy_packets_drop`
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and comments should
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> similarly reference
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> TFC.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Bill
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Fischofer(Bill-Fischofer-Linaro)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Why not
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> `odp_support_t` same
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> as other
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> capabilities here?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Bill
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Fischofer(Bill-Fischofer-Linaro)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> OK, then I would
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> make it clear that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> these are supplied
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> by the application.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> For example:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ```
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The application may
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> choose to insert
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> additional padding
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bytes after the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> packet payload
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (bytes in the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> packet beyond IP
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> length). These will
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> be included in the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> encrypted output
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> packet, to be
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> skipped by the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> receiver.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ```
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I wouldn't make
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> representations
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> about automatic
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> skipping since
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> there's no
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> assurance that the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> receiver is an ODP
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> application so we
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> can't say what some
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> other recipient
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> will do.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Dmitry
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Eremin-Solenikov(lumag)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Nothing controls
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> number of padding
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bytes. It is up to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> an application to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> decide.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Dmitry
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Eremin-Solenikov(lumag)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Because there
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> might be no
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> packet associated
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> with such event.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Just information
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that there was
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> TFC packet
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Bill
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Fischofer(Bill-Fischofer-Linaro)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> What controls
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the number of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> such padding
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bytes? This
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> should be
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> documented.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Bill
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Fischofer(Bill-Fischofer-Linaro)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If this were an
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> `odp_ipsec_packet_result_t`
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bit rather
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> than a status
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> event all input
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> packets
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (synchronous,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> asynchronous,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and inline)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> cases could be
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> handled the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> same without
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the TBD. Why
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> use status
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> events for
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> these packets?
https://github.com/Linaro/odp/pull/329#discussion_r162049330
updated_at 2018-01-17 13:28:18
