[Swan-dev] Merging algorithm tests?

Andrew Cagney andrew.cagney at gmail.com
Wed Mar 22 13:42:00 UTC 2017


On 21 March 2017 at 11:16, Paul Wouters <paul at nohats.ca> wrote:
> On Wed, 15 Mar 2017, Andrew Cagney wrote:
>
>> For the DH19/DH20/DH21, since the test objective was to just
>> demonstrate a basic crypto suite interop, i grouped everything
>> reducing the number of tests (the convention seems to be one test per
>> crypto suite).  For instance, ikev2-algo-ike-dh-ecp-01's westrun.sh
>> looks like:
>>
>> ../bin/libreswan-up-down.sh ikev2-ike=aes128-sha1-dh19 -I 192.0.1.254
>> 192.0.2.254
>> ../bin/libreswan-up-down.sh ikev2-ike=aes128-sha1-dh20 -I 192.0.1.254
>> 192.0.2.254
>> ../bin/libreswan-up-down.sh ikev2-ike=aes128-sha1-dh21 -I 192.0.1.254
>> 192.0.2.254
>>
>> this seems to work remarkably well(1)(2).  I'm now wondering if this
>> is a better more general approach for crypto suite interop tests like
>> this.
>
>
> The reason is hasnt been done is because the responder side never got
> the function to change its configuration after running eastinit.sh,
> so it has to have all connections loaded and finding the right host
> connection then becomes mingled in the process.  If we would support
> a 1eastrun.sh 2westrun.sh 3eastrun.sh we could do it.

Yes; although for strongswan it supports everything anyway.

We support multiple run scripts, they are run in C locale sort order
(cf nss-cert-ocsp-01-strict).

> But then again, if we just fix the slowness of the tests, I would really
> prefer to keep it all seperate to ensure we always test with a clean
> state.

There's a tradeoff.  Constantly cleaning the slate means we don't
notice the small amount of grime we leave behind (we might have
noticed the PK11SymKey leak earlier) and no matter what the framework,
being able to add tests that take each take ~1s is always going to be
a win.

Here the only goal is to prove that when the two ends agree to
aes-sha1-DH21, say, they perform the same operations.

>> (1) my implementation is simple (I suspect there's a way to do this
>> directly with whack; but that means learning whack :-)
>
>
> just using ipsec auto with delete/add and up/down?

I'm using auto add/delete up/down with a config file hardwired with
algorithms.  It is probably possible to avoid this and specify the
algorithms on the whack line but that means consulting the book of
magic.

>> (2) anyone know a way to do this with strongswan as the initiator?
>
>
> strongswan AFAIK does not have add/delete, only up/down, so you would
> also have to load all connections and then up/down different ones.
> Their "vicci" (sp?) interface might allow it but I have no idea how
> that works.

Yea.

While testing pluto->pluto and pluto->strongswan leaves out
strongswan->pluto, it should be sufficient.

Andrew


More information about the Swan-dev mailing list