[strongSwan] incorrect notification data for critical invalid payload type
gowrishankar
gowrishankar.m at linux.vnet.ibm.com
Fri Sep 28 21:42:51 CEST 2012
Hi Andreas,
I could not follow up on your reply by that time.
On Sunday 01 July 2012 06:43 PM, Andreas Steffen wrote:
> What do you mean by corrupted? To my unexperienced eyes the log shows
> that indeed a one-octet notification payload is sent containing the
> received and rejected value 0x2D which is not defined according to IANA.
Oops, I should have not mentioned "corrupted". For what I observe in
charon.log
Sep 28 07:08:16 16[ENC] parsing NOTIFY payload, 190 bytes left
Sep 28 07:08:16 16[ENC] parsing payload from => 190 bytes @ 0x7f03d4000e68
< CUT >
Sep 28 07:08:16 16[ENC] parsing rule 0 U_INT_8
Sep 28 07:08:16 16[ENC] => 1
Sep 28 07:08:16 16[ENC] parsing rule 1 FLAG
Sep 28 07:08:16 16[ENC] => 0
Sep 28 07:08:16 16[ENC] parsing rule 2 RESERVED_BIT
Sep 28 07:08:16 16[ENC] => 0
Sep 28 07:08:16 16[ENC] parsing rule 3 RESERVED_BIT
Sep 28 07:08:16 16[ENC] => 0
Sep 28 07:08:16 16[ENC] parsing rule 4 RESERVED_BIT
Sep 28 07:08:16 16[ENC] => 0
Sep 28 07:08:16 16[ENC] parsing rule 5 RESERVED_BIT
Sep 28 07:08:16 16[ENC] => 0
Sep 28 07:08:16 16[ENC] parsing rule 6 RESERVED_BIT
Sep 28 07:08:16 16[ENC] => 0
Sep 28 07:08:16 16[ENC] parsing rule 7 RESERVED_BIT
Sep 28 07:08:16 16[ENC] => 0
Sep 28 07:08:16 16[ENC] parsing rule 8 RESERVED_BIT
Sep 28 07:08:16 16[ENC] => 0
Sep 28 07:08:16 16[ENC] parsing rule 9 PAYLOAD_LENGTH
Sep 28 07:08:16 16[ENC] => 12
Sep 28 07:08:16 16[ENC] parsing rule 10 U_INT_8
Sep 28 07:08:16 16[ENC] => 3
Sep 28 07:08:16 16[ENC] parsing rule 11 SPI_SIZE
Sep 28 07:08:16 16[ENC] => 4
Sep 28 07:08:16 16[ENC] parsing rule 12 U_INT_16
Sep 28 07:08:16 16[ENC] => 16393
Sep 28 07:08:16 16[ENC] parsing rule 13 SPI
Sep 28 07:08:16 16[ENC] => => 4 bytes @ 0x7f03d4001060
Sep 28 07:08:16 16[ENC] 0: B0 0C DE
3C ...<
Sep 28 07:08:16 16[ENC] parsing rule 14 NOTIFICATION_DATA
Sep 28 07:08:16 16[ENC] => => 0 bytes @ (nil)
To note here, I am not setting any notification data in NOTIFY payload.
Sep 28 07:08:16 16[ENC] parsing NOTIFY payload finished
Sep 28 07:08:16 16[ENC] parsing (1) payload, 178 bytes left
Sep 28 07:08:16 16[ENC] parsing payload from => 178 bytes @ 0x7f03d4000e74
< CUT >
Sep 28 07:08:16 16[ENC] parsing rule 0 U_INT_8
Sep 28 07:08:16 16[ENC] => 41
Sep 28 07:08:16 16[ENC] parsing rule 1 FLAG
Sep 28 07:08:16 16[ENC] => 1
critical flag is set here.
Sep 28 07:08:16 16[ENC] parsing rule 2 RESERVED_BIT
Sep 28 07:08:16 16[ENC] => 0
Sep 28 07:08:16 16[ENC] parsing rule 3 RESERVED_BIT
Sep 28 07:08:16 16[ENC] => 0
Sep 28 07:08:16 16[ENC] parsing rule 4 RESERVED_BIT
Sep 28 07:08:16 16[ENC] => 0
Sep 28 07:08:16 16[ENC] parsing rule 5 RESERVED_BIT
Sep 28 07:08:16 16[ENC] => 0
Sep 28 07:08:16 16[ENC] parsing rule 6 RESERVED_BIT
Sep 28 07:08:16 16[ENC] => 0
Sep 28 07:08:16 16[ENC] parsing rule 7 RESERVED_BIT
Sep 28 07:08:16 16[ENC] => 0
Sep 28 07:08:16 16[ENC] parsing rule 8 RESERVED_BIT
Sep 28 07:08:16 16[ENC] => 0
Sep 28 07:08:16 16[ENC] parsing rule 9 PAYLOAD_LENGTH
Sep 28 07:08:16 16[ENC] => 4
Sep 28 07:08:16 16[ENC] parsing rule 10 UNKNOWN_DATA
Sep 28 07:08:16 16[ENC] => => 0 bytes @ (nil)
Sep 28 07:08:16 16[ENC] parsing (1) payload finished
Parsing of NOTIFY and INVALID payload done now. Below is the portion
of logs while charon generates NOTIFY payload for critical
invalid payload.
Sep 28 07:08:16 16[ENC] generating payload of type NOTIFY
Sep 28 07:08:16 16[ENC] generating rule 0 U_INT_8
Sep 28 07:08:16 16[ENC] => 0
Sep 28 07:08:16 16[ENC] generating rule 1 FLAG
Sep 28 07:08:16 16[ENC] => 0
Sep 28 07:08:16 16[ENC] generating rule 2 RESERVED_BIT
Sep 28 07:08:16 16[ENC] => 0
Sep 28 07:08:16 16[ENC] generating rule 3 RESERVED_BIT
Sep 28 07:08:16 16[ENC] => 0
Sep 28 07:08:16 16[ENC] generating rule 4 RESERVED_BIT
Sep 28 07:08:16 16[ENC] => 0
Sep 28 07:08:16 16[ENC] generating rule 5 RESERVED_BIT
Sep 28 07:08:16 16[ENC] => 0
Sep 28 07:08:16 16[ENC] generating rule 6 RESERVED_BIT
Sep 28 07:08:16 16[ENC] => 0
Sep 28 07:08:16 16[ENC] generating rule 7 RESERVED_BIT
Sep 28 07:08:16 16[ENC] => 0
Sep 28 07:08:16 16[ENC] generating rule 8 RESERVED_BIT
Sep 28 07:08:16 16[ENC] => 0
Sep 28 07:08:16 16[ENC] generating rule 9 PAYLOAD_LENGTH
Sep 28 07:08:16 16[ENC] => => 2 bytes @ 0x7f03e740485e
Sep 28 07:08:16 16[ENC] 0: 00
09 ..
Sep 28 07:08:16 16[ENC] generating rule 10 U_INT_8
Sep 28 07:08:16 16[ENC] => 0
Sep 28 07:08:16 16[ENC] generating rule 11 SPI_SIZE
Sep 28 07:08:16 16[ENC] => 0
Sep 28 07:08:16 16[ENC] generating rule 12 U_INT_16
Sep 28 07:08:16 16[ENC] => => 2 bytes @ 0x7f03e740485e
Sep 28 07:08:16 16[ENC] 0: 00
01 ..
Sep 28 07:08:16 16[ENC] generating rule 13 SPI
Sep 28 07:08:16 16[ENC] => => 0 bytes @ (nil)
Sep 28 07:08:16 16[ENC] generating rule 14 NOTIFICATION_DATA
Sep 28 07:08:16 16[ENC] => => 1 bytes @ 0x7f03d4000b50
Sep 28 07:08:16 16[ENC] 0:
2D -
Sep 28 07:08:16 16[ENC] generating NOTIFY payload finished
Here, this payload is of 9 bytes as payload length also mentions
correctly. But, my doubt is on notification data which is 2D.
It is always 2D even if I set notification data on sending node (say 01).
Sep 28 06:43:57 16[ENC] parsing rule 14 NOTIFICATION_DATA
Sep 28 06:43:57 16[ENC] => => 1 bytes @ 0x7fdec80010b0
Sep 28 06:43:57 16[ENC] 0: 01
and
Sep 28 06:43:57 16[ENC] generating rule 12 U_INT_16
Sep 28 06:43:57 16[ENC] => => 2 bytes @ 0x7fded914285e
Sep 28 06:43:57 16[ENC] 0: 00
01 ..
Sep 28 06:43:57 16[ENC] generating rule 13 SPI
Sep 28 06:43:57 16[ENC] => => 0 bytes @ (nil)
Sep 28 06:43:57 16[ENC] generating rule 14 NOTIFICATION_DATA
Sep 28 06:43:57 16[ENC] => => 1 bytes @ 0x7fdec8000db0
Sep 28 06:43:57 16[ENC] 0:
2D -
Sep 28 06:43:57 16[ENC] generating NOTIFY payload finished
I could not get what you said earlier for this value "received and
rejected". As I am new in this area, can you please help me to
understand it more.
Thanks,
Gowri Shankar
>
> Andreas
>
> On 07/01/2012 01:39 PM, gowrishankar wrote:
>> Hi,
>>
>> I am testing IKEv2 implementation for invalid but critical payload type.
>> strongswan seems to be sending notification payload of message type
>> "UNSUPPORTED_CRITICAL_PAYLOAD" as expected. But, notification data is
>> corrupted where as it should be a "one-octet payload type" as per
>> Section 2.5 of RFC 5996 (or 4306).
>>
>> From charon.log:
>>
>> Jun 30 22:45:07 16[ENC] payload type (100) is not supported, but its
>> critical!
>> Jun 30 22:45:07 16[IKE] critical unknown payloads found
>> Jun 30 22:45:07 16[ENC] added payload of type NOTIFY to message
>> Jun 30 22:45:07 16[ENC] added payload of type NOTIFY to message
>> Jun 30 22:45:07 16[ENC] generating CREATE_CHILD_SA response 2 [ N(CRIT) ]
>> Jun 30 22:45:07 16[ENC] insert payload NOTIFY to encryption payload
>> ...
>> ..
>> Jun 30 22:45:07 16[ENC] generating payload of type NOTIFY
>> ...
>> ..
>> Jun 30 22:45:07 16[ENC] generating rule 14 NOTIFICATION_DATA
>> Jun 30 22:45:07 16[ENC] => => 1 bytes @ 0xad7005a8
>> Jun 30 22:45:07 16[ENC] 0:
>> 2D -
>> Jun 30 22:45:07 16[ENC] generating NOTIFY payload finished
>>
>> Also, I found this problem might have been fixed in 5.0.0 version (thou-
>> gh I have not yet tested), by a rework applied to handle variable
>> length of payload data.
>>
>> http://wiki.strongswan.org/projects/strongswan/repository/revisions/95a26523afc0d2a997cd1d4f738c287ae045ae4e
>>
>>
>> Can someone confirm if this was already reported (if so, strongswan
>> bug id?) or I can open a defect to down-stream the patch in 4.6.x ?
>>
>> Thanks,
>> Gowri Shankar
> ======================================================================
> Andreas Steffen andreas.steffen at strongswan.org
> strongSwan - the Linux VPN Solution! www.strongswan.org
> Institute for Internet Technologies and Applications
> University of Applied Sciences Rapperswil
> CH-8640 Rapperswil (Switzerland)
> ===========================================================[ITA-HSR]==
>
>
>
More information about the Users
mailing list