[Swan-dev] interop-ikev2-racoon-02-psk-responder test
andrew.cagney at gmail.com
Tue Sep 1 05:09:04 EEST 2015
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
If nothing else, since the test is unstable, it should be disabled.
More information about the Swan-dev