Bill Fischofer wrote:
> On Thu, May 4, 2017 at 11:44 AM, Dmitry Eremin-Solenikov <
> [email protected]> wrote:
>
> > On 04.05.2017 19:35, Bill Fischofer wrote:
> > >
> > >
> > > On Thu, May 4, 2017 at 11:25 AM, Dmitry Eremin-Solenikov
> > > <[email protected]
> > > <mailto:[email protected]>> wrote:
> > >
> > > Hello,
> > >
> > > I have been working on limits support in IPsec. Now I have several
> > > questions:
> > >
> > > - Is hard limit crossing fatal? IOW, should I start returning
> > > unprocessed packets after crossing it?
> > >
> > >
> > > The reason for having soft and hard limits is this distinction. When a
> > > soft limit is reached a notification event should be issued. When a hard
> > > limit is reached the SA is treated as disabled. So an operation against
> > > an SA that's reached it's hard limit should be treated the same as an
> > > operation against a disabled SA.
> >
> > Argh. There is no 'event' for soft limits, just a status in the error
> > flags. BTW: should we move soft_exp_* to flags instead of errors?
> >
>
> This is one of the "to do" areas we'll hopefully cover next week. Reaching
> a soft limit should result in an odp_ipsec_status_t event being issued to
> alert the application that the soft limit was reached.
There is a difference between time based limits and the byte/packet based
limits. For the latter the API should already be ok since byte and packet
based limits are tracked on per-packet basis as part of processing the
packets.
Expiration of the byte and packet life times are indicated in the status
bits of the packet result. When a soft byte or packet limit is exceeded,
the corresponding status bit should be set in the result but otherwise the
IPsec operation should complete normally. If a hard limits is exceeded,
then the IPsec operation must fail and the original unprocessed packet
must be returned to the application through the operation result struct.
Handling of time based lifetimes on the other hand is indeed a to-do
item, since their expiration is not tied to any packets. The current
API can signal time based life time expiration only when a packet for
the SA is getting processed but not if there is no traffic for the SA.
This means that the application needs to track at least the soft life
time itself to be able to rekey in time even if there is no traffic
just then through the SA.
One alternative would be to signal time based life time expiration
through the status event. Another would be to just drop them from
the API completely and let the application handle them (which would
still allow introducing them back in the API later, if desired).
>
>
> >
> > And also there is no way to treat hard-expired SA as disabled. We should
> > report hard_exp_* through result errors.
> >
>
> That's fine. The point is the operation fails. It's an error to continue to
> process packets against an SA that's reached a hard limit.
>
Passing a disabled SA explicitly to IPsec processing function is disallowed
by the API and can therefore cause undefined behavior as we have discussed.
But attempting an IPsec operation for an SA for which a hard life time
has been reached is not disallowed, so an application may do so. The ODP
implementation must then indicate the error through a status bit and
return the unprocessed packet back to the application.
Requiring that an application never attempts IPsec processing for an
SA if it has gotten the hard life time expiry error once would require
synchronization between different threads of the application for that
purpose and I do not think it would make the ODP implementation much
easier.
>
> >
> > > - Does 'bytes' limit count packet bytes before or IPsec operation?
> > Does
> > > it count 'usefull' payload or the whole odp_packet_len()?
It should count the bytes to which the crypto/auth operations are applied,
i.e. the number of bytes they keys have been used, including padding bytes.
Counting the bytes outside of that (e.g. outer tunnel header or L2 header)
is not useful since those bytes do not affect the secrecy of the keys.
But I do not think counting some extra bytes would be a big problem.
Maybe the API should say something about it.
> > >
> > >
> > > It's typically easier to just count packets and not be overly concerned
> > > about trying to cut off packets mid-stream on byte limits. For byte
> > > counting the SA would simply count the number of bytes processed for
> > > each operation and compare that to the limits as the operation finishes
> > > up. Limits are statistical in nature and as such if the odd in-flight
> > > packet or byte slips past it's not something to worry about.
For soft limits I would agree, but I am not sure if that is always ok for
the hard limits. Failing a little too early in case of a hard limit should
be ok, but letting too many bytes or packets through may become a security
issue. At least the API should make it very clear if a hard limit is not
that hard.
Janne
