RAP/RAR flags interaction with subdbs #75

New Issue

idk · 2025-04-21T14:59:12-04:00

idk commented

2025-04-21 14:59:12 -04:00

More questinos than answers, consider this a placeholder issue for now... Ripping out RAP/RAR would be another huge batch of changes, probably not the right time... anyway:

The goal of subdbs is to do a "better" job of isolation than the RAP/RAR flags do, right?

But the recent changes don't remove or deprecate the RAP/RAR flags, and actually add a couple setReceivedAsReply() calls in InboundMessageDistributor. Is this a temporary belt-and-suspenders plan, with RAP/RAR slated to be removed in some future release? If subdbs are "better", then could the RAP/RAR flags actually be interfering with the "correct" operation of the subdbs, and impairing whatever improvements subdbs are supposed to bring? Has this been tested? What's the plan?

Also, I have questions about the 2.3.0 change to KNDF.validate(ls), where the date comparison was changed to a deep equals, with a lot of TODO comments. I don't quite understand the point of that change but it's not clear that the author of the change does either. The code now only messes with the flags if the leasesets are (almost) completely identical, but if so, why mess with the flags at all? I think the change breaks some stuff, but not sure.

Anyway, now for 2.4.0, subnetdbs should impact what that 2.3.0 code is trying to do? Or not? But there's no further changes there...

More questinos than answers, consider this a placeholder issue for now... Ripping out RAP/RAR would be another huge batch of changes, probably not the right time... anyway: The goal of subdbs is to do a "better" job of isolation than the RAP/RAR flags do, right? But the recent changes don't remove or deprecate the RAP/RAR flags, and actually add a couple setReceivedAsReply() calls in InboundMessageDistributor. Is this a temporary belt-and-suspenders plan, with RAP/RAR slated to be removed in some future release? If subdbs are "better", then could the RAP/RAR flags actually be interfering with the "correct" operation of the subdbs, and impairing whatever improvements subdbs are supposed to bring? Has this been tested? What's the plan? Also, I have questions about the 2.3.0 change to KNDF.validate(ls), where the date comparison was changed to a deep equals, with a lot of TODO comments. I don't quite understand the point of that change but it's not clear that the author of the change does either. The code now only messes with the flags if the leasesets are (almost) completely identical, but if so, why mess with the flags at all? I think the change breaks some stuff, but not sure. Anyway, now for 2.4.0, subnetdbs should impact what that 2.3.0 code is trying to do? Or not? But there's no further changes there...

idk added the netdb label 2025-04-21 14:59:12 -04:00

idk self-assigned this 2025-04-21 14:59:12 -04:00

idk commented

2025-04-21 14:59:13 -04:00

Agreed and thanks for the explanation. Yeah definitely definitely do not rip out RAP/RAR.

Point is that belt+suspenders is fine but if the belt disagrees with the suspenders, is that good or bad? Could be either. Or both. But there should be a long-term plan about it.

Agreed and thanks for the explanation. Yeah definitely definitely do not rip out RAP/RAR. Point is that belt+suspenders is fine but if the belt disagrees with the suspenders, is that good or bad? Could be either. Or both. But there should be a long-term plan about it.

idk commented

2025-04-21 14:59:13 -04:00

But the recent changes don't remove or deprecate the RAP/RAR flags, and actually add a couple setReceivedAsReply() calls in InboundMessageDistributor. Is this a temporary belt-and-suspenders plan, with RAP/RAR slated to be removed in some future release? If subdbs are "better", then could the RAP/RAR flags actually be interfering with the "correct" operation of the subdbs, and impairing whatever improvements subdbs are supposed to bring? Has this been tested? What's the plan?

I didn't rip them out for at least 2 reasons

I anticipate subDb's using more memory than the monolithic netDb with RAP/RAR flags, and have/am considering consider adding an option to disable subDb's on those devices. This is part of the reason we didn't catch the memory leak, it was just sort of assumed that we would want to keep the DB's around and that memory use would go up, but that was obviously an extremely inadequate analysis to be addressed in some of the other tickets.
The general outline of the netDb deanonymization attacks is that the attacker sends a message containing a LeaseSet or RouterInfo to a client, then trying to obtain it back from a floodfill that it thinks is hosting that client in a way that it can prove happened. By preserving the RAP/RAR flags(possibily temporarily, possibly permanently), we can use them to analyze the subDb's for internal consistency and gain more insight into the path the attacks take. If they are working properly, client DB's should only have one set of flags, main DB's should only have another set of flags. So far this is true. 2.5. I want to see if I can use disagreements between the flags and the Client DB's to identify attempted attacks.

Response on validate() to come, I have to go through my email and chat logs to get the details but my basic recollection is that the attack relied on sending a crafted leaseSet belonging to the attacker to a floodfill, then the attacker sends a slightly altered version of it to a client that it thinks is hosted on the floodfill that it's talking to, then requests it back out of the floodfill that the client associated with. There were 2 or 3 attacks which followed this general form, which were the ultimate motivation for separating out the client DB's. If clients and floodfills were updating information owned by the other in a remotely discernible way then giving them separate DB's where dis-associated clients could not update information in eachother's subDb seemed like the long-term solution. This is also the reason the main DB was originally called the floodfill DB.

> But the recent changes don't remove or deprecate the RAP/RAR flags, and actually add a couple setReceivedAsReply() calls in InboundMessageDistributor. Is this a temporary belt-and-suspenders plan, with RAP/RAR slated to be removed in some future release? If subdbs are "better", then could the RAP/RAR flags actually be interfering with the "correct" operation of the subdbs, and impairing whatever improvements subdbs are supposed to bring? Has this been tested? What's the plan? I didn't rip them out for at least 2 reasons 1. I anticipate subDb's using more memory than the monolithic netDb with RAP/RAR flags, and have/am considering consider adding an option to disable subDb's on those devices. This is part of the reason we didn't catch the memory leak, it was just sort of assumed that we would want to keep the DB's around and that memory use would go up, but that was obviously an extremely inadequate analysis to be addressed in some of the other tickets. 2. The general outline of the netDb deanonymization attacks is that the attacker sends a message containing a LeaseSet or RouterInfo to a client, then trying to obtain it back from a floodfill that it thinks is hosting that client in a way that it can prove happened. By preserving the RAP/RAR flags(possibily temporarily, possibly permanently), we can use them to analyze the subDb's for internal consistency and gain more insight into the path the attacks take. If they are working properly, client DB's should only have one set of flags, main DB's should only have another set of flags. So far this is true. **2.5.** I want to see if I can use disagreements between the flags and the Client DB's to identify attempted attacks. Response on `validate()` to come, I have to go through my email and chat logs to get the details but my basic recollection is that the attack relied on sending a crafted leaseSet belonging to the attacker to a floodfill, then the attacker sends a slightly altered version of it to a client that it thinks is hosted on the floodfill that it's talking to, then requests it back out of the floodfill that the client associated with. There were 2 or 3 attacks which followed this general form, which were the ultimate motivation for separating out the client DB's. If clients and floodfills were updating information owned by the other in a remotely discernible way then giving them separate DB's where dis-associated clients could not update information in eachother's subDb seemed like the long-term solution. This is also the reason the `main` DB was originally called the `floodfill` DB.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: I2P_Developers/i2p.i2p#75