Bill Fischofer wrote:
>
> The following data items MUST be in the SAD:
But that does not necessarily mean that they need to be in the ODP SA.
> With this background, it's clear that should we choose to remove
> time-based expiration from the ODP IPsec API spec we would have an
> incomplete IPsec specification that would require any ODP
> implementation that wishes to be IPsec compliant to "fill in" the spec
> on its own. That would not be good.
Regardless of how complete the life time support is in ODP, there
are other things that the application needs to do for IPsec RFC
compliancy. For example, ODP does not do any policy enforcement
but leaves it to the application (which is good since it adds
flexibility).
> Note also that the RFC says
> nothing about counting packets, only bytes, so perhaps we shouldn't be
> offering packet counts?
I suppose packet based life times could be added later as a backward
compatible API change if they are not included now. But I think some
other IPsec implementations provide them.
> Given that we want to keep these, the question is then how are they to
> be handled? The argument I would make is that these are control
> signals as they indicate that the control plane should begin rekeying
> on an SA (soft expiration) or that an SA's lifetime has ended (hard
> expiration). As such they should be odp_ipsec_status_t events, which
> seems to be what IPsec users like OFP would prefer.
Even if all life time expirations are signaled as status events,
a normal operation completion event for a packet is needed when
IPsec processing is attempted but fails due to hard life time
(or byte or packet limit) expiration. So those error bits are
still needed in the op_result.
I am not sure OFP has any preference one way or the other.
> But perhaps this is too coarse. Having a dest_cos makes sense for
> PIPELINE_CLS output but the current dest_queue is used for both
> odp_ipsec_result_t and odp_ipsec_status_t events, which inherently
> have different "consumers". So might it make more sense to split this
> into:
>
> /**
> * Output queue for IPSEC results
> *
> * Operations in asynchronous or inline mode enqueue result events are placed
> * onto this queue.
> */
> odp_queue_t result_queue;
>
> /**
> * Output queue for IPSEC status
> *
> * Status events relating to this SA are placed onto this queue.
> */
> odp_queue_t status_queue;
There are some status events (at least the disable SA completion
event) that need to be ordered with operation completion events.
When an application gets the disable completion event, it must
be able to count on that it has seen all operation completion
events for that SA or else it becomes much more difficult to
tear down SAs safely. To get that ordering, disable completion
needs to come through the same queue as the normal IPsec
operation events.
This ordering is not currently explicitly specified in the API
but we have discussed the need to clarify the API with Petri.
I think the ordering becomes even more important if we change
operation result events to packet events with IPsec specific
packet metadata.
Janne
