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).
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?
--Michael
-------- Original Message --------
Subject: Re: [P2PSIP] Remove StoreReq.resource, FetchReq.resource, etc.
From: Eric Rescorla <[email protected]>
Date: Sat, December 26, 2009 5:20 pm
To: Michael Chen <[email protected]>
Cc: [email protected]
On Sat, Dec 26, 2009 at 5:15 PM, Michael Chen <[email protected]> wrote:
> Hi,
> The resource IDs in these request structures should be removed and be
> provided only from the Destination list in the forwarding header.
> StoreReq.resource
> FetchReq.resource
> StatReq.resource
> FindReq.resource
> This can avoid the possible inconsistency between the header and the
> message. It may make the request structure seemingly incomplete, but less is
> more.
These aren't actually redundant. There are times when you want to do a
Store or a Fetch to the non-responsible node (e.g., replica stores).
-Ekr
_______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
