Validators should not make decisions based on which ports data was received #6672
Comments
|
Why isn’t the rule simply:
Regardless how it arrived? Where the leader is the layer above per node per shred. It shouldn't matter how it arrived. |
|
Yeah that applies to everything except for Repairman. So Turbine doesn't care about where (in terms of slot) your peers are. Repairman is sending really old shreds (from the epoch before) to you and you should definitely not be sending them through turbine. Because your peers might not be as far behind as you are. |
|
@aeyakovenko So we need a solution for repairman. Something that isn't port dependent. Also we send shreds received from neighbors to the children in layers below. So the rules should really be:
|
|
@sagar-solana isn’t repairman request/response? |
|
@aeyakovenko no its not. It's automatic. Infact I just realized it repairs anyone more than 50 slots behind. Not an epoch anymore. So repairman looks at others' gossip and catches them up. No request. Directly response. |
|
@sagar-solana but their request is signed by them. so its a request to be repaired by the network which they can cancel. |
|
They can't take something off of gossip once it's put there? The response is not so much a response as much as it is just a flood of shreds on tvu. Anyway even if we allow nulling the gossipped EpochSlots that doesn't solve the main issue of not being able to differentiate shreds delivered via repairman vs turbine. |
|
how does the flow control work with repairman? does the node keep updating what it needs? |
|
@carllin please help clarify if I get this wrong. |
|
TODO: recover #7774 as a part of fixing this issue 😿 |
Turbine retransmit logic is based on which socket it received the packet from (i.e `packet.meta.forward`): https://github.com/solana-labs/solana/blob/708bbcb00/core/src/retransmit_stage.rs#L467-L470 This can leave the cluster vulnerable to spoofing and selective propagation of packets; see solana-labs#6672 solana-labs#7774 This commit identifies if the node is on the "critical path" based on its index in the shuffled cluster. If so, it forwards the packet to both neighbors and children; otherwise, the packet is only forwarded to the children.
Turbine retransmit logic is based on which socket it received the packet from (i.e `packet.meta.forward`): https://github.com/solana-labs/solana/blob/708bbcb00/core/src/retransmit_stage.rs#L467-L470 This can leave the cluster vulnerable to spoofing and selective propagation of packets; see solana-labs#6672 solana-labs#7774 This commit identifies if the node is on the "critical path" based on its index in the shuffled cluster. If so, it forwards the packet to both neighbors and children; otherwise, the packet is only forwarded to the children.
Turbine retransmit logic is based on which socket it received the packet from (i.e `packet.meta.forward`): https://github.com/solana-labs/solana/blob/708bbcb00/core/src/retransmit_stage.rs#L467-L470 This can leave the cluster vulnerable to spoofing and selective propagation of packets; see solana-labs#6672 solana-labs#7774 This commit identifies if the node is on the "critical path" based on its index in the shuffled cluster. If so, it forwards the packet to both neighbors and children; otherwise, the packet is only forwarded to the children. The metrics added in solana-labs#17351 shows that the number of times the index does not match the port is very rare, and therefore this change should be safe.
Turbine retransmit logic is based on which socket it received the packet from (i.e `packet.meta.forward`): https://github.com/solana-labs/solana/blob/708bbcb00/core/src/retransmit_stage.rs#L467-L470 This can leave the cluster vulnerable to spoofing and selective propagation of packets; see solana-labs#6672 solana-labs#7774 This commit identifies if the node is on the "critical path" based on its index in the shuffled cluster. If so, it forwards the packet to both neighbors and children; otherwise, the packet is only forwarded to the children. The metrics added in solana-labs#17351 shows that the number of times the index does not match the port is very rare, and therefore this change should be safe.
Turbine retransmit logic is based on which socket it received the packet from (i.e `packet.meta.forward`): https://github.com/solana-labs/solana/blob/708bbcb00/core/src/retransmit_stage.rs#L467-L470 This can leave the cluster vulnerable to spoofing and selective propagation of packets; see solana-labs#6672 solana-labs#7774 This commit identifies if the node is on the "critical path" based on its index in the shuffled cluster. If so, it forwards the packet to both neighbors and children; otherwise, the packet is only forwarded to the children. The metrics added in solana-labs#17351 shows that the number of times the index does not match the port is very rare, and therefore this change should be safe.
Turbine retransmit logic is based on which socket it received the packet from (i.e `packet.meta.forward`): https://github.com/solana-labs/solana/blob/708bbcb00/core/src/retransmit_stage.rs#L467-L470 This can leave the cluster vulnerable to spoofing and selective propagation of packets; see solana-labs#6672 solana-labs#7774 This commit identifies if the node is on the "critical path" based on its index in the shuffled cluster. If so, it forwards the packet to both neighbors and children; otherwise, the packet is only forwarded to the children. The metrics added in solana-labs#17351 shows that the number of times the index does not match the port is very rare, and therefore this change should be safe.
Turbine retransmit logic is based on which socket it received the packet from (i.e `packet.meta.forward`): https://github.com/solana-labs/solana/blob/708bbcb00/core/src/retransmit_stage.rs#L467-L470 This can leave the cluster vulnerable to spoofing and selective propagation of packets; see solana-labs#6672 solana-labs#7774 This commit identifies if the node is on the "critical path" based on its index in the shuffled cluster. If so, it forwards the packet to both neighbors and children; otherwise, the packet is only forwarded to the children. The metrics added in solana-labs#17351 shows that the number of times the index does not match the port is very rare, and therefore this change should be safe.
Turbine retransmit logic is based on which socket it received the packet from (i.e `packet.meta.forward`): https://github.com/solana-labs/solana/blob/708bbcb00/core/src/retransmit_stage.rs#L467-L470 This can leave the cluster vulnerable to spoofing and selective propagation of packets; see #6672 #7774 This commit identifies if the node is on the "critical path" based on its index in the shuffled cluster. If so, it forwards the packet to both neighbors and children; otherwise, the packet is only forwarded to the children. The metrics added in #17351 shows that the number of times the index does not match the port is very rare, and therefore this change should be safe.
Turbine retransmit logic is based on which socket it received the packet from (i.e `packet.meta.forward`): https://github.com/solana-labs/solana/blob/708bbcb00/core/src/retransmit_stage.rs#L467-L470 This can leave the cluster vulnerable to spoofing and selective propagation of packets; see #6672 #7774 This commit identifies if the node is on the "critical path" based on its index in the shuffled cluster. If so, it forwards the packet to both neighbors and children; otherwise, the packet is only forwarded to the children. The metrics added in #17351 shows that the number of times the index does not match the port is very rare, and therefore this change should be safe. (cherry picked from commit 1618386)
…17973) Turbine retransmit logic is based on which socket it received the packet from (i.e `packet.meta.forward`): https://github.com/solana-labs/solana/blob/708bbcb00/core/src/retransmit_stage.rs#L467-L470 This can leave the cluster vulnerable to spoofing and selective propagation of packets; see #6672 #7774 This commit identifies if the node is on the "critical path" based on its index in the shuffled cluster. If so, it forwards the packet to both neighbors and children; otherwise, the packet is only forwarded to the children. The metrics added in #17351 shows that the number of times the index does not match the port is very rare, and therefore this change should be safe. (cherry picked from commit 1618386) Co-authored-by: behzad nouri <behzadnouri@gmail.com>
|
Turbine port-based forwarding logic is removed as of #17716 released on v1.7 branch |
Problem
Validators make many shred decisions based on which port it was received on.
This is not secure at all. This issue is related to the regular DoS that is possible on any of a validator's ports. However it leaves the window open for an amplification attack.
Proposed Solution
@aeyakovenko
The text was updated successfully, but these errors were encountered: