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.stef...@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]== > > > _______________________________________________ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users