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

[Kazuho Oku <[e-mail]>]

> 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?
> https://github.com/quicwg/base-drafts/issues/1439#issuecomment-397246970 by @gloinul 

I'd assume that the second ACK will contain CE vector of 0010.

Quoting what @mikkelfj says, the specification can require one of the three behaviors. My understanding is that _b_ is the behavior we want in order to mitigate the impact of injection attacks racing against the original packet.

> Assume receiver does not detect or reject duplicate packets, but it does track an ACK backlog and there has some natural ACK dectection capability.
> If packet 4 in the above example first sets CE, this will be visible in the backlog. A second packet 4 without CE can then see that 4 is already pending ACK and can choose to a) overwrite the CE bit, b) do nothing since a packet is present, or c) use inclusive OR on the CE bit.
> https://github.com/quicwg/base-drafts/issues/1439#issuecomment-397256856 @mikkelfj 

> From my perspective receiver suppressing duplicated packets are a work saver for the receiver.
> https://github.com/quicwg/base-drafts/issues/1439#issuecomment-397246970 @gloinul 

A receiver can suppress duplicates to some extent, but it can never be perfect. 

I do not think it is a good idea to require receivers to implement complicated countermeasures against packet injection attacks for two reasons: 1) it's not enforceable 2) having complex requirement will take people away from implementing ECN support.

Sending back the signal that tells which PN arrived with CE bit set simplifies the architecture at the same time giving us a guaranteed level of protection. See https://github.com/quicwg/base-drafts/issues/1439#issuecomment-397258455 by @mikkelfj.

> It doesn't need to do more than PN decryption for the packet.
> https://github.com/quicwg/base-drafts/issues/1439#issuecomment-397246970 by @gloinul 

The receiver is required to decrypt the payload even if it has seen the PN before, unless it knows that the payload is identical in some other ways (e.g. by comparing the hash of the payload). Please refer to [QUIC-TLS draft section 10.3](https://quicwg.org/base-drafts/draft-ietf-quic-tls.html#rfc.section.10.3).

> 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.
> https://github.com/quicwg/base-drafts/issues/1439#issuecomment-397246970 by @gloinul 

It does not. Frames are guaranteed to be idempotent. See #1424.

They need to be idempotent because there is no reliable way for a receiver to tell if a packet it has received is a duplicate.

-- 
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-397281950