Bill Fischofer(Bill-Fischofer-Linaro) replied on github web page:
include/odp/api/spec/ipsec.h
@@ -1293,6 +1297,10 @@ int odp_ipsec_in(const odp_packet_t pkt_in[], int num_in,
* with IPSEC, etc headers constructed according to the standards. The amount
* and content of packet data before the IP header is undefined.
*
+ * Additional TFC padding might be present after packet payload for ESP-tunnel
+ * mode. It will be included into encrypted packet. Receiver side will skip
+ * this padding automatically.
+ *
Comment:
@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_r161906484
updated_at 2018-01-16 22:41:16
