I have a connection between openbsd 4.0 (yes, a bit out of date) and a
checkpoint vpn-1 r55. Once or twice a month the tunnel stops working,
and when it happened today I had the isakmpd.pcap running. I have have
to manually restart the tunnel using 'echo t' or 'echo c' into the
fifo to get it up again.
OpenBSD should always be the IKE initiator in my setup, but when the
problem starts, the *checkpoint* tries to initiate the phase 1
communication and fails. It goes well during security association and
key exchange, but it fails on the third step, identification:
no tstamp dir info
1 7645.66 C->O Identity Protection (Main Mode security association)
2 7645.66 O->C Identity Protection (Main Mode security association)
3 7645.71 C->O Identity Protection (Main Mode key exchange)
4 7645.71 O->C Identity Protection (Main Mode key exchange)
5 7645.75 C->O Identity Protection (Main Mode identification)
6 7645.75 O->C Informational (payload malformed)
7 7647.76 C->O Identity Protection (Main Mode identification) dup
8 7647.76 O->C Informational (payload malformed)
9 7649.76 C->O Identity Protection (Main Mode identification) dup
10 7649.76 O->C Informational (payload malformed)
[...]
Packet no 5 contains a payload with type 137, but that shouldn't be
allowed in ISAKMP version 1, should it (rfc 2408 section 3.8)? Also,
the reserved field is set to 0xDB, which is not allowed. Is this a
problem, or should it fail gracefully and fall back to standard
operation?
The "payload malformed" messages sent back by OpenBSD do not re-use
the established i/r cookies; in stead it generates a new icookie and
blanks the rcookie. Point 5 in the table in section 2.4 in RFC 2408
shows that the i/r cookies should be in place, but it doesn't clearly
say how to handle informational messages.
The packet exchange with checkpoint sending identification messages
and openbsd responding with payload malformed, goes on for a long time
and the checkpoint ignores openbsd's repeated attempts at renewing
phase 2 connections (which already have a working phase 1 connection).
So this boils down to two questions:
1. Is the checkpoint IKE implementation simply wrong, since it uses
out of spec ID numbers, strange payloads and non-zero reserved
fields? I'm aware that this is rather common for vendors. Is it
generally a problem?
2. Should informational messages use the same i/r cookies as the query
that spawned the info messages, or is this irrelevant according to
the spec? I would think it is relevant.
Here are the exact same packets as above, but with full decoding. The
fun start at packet 5. Output from wireshark.
1 7645.66 C->O Identity Protection (Main Mode security association)
Internet Security Association and Key Management Protocol
Initiator cookie: A6D3530A7ECAC4D8
Responder cookie: 0000000000000000
Next payload: Security Association (1)
Version: 1.0
Exchange type: Identity Protection (Main Mode) (2)
Flags: 0x00
.... ...0 = Not encrypted
.... ..0. = No commit
.... .0.. = No authentication
Message ID: 0x00000000
Length: 128
Security Association payload
Next payload: Vendor ID (13)
Payload length: 56
Domain of interpretation: IPSEC (1)
Situation: IDENTITY (1)
Proposal payload # 1
Next payload: NONE (0)
Payload length: 44
Proposal number: 1
Protocol ID: ISAKMP (1)
SPI Size: 0
Proposal transforms: 1
Transform payload # 1
Next payload: NONE (0)
Payload length: 36
Transform number: 1
Transform ID: KEY_IKE (1)
Encryption-Algorithm (1): 3DES-CBC (5)
Hash-Algorithm (2): SHA (2)
Authentication-Method (3): PSK (1)
Group-Description (4): Alternate 1024-bit MODP group (2)
Life-Type (11): Seconds (1)
Life-Duration (12): Duration-Value (28800)
Vendor ID payload
Next payload: NONE (0)
Payload length: 44
Vendor ID: Check Point
Check Point Product: VPN-1
Version: NG with Application Intelligence R55
Check Point Vendor ID parameters
2 7645.66 O->C Identity Protection (Main Mode security association)
Internet Security Association and Key Management Protocol
Initiator cookie: A6D3530A7ECAC4D8
Responder cookie: 2D512A81B0729297
Next payload: Security Association (1)
Version: 1.0
Exchange type: Identity Protection (Main Mode) (2)
Flags: 0x00
.... ...0 = Not encrypted
.... ..0. = No commit
.... .0.. = No authentication
Message ID: 0x00000000
Length: 184
Security Association payload
Next payload: Vendor ID (13)
Payload length: 56
Domain of interpretation: IPSEC (1)
Situation: IDENTITY (1)
Proposal payload # 1
Next payload: NONE (0)
Payload length: 44
Proposal number: 1
Protocol ID: ISAKMP (1)
SPI Size: 0
Proposal transforms: 1
Transform payload # 1
Next payload: NONE (0)
Payload length: 36
Transform number: 1
Transform ID: KEY_IKE (1)
Encryption-Algorithm (1): 3DES-CBC (5)
Hash-Algorithm (2): SHA (2)
Authentication-Method (3): PSK (1)
Group-Description (4): Alternate 1024-bit MODP group (2)
Life-Type (11): Seconds (1)
Life-Duration (12): Duration-Value (28800)
Vendor ID payload
Next payload: Vendor ID (13)
Payload length: 20
Vendor ID: unknown vendor ID: 0x6C0DCD481DEAE8AE0B0A68384B3072F9
Vendor ID payload
Next payload: Vendor ID (13)
Payload length: 20
Vendor ID: draft-ietf-ipsec-nat-t-ike-02
Vendor ID payload
Next payload: Vendor ID (13)
Payload length: 20
Vendor ID: draft-ietf-ipsec-nat-t-ike-03
Vendor ID payload
Next payload: Vendor ID (13)
Payload length: 20
Vendor ID: RFC 3947 Negotiation of NAT-Traversal in the IKE
Vendor ID payload
Next payload: NONE (0)
Payload length: 20
Vendor ID: RFC 3706 Detecting Dead IKE Peers (DPD)
3 7645.71 C->O Identity Protection (Main Mode key exchange)
Internet Security Association and Key Management Protocol
Initiator cookie: A6D3530A7ECAC4D8
Responder cookie: 2D512A81B0729297
Next payload: Key Exchange (4)
Version: 1.0
Exchange type: Identity Protection (Main Mode) (2)
Flags: 0x00
.... ...0 = Not encrypted
.... ..0. = No commit
.... .0.. = No authentication
Message ID: 0x00000000
Length: 184
Key Exchange payload
Next payload: Nonce (10)
Payload length: 132
Key Exchange Data (128 bytes / 1024 bits)
Nonce payload
Next payload: NONE (0)
Payload length: 24
Nonce Data
4 7645.71 O->C Identity Protection (Main Mode key exchange)
Internet Security Association and Key Management Protocol
Initiator cookie: A6D3530A7ECAC4D8
Responder cookie: 2D512A81B0729297
Next payload: Key Exchange (4)
Version: 1.0
Exchange type: Identity Protection (Main Mode) (2)
Flags: 0x00
.... ...0 = Not encrypted
.... ..0. = No commit
.... .0.. = No authentication
Message ID: 0x00000000
Length: 184
Key Exchange payload
Next payload: Nonce (10)
Payload length: 132
Key Exchange Data (128 bytes / 1024 bits)
Nonce payload
Next payload: NONE (0)
Payload length: 24
Nonce Data
5 7645.75 C->O Identity Protection (Main Mode identification)
Internet Security Association and Key Management Protocol
Initiator cookie: A6D3530A7ECAC4D8
Responder cookie: 2D512A81B0729297
Next payload: Identification (5)
Version: 1.0
Exchange type: Identity Protection (Main Mode) (2)
Flags: 0x00
.... ...0 = Not encrypted
.... ..0. = No commit
.... .0.. = No authentication
Message ID: 0x00000000
Length: 68
Identification payload
Next payload: Private USE (137)
Payload length: 487
[Malformed Packet: ISAKMP]
6 7645.75 O->C Informational (payload malformed)
Internet Security Association and Key Management Protocol
Initiator cookie: 2FE2A207BE5F2920
Responder cookie: 0000000000000000
Next payload: Notification (11)
Version: 1.0
Exchange type: Informational (5)
Flags: 0x00
.... ...0 = Not encrypted
.... ..0. = No commit
.... .0.. = No authentication
Message ID: 0x00000000
Length: 40
Notification payload
Next payload: NONE (0)
Payload length: 12
Domain of interpretation: IPSEC (1)
Protocol ID: ISAKMP (1)
SPI Size: 0
Message type: PAYLOAD-MALFORMED (16)
7 7647.76 C->O Identity Protection (Main Mode identification) dup
Internet Security Association and Key Management Protocol
Initiator cookie: A6D3530A7ECAC4D8
Responder cookie: 2D512A81B0729297
Next payload: Identification (5)
Version: 1.0
Exchange type: Identity Protection (Main Mode) (2)
Flags: 0x00
.... ...0 = Not encrypted
.... ..0. = No commit
.... .0.. = No authentication
Message ID: 0x00000000
Length: 68
Identification payload
Next payload: Private USE (137)
Payload length: 487
[Malformed Packet: ISAKMP]
8 7647.76 O->C Informational (payload malformed)
Internet Security Association and Key Management Protocol
Initiator cookie: F887EA1A33DB9DE1
Responder cookie: 0000000000000000
Next payload: Notification (11)
Version: 1.0
Exchange type: Informational (5)
Flags: 0x00
.... ...0 = Not encrypted
.... ..0. = No commit
.... .0.. = No authentication
Message ID: 0x00000000
Length: 40
Notification payload
Next payload: NONE (0)
Payload length: 12
Domain of interpretation: IPSEC (1)
Protocol ID: ISAKMP (1)
SPI Size: 0
Message type: PAYLOAD-MALFORMED (16)
9 7649.76 C->O Identity Protection (Main Mode identification) dup
Internet Security Association and Key Management Protocol
Initiator cookie: A6D3530A7ECAC4D8
Responder cookie: 2D512A81B0729297
Next payload: Identification (5)
Version: 1.0
Exchange type: Identity Protection (Main Mode) (2)
Flags: 0x00
.... ...0 = Not encrypted
.... ..0. = No commit
.... .0.. = No authentication
Message ID: 0x00000000
Length: 68
Identification payload
Next payload: Private USE (137)
Payload length: 487
[Malformed Packet: ISAKMP]
10 7649.76 O->C Informational (payload malformed)
Internet Security Association and Key Management Protocol
Initiator cookie: 67B0BDD2B9D5463D
Responder cookie: 0000000000000000
Next payload: Notification (11)
Version: 1.0
Exchange type: Informational (5)
Flags: 0x00
.... ...0 = Not encrypted
.... ..0. = No commit
.... .0.. = No authentication
Message ID: 0x00000000
Length: 40
Notification payload
Next payload: NONE (0)
Payload length: 12
Domain of interpretation: IPSEC (1)
Protocol ID: ISAKMP (1)
SPI Size: 0
Message type: PAYLOAD-MALFORMED (16)
