Subject: Re: [P2PSIP] Remove StoreReq.resource, FetchReq.resource, etc.

From: "Michael Chen" <[email-masked]>
Date: Sat, 26 Dec 2009 20:23:10 -0700

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-masked]>

Date: Sat, December 26, 2009 5:20 pm

To: Michael Chen <[email-masked]>

Cc: [email-masked]

On Sat, Dec 26, 2009 at 5:15 PM, Michael Chen <[email-masked]> 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

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 26 Dec 2009 21:19:41 -0800

On Sat, Dec 26, 2009 at 7:23 PM, Michael Chen <[email-masked]> wrote:
> 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.
>

I may have missed something, but the existing rules are intended to stop this
from happening.

Best,
-Ekr