Re: [quicwg/base-drafts] Handling of duplicate packets (#1405)

[Magnus Westerlund <[e-mail]>]

@mikkelfj I am uncertain if that happens in a way that will prevent this attack. My assumption when this attack would be possible would be a low rate management connection where any rekeying based on number of legit sent packets may occur very infrequently. I don't find what the rekeying frequency requirements are, does someone have pointer? 

The number of tested forges will be dependent on the number of forged duplicate packets the attacker manage to send without raising an alarm that the connection is under attack. But, if there are no such warnings then an attacker could potentially send a large number of attack packets without the target noticing other than it drops a lot of packets due to authentication failure. The attack only consumes PN and thus packets until rekeying when a successful forge has been accomplished. 

To my understanding the protection against this type of attack, is to prevent that a successful forge results in a response. If there are no general duplication protection then using a recently sent packet as attack packet is makes it simpler to cause a response. In fact the response to ECN-CE marks can actually be one thing that provides such a proof if some of the response discussed in #1372 would be allowed. Modifying the payload forging the authentication tag and setting the ECN bits to CE could then trigger an ACK on successful forge. For a connection that mostly idle that ACK will be a good signal for a forge. However, for this type of connection one can likely also target packets with a PING frame. Thus, also getting an ACK response on successful forge.
 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1405#issuecomment-398022746