Re: [quicwg/base-drafts] Improve ACK_ECN frame encoding (e.g., use bit-vector) (#1439)

[Magnus Westerlund <[e-mail]>]

@kazuho I think I better understand your thinking, but I am still uncertain that I fully understand. So lets see if I understand correctly how the receiver would act in the case of a packet duplications happening. 

So the receiver at the point of sending an ACK has received PN=2,3,4  where 4 has a CE mark. Then the ACK will say: Largest PN=4, length=3, CE vector = 001. 

But then arrives PN=4, 5, 5 before it is time to send the next ACK. So the duplicate of PN=4 has ECN=ECT(0), and first 5 has ECT(0) and second ECN-CE set. Thus the ACK will be:
Largest PN=5, length 4, CE vector 0001? 

In this case the sender doesn't see that PN=5 was duplicated with different CE values. Or do you say that this must be sent as two ACKs, where the first is: 
Largest PN=5, length 4, CE vector 0000 and the next:
Largest PN=5, length 4, CE vector 0001
So any duplication must trigger ACKing? 

The issues I see with this, if I have correctly understood it are:
* Packet duplication results in additional ACKs
* In the first case where the CE marks are in the first arrival and then not in the late coming duplication an ACK loss of the first will mask the CE mark. 
* Also in the case of ACK loss of the first PN=5 ACK will result in that the sender can't know if this CE mark was present in the lost ACK or not, thus resulting in an uncertainty for a sender if an CE mark is more likely an attack packet. As late remarked packets a bigger risk for the attack included in the security consideration.

When it comes to bleaching, we are not only considering ECN-CE to ECT but also ECT to Not-ECT. The later more relevant when it comes to the capability check as networks that don't handle ECN correctly usually sets all the ECN bits to Not-ECT independently of value. Thus we do need to determine also when some packets has not been marked at the receiver. So, I see your proposed format work for the purpose of the sender learn the received value as long as there are no packet duplication. I still don't see this format helping with the issues that arise with packet duplication. Then you would need yet another set of modes saying duplicate with which of the 4 ECN values. 

>From my perspective receiver suppressing duplicated packets are a work saver for the receiver. It doesn't need to do more than PN decryption for the packet. The ECN field of the later packets are of very limited value. And the receiver requirement for implementing this is very low. And if you are not suppressing duplicated packets early, then you will have to consider what you do with each individual frame type. Is it safe to process a duplicate or do you need to suppress it at frame type level. To me it opens up the implementation to much more attacks. 

-- 
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/1439#issuecomment-397246970