Re: simplifying rekeying [draft-jenkins-ipsec-rekeying-06.txt]

[Bill Sommerfeld <[e-mail]>]

Having just spent some time beating my head against a related issue
(quick mode state management) in interoperability testing, it's clear
that the whole phase-2 "message-id" (really "transaction id") and the
implicit initialization vector chaining approach is just extremely
fragile from a protocol point of view, leading to all sorts of
finger-pointing when debugging.

one commonly sees the following if a quick mode exchange which runs
"slow" (particularly when you have logging, etc., cranked up all the
way), leading one party to retransmit:

	- both packets are received; the first one is handled
properly, advancing the IV and similar state in the phase 2
transaction.
	- the second packet is decrypted using the new (wrong) IV
state, resulting in a decrypted packet in which the first block of the
plaintext is garbled.
	- the garbled packet is fed to the isakmp parser, where any of
a number of things could happen before the parser decides the packet
is too broken to live.  almost certainly, it's not going to be able to find
the HASH payload at all so it can't even verify the integrity of
the rest of the message..
	- the receiver typically then sends a (spurious) NOTIFY
message informing the sender that a message, broken in one of many
possible ways, has been received.

An alternative case occurs when the initiator doesn't like the
responder's reply, and just drops the phase 2 exchange state. the
retransmitted message from the responder is then treated as a "new" QM
transaction, which, as above, is garbled on decryption.

No, this isn't a "security flaw" in the protocol.  It's simply
non-robust protocol design..  it's exactly when retransmissions are
occuring that you *don't* want to burden the network with additional
spurious traffic.

					- Bill