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

[D. Hugh Redelmeier]

| From: Andrew Cagney <andrew.cagney at gmail.com>

| On 30 August 2015 at 14:40, Paul Wouters <paul at nohats.ca> wrote:
| > On Sun, 30 Aug 2015, D. Hugh Redelmeier wrote:

| >> It fails with this message in the console log:
| >> +002 "westnet-eastnet-ikev2" #2: invalid padding-length octet: 0x23
| >>
| >> I think that this is an oblique way of saying that the encrypted payload
| >> is smells bad and will be rejected.  If so, it isn't really user-friendly.

| I concluded that racoon, for aes-cbc, was forgetting to add a
| pad-length.

Seems likely.  Are you convinced enough to change the test to consider
this a pass?

On the surface, the collection of messages isn't enough for the user
to understand what has gone on.  Pluto needs to explain that this
event causes the message to be ignored / discarded.  The implication
being that negotiation might fail due to this.  Maybe I read the log
too carelessly and all is clear.

| 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.

| >  I think this might be a
| > bug in racoon2. No one is really using or developing racoon2 AFAIK. In
| > fact, racoon1 (aka ipsec-tools) sees more development still, but has no
| > IKEv2 support.

Is there nobody to receive a bug report?