Change:
This should make things correct. We might consider getting rid of the term connection or association entirely, but each is problematic: association is a historical term but we also use connection a lot anyway.
It's a shame that "association" is so firmly entrenched. I don't see "association" being used much anyway. Good that you have removed "session" though.

Discussion:
client: The endpoint initiating the DTLS connection. <del> connection: A transport-layer connection between two endpoints. </del> <ins> association: Shared state between two endpoints established with a DTLS handshake. connection: Synonym for association. </ins> endpoint: Either the client or server of the connection. handshake: An initial negotiation between client and server that <del> establishes the parameters of their transactions. </del> <ins> establishes the parameters of the connection. </ins> peer: An endpoint.  When discussing a particular endpoint, "peer" refers to the endpoint that is remote to the primary subject of

sender: An endpoint that is transmitting records. <del> session: An association between a client and a server resulting from a handshake. </del> server: The endpoint which did not initiate the DTLS connection. CID: Connection ID

the following sliding window procedure, borrowed from Section 3.4.3 of RFC4303. <del> The received record counter for a session MUST be initialized to zero when that session is established.  For each received record, the receiver MUST verify that the record contains a sequence number that does not duplicate the sequence number of any other record received during the lifetime of the session.  This check SHOULD happen after deprotecting the record; otherwise the record discard might itself serve as a timing channel for the record number.  Note that computing the full record number from the partial is still a potential timing channel for the record number, though a less powerful one than whether the record was deprotected. </del> <ins> The received record counter for an association MUST be initialized to zero when that association is established.  For each received record, the receiver MUST verify that the record contains a sequence number that does not duplicate the sequence number of any other record received during the lifetime of the association.  This check SHOULD happen after deprotecting the record; otherwise the record discard might itself serve as a timing channel for the record number.  Note that computing the full record number from the partial is still a potential timing channel for the record number, though a less powerful one than whether the record was deprotected. </ins> Duplicates are rejected through the use of a sliding receive window. (How the window is implemented is a local matter, but the following

receiver does not notify the sender of the window size.) The "right" edge of the window represents the highest validated <del> sequence number value received on the session.  Records that contain sequence numbers lower than the "left" edge of the window are </del> <ins> sequence number value received on the association.  Records that contain sequence numbers lower than the "left" edge of the window are </ins> rejected.  Records falling within the window are checked against a list of received records within the window.  An efficient means for performing this check, based on the use of a bit mask, is described