Subject: [IPsec] draft-ietf-ipsecme-ipsecha-protocol-02.txt

From: Tero Kivinen <[email-masked]>
Date: Wed, 10 Nov 2010 13:18:34 +0200

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.
-- 
[email-masked]

---

From: Raj Singh <[email-masked]>
Date: Thu, 18 Nov 2010 22:21:11 +0530

Hi Tero,

Thanks for the comments.
Opened Ticket #204 for format error in notification payload.

Regarding the second issue. Some clarification is needed:
The text meant that the message containing IKEV2_MESSAGE_ID_SYNC
notification is allowed with message id zero only.
This doesn't mean that message id is NOT allowed for other messages.

Also, Yaron has suggested another method IKEv2 Message Id sync in another
thread, after discussion further decision will be taken on this.

Thanks,
Raj

On Wed, Nov 10, 2010 at 4:48 PM, Tero Kivinen <[email-masked]> wrote:

> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>