Subject: [P2PSIP] RFC6940: Detecting Partitioning

From: Evgeny <[email-masked]>
Date: Sun, 14 Oct 2018 22:04:38 +0300

Hi there

I have hard time understanding the mechanism described in 10.7.4.4 
(Detecting Partitioning) [1]:

 > P SHOULD then send a Ping for its own Node-ID routed through B.
 > If a response is received from peer S', which is not P's successor,
 > then the overlay is partitioned

How is it even possible? Given the Symmetric Recursive Routing, the 
Ping answer will always come from node B.
I tried to grasp through the RFC about special routing rules of Ping 
answers, but I didn't find anything special
except the statement in 6.1.2 (Other ID) [2] which I *fail* to 
understand:

 > The node MUST implement support for
 > returning responses to a Ping or Attach request made by a Joining
 > Node Attaching to its responsible peer

"made by a Joining Node Attaching to its responsible peer"? What does 
that mean exactly? Why is "Attaching"
with a capital letter?

[1] https://tools.ietf.org/html/rfc6940#section-10.7.4.4
[2] https://tools.ietf.org/html/rfc6940#section-6.1.2

---

From: Michael Chen <[email-masked]>
Date: Sun, 14 Oct 2018 15:25:52 -0700

Let me take a look Monday.

I also noticed that you asked about test vectors back in May. I am one of the few that has a full implementation available for interoperability testing. Let's see if we can still organize one.

--Michael

On Oct 14, 2018 12:04 PM, Evgeny <[email-masked]> wrote:

Hi there

> then the overlay is partitioned

How is it even possible? Given the Symmetric Recursive Routing, the Ping answer will always come from node B.

I tried to grasp through the RFC about special routing rules of Ping answers, but I didn't find anything special

> Node Attaching to its responsible peer

"made by a Joining Node At
taching to its responsible peer"? What does that mean exactly? Why is "Attaching"

with a capital letter?

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Mon, 15 Oct 2018 09:13:44 +0200

Hi Evgeny,

> answer will always come from node B.

Yes, the last hop forwarding the answer will be B, but the originating
node from the other end (i.e., the one answering the ping request) is a
different node than P's current successor.

> "made by a Joining Node At taching to its responsible peer"? What does

That may be best understood by looking at Figure 1 on page 139 and/or
section 10.5.
The Joining Node sends an AttachReq to its own ID+1 (this process
is probably denoted as "Attaching"). The Admitting Peer (AP) and
responsible peer are the same in this case, it will be the successor
of the newly joining node. Does this make sense?

Regards,
 Roland

---

From: Evgeny <[email-masked]>
Date: Mon, 15 Oct 2018 10:56:54 +0300

> different node than P's current successor.

"the one answering the ping request"? But this will be my node 
answering the ping request.
Ok, I'm lost. Let's consider the PingReq path:

my_node -> boot_node -> ... -> node_X -> my_node

The corresponding PingAns will be:

my_node -> node_X -> ... -> boot_node -> my_node

So the idea is to check if node_X is the successor of my_node, right?
In this case I don't understand how to get that node from the answer: 
forwarding nodes
are not required to maintain Via lists, or they can just hide the path 
by OpaqueID.
Should I maintain some state on my node to do these checks?

> of the newly joining node. Does this make sense?

Yes, this makes sense, and this is trivial, but it's hard to understand 
from that phrase.
Whatever, thanks for the clarification.

---

From: Michael Chen <[email-masked]>
Date: Mon, 15 Oct 2018 18:00:02 -0700

This is universal for all RELOAD requests and responses, regardless how many forwarding node involved:

1. The security block of a request belongs to (signed by) the requesting node.

2. The security block of a response belongs to (signed by) the responding node.

3. A forwarding node only changes the header (e.g. via list, which is why you won't find the requester and responder in via list).

Therefore, the partition check response header and body are both useless to the requester, only it's security block matters, which has the responders identity.

I hope that helps.

--Michael

---

From: Roland Bless <[email-masked]>
Date: Tue, 16 Oct 2018 09:15:13 +0200

Hi Evgeny,

On 15.10.2018 at 09:56 Evgeny wrote:
> "the one answering the ping request"? But this will be my node answering
> the ping request.

No, your successor should answer the request, as one should ping
own ID+1. This seems to be inconsistent with the RFC:
"P SHOULD then send a Ping for its own Node-ID routed through B."
Own Node-ID would not work and the initial join procedure
in sec. 10.5 says
"JN SHOULD send an Attach request to the Admitting Peer (AP) for
 Resource-ID n+1"

So Michael already filed an errata.

> Should I maintain some state on my node to do these checks?

The originator of the reply message can be found in the identity part of
the signature block.

Regards,
 Roland

---

From: Evgeny <[email-masked]>
Date: Tue, 16 Oct 2018 10:34:11 +0300

Michael, Roland, thanks for your quick responses, now it makes things 
clear ;)