kernel-interface: Change reqid if seq. nos. are supported and narrowing occurred
With the sequence numbers we don't have to maintain the reqid to delete the temporary state. One exception is with labels. There we currently only install trap policies with the generic label. SAs created from those don't have policies installed, so we have to reuse the reqid of the trap even if narrowing occurs. And as before, we reuse the reqid without checking traffic selectors if sequence numbers are not supported. Note that if a CHILD_SA is manually initiated (i.e. has no sequence number assigned) right before an acquire is triggered, there are several possible outcomes depending on whether narrowing occurs. If there is no narrowing, the same reqid is assigned and the kernel will remove the temporary SA when the SA is installed (no seq => reqid match). Afterwards, the queued duplicate CHILD_SA is destroyed and the acquire state in the trap manager gets removed. If there is narrowing, a new reqid is allocated, so the installation of the SA will not remove the temporary state. However, due to the narrowing, the duplicate check fails and when the duplicate is installed (with sequence number), the temporary state is deleted (as is the state in the trap manager).
This commit is contained in:
@@ -81,6 +81,8 @@ enum kernel_feature_t {
|
||||
KERNEL_POLICY_SPI = (1<<4),
|
||||
/** IPsec backend reports use time per SA via query_sa() */
|
||||
KERNEL_SA_USE_TIME = (1<<5),
|
||||
/** IPsec backend associates acquires and SAs with a sequence number */
|
||||
KERNEL_ACQUIRE_SEQ = (1<<6),
|
||||
};
|
||||
|
||||
/**
|
||||
|
||||
Reference in New Issue
Block a user