Draft: draft-ietf-tls-dtls-connection-id

Commentary: Here 's an alternative suggestion - WDYT , Instead of write : It 's a bit long , though . 
 I do n't want to speak for :-) , 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 has n'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   send any record to B , when receiving and record from A with a different address ? 
 It ca n'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 . 
 Would n'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 does n't add new risks . So , nothing need to be . 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 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
Paragraph (version B):
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.
Paragraph (version B):
DTLS implementations MUST silently discard records with bad MACs or
that are otherwise invalid.