On Sat, Dec 26, 2009 at 7:23 PM, Michael Chen <[email protected]> wrote: > Eric, > You are right. I forgot about replica store. > However, I was also thinking about the possibility that some implementation > may fall victim of a malicious message in which the resource ID in the > destination list and the resource ID in these structures are carefully > chosen. > For example, a StoreReq message is routed based on the destination list that > arrived at a peer responsible for the last entry (a resource ID) in the > list. When that peer reads StoreReq.resource, it realized that it is not > responsible for this resource nor as a replica.(because this ID was > purposely chosen not to be such).
Right. At this point it should (MUST; see 6.4.1.1) reject the request: If the replica number is zero, then the peer MUST check that it is responsible for the resource and, if not, reject the request. If the replica number is nonzero, then the peer MUST check that it expects to be a replica for the resource and that the request sender is consistent with being the responsible node (i.e., that the receiving peer does not know of a better node) and, if not, reject the request. > An implementation may naturally determined that this StoreReq message should > be forwarded to the peer responsible for StoreReq.resource. I will not be > surprised if this is done by a generic forwarding layer that will preserve > the last entry of the destination list (the first resource ID) and simply > add the responsible/closest peer of StoreReq.resource on the top of the > list. > The result is that this message will be routed right back to this peer. I > don't recall any guidance from the draft for this situation or route-loop > detection. This peer may repeat the same mistake and keep the message > looping in the ring. > > If we want to protect against that, some explicit rules should be spelled > out here. Any thoughts? I may have missed something, but the existing rules are intended to stop this from happening. Best, -Ekr _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
