On 27 March 2017 at 13:27, Savolainen, Petri (Nokia - FI/Espoo) <[email protected]> wrote: > >> > /** >> > + * Configuration options for IPSEC inbound processing >> > + */ >> > +typedef struct odp_ipsec_inbound_config_t { >> > + /** Default destination queue for IPSEC events >> > + * >> > + * When inbound SA lookup fails in asynchronous or inline >> modes, >> > + * resulting IPSEC events are enqueued into this queue. >> > + */ >> > + odp_queue_t default_queue; >> > + >> > + /** Constraints for SPI values of inbound SAs for which lookup >> is >> > + * enabled. Minimal range size and unique SPI values may >> improve >> > + * performance. */ >> > + struct { >> > + /** Minimum inbound SPI value. Default value is 0. */ >> > + uint32_t min; >> > + >> > + /** Maximum inbound SPI value. Default value is >> UINT32_MAX. */ >> > + uint32_t max; >> > + >> > + /** Inbound SPI values may overlap. Default value is 0. >> */ >> > + odp_bool_t overlap; >> >> It's not clear what you mean by SPI values overlapping since an SPI is >> a unit32_t value. Some explanation / illustration seems warranted >> here. > > Application tells if it uses unique SPI values for all (inbound) SAs it > creates (== no two SAs have the same SPI), which results simpler lookup for > implementation. This should be the default setting, since application can > decide inbound SPI values. Since default values are usually zero, I used term > "overlap" instead of e.g. "non_unique".
What about "spi_collision_support" term? RFC 4301: "In many secure multicast architectures, e.g., [RFC3740], a central Group Controller/Key Server unilaterally assigns the Group Security Association's (GSA's) SPI. This SPI assignment is not negotiated or coordinated with the key management (e.g., IKE) subsystems that reside in the individual end systems that constitute the group. Consequently, it is possible that a GSA and a unicast SA can simultaneously use the same SPI. A multicast-capable IPsec implementation MUST correctly de-multiplex inbound traffic even in the context of SPI collisions." > > >> > >> > /** >> > + * Disable IPSEC SA >> > + * >> > + * Application must use this call to disable a SA before destroying it. >> The call >> > + * marks the SA disabled, so that IPSEC implementation stops using it. >> For >> > + * example, inbound SPI lookups will not match any more. Application >> must >> > + * stop providing the SA as parameter to new IPSEC input/output >> operations >> > + * before calling disable. Packets in progress during the call may >> still match >> > + * the SA and be processed successfully. >> >> Does this mean that it is an application responsibility to ensure that >> there are no "in flight" IPsec operations at the time this call is >> made? That seems unnecessarily burdensome, as one of the purposes of >> an API like this is to flush the request pipeline before issuing a >> destroy call. I'd prefer the following sort of wording: >> >> "Operations initiated or in progress at the time this call is made >> will complete normally, however no further operations on this SA will >> be accepted. For example, inbound SPI lookups will not match any more, >> and outbound operations referencing this SA will fail." > > > Application must not pass the same SA as parameter simultaneously to > disable() and e.g. ipsec_in() or ipsec_enq(). This way implementation does > not (may not) need to synchronize, between slow path (disable) and fast path > (ipsec_in) calls. Appplication should be able to synchronize itself so that > one thread does not disable/destroy a SA that other thread still actively > uses. > > Look ups for in-flight packet are still possible during disable, since that > SA usage is in control of implementation. So, application can still continue > passing packets without SA (for lookup), but it must not explicitly refer use > SA itself on other (fast path calls). > > -Petri
