Change:
Here's an alternative suggestion - WDYT, NAME NAME Instead of write: It's a bit long, though.
I don't want to speak for NAME :-), but I think he's arguing for a wider scope than just "When a record with a CID is received"
FMPOV that describes the increment introducing CID in the scope of MAC validation and alert generation.
Let me try to point to the difference of the current text and my proposal above: If the address hasn't changed since the last "validation", should a peer chose the option of to ? If the address has changed, then a peer may choose that option but must not send badrecordmac alert? In my opinion, this option to "alert" should not be chosen for CID. Therefore, I would point to that option in RFC 6347 and recommend not to use it with CID.
Imagine the following: server S has an active session with client A using CID=1 S crashes and restarts a new session using CID=1 is successfully established between S and client B A sends a record with CID=1 MAC verification fails for the record If at this point S decides not* to follow the recommendation in and instead replIes to B (since A's address has not been validated) with a fatal MAC failure alert, a perfectly valid session would be killed.
Why should Server S send any record to B, when receiving and record from A with a different address?
It can't send it to A because per A is not a validated peer (crypto fails on the received record). If S decided to send anything back, it could only send to B, which is the validated peer for CID=1.
Wouldn't it be a general rule, not to sent any response to different addresses?
Please see , last paragraph. PR strengthens the SHOULD to a MUST.
I still think, that generally no answer should be send to a different address. That will no be only true for alerts, it is generally true. Reading The termination of the connection state is independent from introducing CID. (Therefore "a perfectly valid session would be killed." is the specified consequence of sending alert rather than something new and unknown introduced by CID.) If a specification got somehow more complex, and so introduce misunderstandings, I would prefer to have general rules instead of introducing context sensitive rules.
What are you suggesting exactly?
For me this look like, there is no additional risk. Using the option to choose to generate an alert is specified including the consequences. Assuming spoofing for "None-CID" traffic, introducing CID doesn't add new risks. So, nothing need to be added. Maybe, if wanted, an additional hint, that with CID it may be easier to sent records with invalid MAC and so choosing to generate an alert should be well reconsidered though it would be mostly the wrong approach.
But there is a risk that is worth pointing out and fixing. Even if it's only incremental value.
As long as it is clear, that the general risk was always there and CID makes it more probable to terminate the connection state accidentally.
I added a . In my opinion, this describes the higher risk and the resulting MUST NOT for alerts at the right place without limiting the processing in other scopes.
Looks good to me

Discussion:
different than the one currently associated with the DTLS connection, the receiver MUST NOT replace the address it uses for sending records to its peer with the source address specified in the received <del> datagram unless the following conditions are met: </del> <ins> datagram unless the following three conditions are met: </ins> The received datagram has been cryptographically verified using the DTLS record layer processing procedures.

to receive and process DTLS records.  No such test is defined in this specification. <del> The above is necessary to protect against attacks that use datagrams with spoofed addresses or replayed datagrams to trigger attacks. Note that there is no requirement to use of the anti-replay window mechanism defined in Section 4.1.2.6 of DTLS 1.2.  Both solutions, the "anti-replay window" or "newer algorithm" will prevent address updates from replay attacks while the latter will only apply to peer address updates and the former applies to any application layer traffic. </del> <ins> The conditions above are necessary to protect against attacks that use datagrams with spoofed addresses or replayed datagrams to trigger attacks.  Note that there is no requirement to use of the anti-replay window mechanism defined in Section 4.1.2.6 of DTLS 1.2.  Both solutions, the "anti-replay window" or "newer algorithm" will prevent address updates from replay attacks while the latter will only apply to peer address updates and the former applies to any application layer traffic. </ins> Application protocols that implement protection against these attacks depend on being aware of changes in peer addresses so that they can

DTLS-specific mechanism may be used, as described in I-D.tschofenig- tls-dtls-rrc. <ins> DTLS implementations MUST silently discard records with bad MACs or that are otherwise invalid. </ins> 7. dtls-example2 shows an example exchange where a CID is used uni-