Closed gloinul closed 2 months ago
Max paths allowed to be open gives the size for what amount of traffic an attacker can cause towards an attack target by having the server send path_validate + path_challenge.
@gloinul do you mean if I have N open paths, an attacker can cause me to send N path validation packets instead of one to a victim as described in 21.5.4.?
Having path resource control opens up for similar errors as have been found in QUIC.
@gloinul not sure what you mean by this?
Max paths allowed to be open gives the size for what amount of traffic an attacker can cause towards an attack target by having the server send path_validate + path_challenge.
@gloinul do you mean if I have N open paths, an attacker can cause me to send N path validation packets instead of one to a victim as described in 21.5.4.?
Yes
Having path resource control opens up for similar errors as have been found in QUIC.
@gloinul not sure what you mean by this?
So we touched on this in the interim. In regards to if the peer can remove agency for ones implementation to control its resources, like opening up paths in a legal way. So that is design issue. But, we have to ensure that one are clear that there are parts that an implementation have to put in its limits otherwise the peer might spiral resources out of control. I think what I might have referenced was the retry attack (I think) that was discussed back in March.
I think there are two classes of issue, amount of state and amount of traffic. For state, we have a good handle: max path is the min of values announced by both peers, number of CID is max_path times max_cid_per_path, an endpoint can only start a path if the peer has provided a CID for that path.
For the amount of traffic, I am not sure. I believe this falls out from controlling state.
In any case, we probably need to write that down.
The draft lacks content in the security consideration section. It is definitely time to start dealing with this.
Issues for MP-QUIC include: