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

[Andrew Cagney]

I concluded that racoon, for aes-cbc, was forgetting to add a
pad-length.  Commit f2de5ef7 added the check :-; Commit d6e46094 just
clarified things a little adding tweaking the message and adding the
[sic:reguired] comment:

+ * Append optional "padding" and reguired "padding-length" byte.
+ *
+ * Some encryption modes, namely CBC, require things to be padded to
+ * the encryption block-size.  While others, such as CTR, do not.
+ * Either way a "padding-length" byte is always appended.
+ *
+ * This code starts by appending a 0 pad-octet, and each subsequent
+ * octet is one larger.  Thus the last octet always contains one less
+ * than the number of octets added i.e., the padding-length.
+ *
+ * Adding to the confusion, ESP requires a minimum of 4-byte alignment
+ * and IKE is free to use the ESP code for padding - we don't.

for instance, racoon sends us:

| payload after decryption:
|   29 00 00 0c  02 00 00 00  65 61 73 74  27 00 00 08
|   00 00 40 00  21 00 00 1c  02 00 00 00  2e 49 8a c0
|   19 e8 72 21  f4 f7 93 7b  62 af b8 39  38 ad 54 d2
|   2c 00 00 2c  00 00 00 28  01 03 04 03  03 6e 86 5c
|   03 00 00 0c  01 00 00 0c  80 0e 00 80  03 00 00 08
|   03 00 00 02  00 00 00 08  05 00 00 00  2d 00 00 18
|   01 00 00 00  07 00 00 10  00 00 ff ff  c0 00 01 00
|   c0 00 01 ff  00 00 00 18  01 00 00 00  07 00 00 10
|   00 00 ff ff  c0 00 02 00  c0 00 02 ff  3f 25 1b 2b
|   ea bf b2 fc  a0 51 07 dc  b6 d6 ef 5d  82 29 ee 7f
|   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

The last byte of the payload is the required pad length.  With a 16
byte block, the largest valid pad length value is 15; 23 is larger
than that.

On 30 August 2015 at 14:40, Paul Wouters <paul at nohats.ca> wrote:
> On Sun, 30 Aug 2015, D. Hugh Redelmeier wrote:
>
>> Subject: [Swan-dev] interop-ikev2-racoon-02-psk-responder test
>>
>> I just ran the test suite to test some changes before committing them.
>> The only regression (i.e. the only test that passed yesterday but failed
>> today) is interop-ikev2-racoon-02-psk-responder.
>>
>> 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.
>
>
> This message has appeared a long time ago when Andrew redid our CBC-only
> crypto to CBC/CTR/GCM. We could never figure out why racoon did this. As
> other interop tests with stronswan worked fine. 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.