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 <kivi...@iki.fi> wrote: > 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 >
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
