Dmitry Eremin-Solenikov wrote:
> Another generic question regarding ODP. If the package gets passed to
> IPsec API, should I trust e.g. IP header values? IOW, can I assume, that
> ip->tot_len + l3_offset is equal to odp_packet_len(), or is that an error?
Good question.
I think there are several somewhat different cases that may merit
a bit different handling. In any case some clarification is needed
in the API spec.
I-1) Inbound: IP length < packet length - L3 offset
Received packets may contain some L2 data at the end (e.g. to pad
Ethernet frames to the minimum frame length).
I think it would make most sense to require ODP implementations to
discard the extra packet data (i.e. truncate the packet) before any
IPsec processing and then perform IPsec decapsulation normally.
I do not think it would be very useful to require the application to
truncate the packet to the correct length since the ODP implementation
must anyway be able to handle the extra packet data in the inbound
inlined offload case.
I-2) Inbound: IP length > packet length - L3 offset
I think ODP should return an error (which one?) through the operation
status. Specifying undefined behavior may not be very useful since the
ODP implementation must anyway be able to gracefully handle this case
for inline processed packets.
O-1) Outbound: IP length < packet length - L3 offset
One possibility would be to discard the extra packet data at the end
before IPsec processing, just like in the inbound case. But here we
could also consider treating the extra packet data as TFC padding that
gets encrypted along with the actual payload (but that might be more
complex, especially with fragmentation offload).
O-2) Outbound: IP length > packet length - L3 offset
I think ODP should return an error in the op status as in the inbound
case, but I suppose undefined behavior could be considered too.
Janne
