On Fri, May 5, 2017 at 8:47 AM, Peltonen, Janne (Nokia - FI/Espoo) < [email protected]> wrote:
> Now I realize that there is a problem in the current API in the > outbound inline case when soft byte or packet limit is reached. > > Either such packet is considered successfully processed and sent > out directly, in which case there is no indication to the application > that the soft limit was reached. Or alternatively the packet is > not considered successfully handled and is sent back to the > application, in which case inline processing changes to slower > async processing. > > So I guess something needs to change in the API also for the > byte and packet based lifetimes. > Yes, crossing a soft limit doesn't prevent packets from being processed successfully, so in the outbound case the packet goes out as normal. It's just that the implementation needs to issue the alert status event as a result of this limit being reached. > > Janne > > > > -----Original Message----- > > From: Peltonen, Janne (Nokia - FI/Espoo) > > Sent: Friday, May 05, 2017 11:37 AM > > To: Bill Fischofer <[email protected]>; Dmitry Eremin-Solenikov > > <[email protected]> > > Cc: lng-odp-forward <[email protected]> > > Subject: RE: [lng-odp] IPsec limits support > > > > > > 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 > > > >
