[strongSwan] Clarification about INVALID_MAJOR_VERSION

kumuda kumuda at linux.vnet.ibm.com
Tue Sep 9 18:47:25 CEST 2014


Hi,

IN IKEV2 tahi tests, testing end-node as responder for Receipt of a 
higher major version number

As per RFC 5996:
If an endpoint receives a message with a higher major version number,
    it MUST drop the message and SHOULD send an unauthenticated Notify
    message of type INVALID_MAJOR_VERSION containing the highest
    (closest) version number it supports.

IKE_SA_INIT request with major version 3 is sent, charon log shows that 
the header verification failed

/etc/strongswan/ipsec.conf has "keyexchange=ikev2"

-bash-4.2# strongswan start
Starting strongSwan 5.2.0 IPsec [starter]...

   loaded plugins: charon curl aes des rc2 sha1 sha2 md4 md5 random 
nonce x509 revocation constraints acert pubkey pkcs1 pkcs8 pkcs12 pgp 
dnskey sshkey pem openssl fips-prf gmp xcbc cmac hmac attr 
kernel-netlink resolve socket-default farp stroke vici updown 
eap-identity eap-md5 eap-gtc eap-mschapv2 eap-tls eap-ttls eap-peap 
xauth-generic xauth-eap xauth-pam dhcp


_from charon.log_
Sep  8 11:40:01 01[NET] received packet: from 2001:db8:f:1::1[500] to 
2001:db8:1:1::1[500]
Sep  8 11:40:01 01[ENC] parsing header of message
Sep  8 11:40:01 01[ENC] parsing HEADER payload, 337 bytes left
...
Sep  8 11:40:01 01[ENC]   parsing rule 0 IKE_SPI
Sep  8 11:40:01 01[ENC]    => 8 bytes @ 0x3fff580010a8
Sep  8 11:40:01 01[ENC]    0: CC 38 37 F0 27 9B 88 
D4                          .87.'...
Sep  8 11:40:01 01[ENC]   parsing rule 1 IKE_SPI
Sep  8 11:40:01 01[ENC]    => 8 bytes @ 0x3fff580010b0
Sep  8 11:40:01 01[ENC]    0: 00 00 00 00 00 00 00 
00                          ........
Sep  8 11:40:01 01[ENC]   parsing rule 2 U_INT_8
Sep  8 11:40:01 01[ENC]    => 33
Sep  8 11:40:01 01[ENC]   parsing rule 3 U_INT_4
Sep  8 11:40:01 01[ENC]    => 3
Sep  8 11:40:01 01[ENC]   parsing rule 4 U_INT_4
Sep  8 11:40:01 01[ENC]    => 0
Sep  8 11:40:01 01[ENC]   parsing rule 5 U_INT_8
Sep  8 11:40:01 01[ENC]    => 34
Sep  8 11:40:01 01[ENC]   parsing rule 6 RESERVED_BIT
Sep  8 11:40:01 01[ENC]    => 0
Sep  8 11:40:01 01[ENC]   parsing rule 7 RESERVED_BIT
Sep  8 11:40:01 01[ENC]    => 0
Sep  8 11:40:01 01[ENC]   parsing rule 8 FLAG
Sep  8 11:40:01 01[ENC]    => 0
Sep  8 11:40:01 01[ENC]   parsing rule 9 FLAG
Sep  8 11:40:01 01[ENC]    => 0
Sep  8 11:40:01 01[ENC]   parsing rule 10 FLAG
Sep  8 11:40:01 01[ENC]    => 1
Sep  8 11:40:01 01[ENC]   parsing rule 11 FLAG
Sep  8 11:40:01 01[ENC]    => 0
Sep  8 11:40:01 01[ENC]   parsing rule 12 FLAG
Sep  8 11:40:01 01[ENC]    => 0
Sep  8 11:40:01 01[ENC]   parsing rule 13 FLAG
Sep  8 11:40:01 01[ENC]    => 0
Sep  8 11:40:01 01[ENC]   parsing rule 14 U_INT_32
Sep  8 11:40:01 01[ENC]    => 0
Sep  8 11:40:01 01[ENC]   parsing rule 15 HEADER_LENGTH
Sep  8 11:40:01 01[ENC]    => 337
Sep  8 11:40:01 01[ENC] parsing HEADER payload finished
Sep  8 11:40:01 01[ENC] header verification failed
Sep  8 11:40:01 01[NET] received invalid IKE header from 2001:db8:f:1::1 
- ignored
Sep  8 11:40:01 01[NET] waiting for data on sockets

Does it mean it received a corrupt IKE_SA_INIT from the initiator?
Is there any configuration to be enabled to receive the 
INVALID-MAJOR-VERSION package?


Regards,
Kumuda G
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20140909/40bfd422/attachment.html>


More information about the Users mailing list