[Swan-dev] interop-ikev2-racoon-02-psk-responder test

[Andrew Cagney]

On 31 August 2015 at 17:00, D. Hugh Redelmeier <hugh at mimosa.com> wrote:

> | On 30 August 2015 at 14:40, Paul Wouters <paul at nohats.ca> wrote:
>
> | > This message has appeared a long time ago when Andrew redid our CBC-only
> | > crypto to CBC/CTR/GCM.
>
> I think that this failure is unstable and that the test is marked as if it
> should pass.  Here are some results from recent runs:
>
> Jul 20 00:33 tests.LOG16.results        west:bad,east:ok
> Jul 20 14:56 tests.LOG17.results        west:bad,east:ok
> Jul 22 01:17 tests.LOG18.results        good
> Jul 24 00:50 tests.LOG19.results        west:ok,east:bad
> Jul 25 03:04 tests.LOG20.results        dunno
> Jul 26 10:29 tests.LOG21.results        west:bad,east:ok
> Jul 27 12:57 tests.LOG23.results        good
> Jul 28 09:47 tests.LOG24.results        good
> Aug 24 09:00 tests.LOG26.results        west:bad,east:ok
> Aug 29 11:12 tests.LOG27.results        good
> Aug 30 00:38 tests.LOG28.results        west:bad,east:ok
> Aug 31 10:59 tests.LOG29.results        west:bad,east:ok
>
> It isn't always the same side that fails.
>
> This isn't a good situation.

Would you know what the pad byte was for each of these cases?  Or at
least the case that passed?  In pluto look for the line:

| payload after decryption:

and then the last byte of the dump:

|   29 00 00 0c  02 00 00 00  65 61 73 74  27 00 00 08
[....]
|   67 31 34 58  e3 cf 5e 9e  f9 5f 10 e4  b8 41 0f 23
"westnet-eastnet-ikev2" #2: invalid padding-length octet: 0x23

I suspect that racooon, when the real payload is block aligned,
completely forgets to do any padding at all.  Perhaps, if we receive a
packet that validates, but has too-big padding, we simply soldier on.
I don't like it, however it is probably what happened before the check
was added.

If nothing else, since the test is unstable, it should be disabled.