I haven't had time to read the draft-ietf-ipsecme-ipsecha-protocol-02
completely yet, but while looking at the slides in the WG meeting, I
noticed one serious problem.
The IKEV2_MESSAGE_ID_SYNC and IPSEC_REPLAY_COUNTER_SYNC messages do
not follow Notification payload syntax.
For the IKEV2_MESSAGE_ID_SYNC there is only the missing critical bit:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload | RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
instead of:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For the IPSEC_REPLAY_COUNTER_SYNC it is bit more serious as it puts
something else on the same plaCe where the C bit normally is:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |E| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
I.e it adds "ESN bit" on the generic IKEv2 header in the location
where normally there is the critical bit.
There is not really any need for the ESN bit as the length of the
delta value can be seen from the payload length field.
----------------------------------------------------------------------
Also the section 7 says:
The Message ID value used in the Informational exchange that contains
the IKEV2_MESSAGE_ID_SYNC notification MUST be zero so that it is not
validated upon receipt as required by normal IKEv2 windowing. The
Message ID zero MUST be accepted only in an Informational exchange
that contains a notification of type IKEV2_MESSAGE_ID_SYNC. If any
Informational exchange has a Message ID zero, but not this
notification type, such messages MUST be discarded upon decryption
and the INVALID_SYNTAX notification SHOULD be sent. Other payloads
MUST NOT be sent in this Informational exchange. Whenever an
IKEV2_MESSAGE_ID_SYNC or IPSEC_REPLAY_COUNTER_SYNC notification
payload is received with an invalid failover count or invalid nonce
data, the event SHOULD be logged.
Message ID zero is completely valid and legal value for message ID and
this text suddenly makes it impossible to use it anymore. The first
message responder ever always has Message ID zero, which means that if
you follow this then first message sent by responder will be rejected.
Message ID is also zero after IKE SA rekey. Also INVALID_SYNTAX
notification do have some special meaning in RFC5996:
Only authentication failures (AUTHENTICATION_FAILED and EAP failure)
and malformed messages (INVALID_SYNTAX) lead to a deletion of the IKE
SA without requiring an explicit INFORMATIONAL exchange carrying a
Delete payload.
....
If a peer parsing a request notices that it is badly formatted (after
it has passed the message authentication code checks and window
checks) and it returns an INVALID_SYNTAX notification, then this
error notification is considered fatal in both peers, meaning that
the IKE SA is deleted without needing an explicit Delete payload.
--
kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
