If the IKEv2 initiator acting as a TNC server receives invalid TNC measurements
from the IKEv2 responder acting as a TNC clienti, the exchange of PB-TNC batches
is continued until the IKEv2 responder acting as a TNC server has also finished
its TNC measurements.
In the past if these measurements in the other direction were correct
the IKEv2 responder acting as EAP server declared the IKEv2 EAP authentication
successful and the IPsec connection was established even though the TNC
measurement verification on the EAP peer side failed.
The fix adds an "allow" group membership on each endpoint if the corresponding
TNC measurements of the peer are successful. By requiring a "allow" group
membership in the IKEv2 connection definition the IPsec connection succeeds
only if the TNC measurements on both sides are valid.
ifdown calls bind's rndc, which tries to access TCP port 953 on lo.
If these packets are dropped by the firewall we have to wait for the TCP
connections to time out, which takes quite a while.
With -W we reduce timeouts when we don't expect a response. With -i the
interval between pings is reduced (mostly in case of auto=route where
the first ping yields no reply).
The default of 56 bytes already exceeds the threshold of 90 bytes (8 bytes
ICMP + 40 bytes IPv6 = 104 bytes). By reducing the size we make sure the
packet is not compressed (40 + 8 + 40 = 88).
This also fixes a strange failure of this scenario due to the recently
added post-test `ip xfrm state` check. The kernel stores a reference to
the used SAs on the inbound skbuffs and since these are garbage collected
it could take a while until all references to an SA disappear and the SA
is finally destroyed. But while SAs might not get destroyed immediately
when we delete them, they are actually marked as dead and therefore won't
show up in `ip xfrm state`. However, that's not the case for the tunnel
SAs the kernel attaches to IPComp SAs, which we don't explicitly delete,
and which aren't modified by the kernel until the IPComp SA is destroyed.
So what happened when the last ping unintentionally got compressed is that
the skbuff had a reference to the IPComp SA and therefore the tunnel SA.
This skbuff often was destroyed after the `ip xfrm state` check ran and
because the tunnel SA would still get reported the test case failed.
