Change:
In this context, "newer" was confusing as the code permits the creation of the next set of packet protection keys when switching over. As the goal of the text was to ensure that old keys not be used, using that formulation avoids any confusion that might be caused from not having a reference against which to decide which is "newer".
Section 6.4: An endpoint always sends packets that are protected with the newest keys. Keys used for packet protection can be discarded immediately after switching to newer keys. I do get confused by the first sentence reference to "newest" key. So the previous section talks about the requirement that one retain the current and next key. If one have created the next key, then that key is newest. I don't think this is intention, but the text can be interpret that one need to switch to the next key as soon as one is allowed if one have created it. The only question is when it is created. If I would guess the above section 6.4 sentence is to ensure that one never uses the previous key, if a key change has occurred. However, one should not be forced to switch to the next key unless the other side has switched or the key has exhausted its protection life time. However, I think the current formulation can result in that an outside attacker that can inject a packet with a toggled key-phase bit can force an endpoint to switch its key, even if the peer hasn't initiated a key update. This simply by forcing it to generate it, and then have the packet integrity check to fail for the injected packet. Because now there is a newer "next key" in store.
Never using old keys is a nice way of putting this. I'll make that change.
On the last point (which I glossed over initially, as it relates to a different concept), the attacker can at best force the installation of the next set of read keys and only if the receiver is willing to do so. Flipping the key phase bit has the effect of causing a receiver to select the previous or next read keys. If the receiver generates keys on demand (which is not a great idea, but some implementations do...), then it will generate those keys. That key generation should be a one-off event (we recommend saving keys in ). A bit flip cannot result in any change to any other state (other than the global anti-forgery counter, which is a recent addition). Updates only occur as a result of successfully removing packet protection and a bit flip will cause the integrity check to fail and the packet to be dropped with no other state changes. The point about "newer" is well taken though. I didn't really think that updates to read keys could affect write keys (that's not how my code works), but as this is a lock-step protocol, that seems obvious in retrospect.
NAME do these explanations plus 52c5f4f41bb1a1128af8f52398224cd2c9f83e45 address your issue? Or are further text changes required?
Mostly, I think one could use the previous sections discussion of "current" and "next" to clarify this. For example: OLD: An endpoint never sends packets that are protected with old keys. New: An endpoint never sends packets that are protected with old keys (previous key) only the current key.
I did that in , but somehow it slipped the net and I failed to create the pull request. Sorry about that. I'll make the recommended change (or something like it).
NAME request was quite clear, so you should merge this and close the issue.I think these say the same thing, but the new text is shorter, which I always like.

Discussion:
6.4. <del> An endpoint always sends packets that are protected with the newest keys.  Keys used for packet protection can be discarded immediately after switching to newer keys. </del> <ins> An endpoint never sends packets that are protected with old keys. Only the current keys are used.  Keys used for protecting packets can be discarded immediately after switching to newer keys. </ins> Packets with higher packet numbers MUST be protected with either the same or newer packet protection keys than packets with lower packet