Subject: [ppsp] rewording of handshake

From: Dave Cottlehuber <[email-masked]>
Date: Mon, 17 Feb 2014 17:10:17 +0100

Hey folks,  

Some points relating to the handshake follow.

Vanshdeep Singh identified a misunderstanding of mine in the protocol, in the closing handshake sent by a peer when it informs other peers it is leaving the swarm.  

1. At the end of section http://tools.ietf.org/html/draft-ietf-ppsp-peer-protocol-08#section-8.17 it’s clearly shown that the final handshake comprises 0x00000000 channel id for *both* source & destination channels.  

However the handshake definition in http://tools.ietf.org/html/draft-ietf-ppsp-peer-protocol-08#section-8.4 says:

"A channel is established with a handshake.  To start a handshake, the
   initiating peer needs to know …

"A peer SHOULD explicitly close a channel by sending a HANDSHAKE  
   message that MUST contain an all 0-zeros channel ID and a list of  
   protocol options.”  

The status quo can be more clearly worded as: 

"A peer SHOULD explicitly close a channel by sending a HANDSHAKE 
   message that MUST contain all 0-zeros channel ID for both source
   and destination channels, and a list of protocol options.” 

From a technical standpoint, is there a possibility of conflict when swarms are sharing the same unique ip/port, i.e. a peer is using multiplexed channels to handle several swarms, that a closing handshake cannot be sent to a single specific swarm? It makes more sense to me to send a closing channel message to the same destination channel already assigned for this peer, instead of the all zeros channel, and possibly requiring the swarm ID as a mandatory option within that too. My implementation currently assumes to be able to use a given channel ID to uniquely identify which peer/swarm is being referred to, when cleaning up after a parting peer, and also, means that I don’t need to track the state (initiator or sender) of a peer.

2. When handshakes are introduced, it implies they’re only used for initiation.

#section-8.4:

"A channel is established with a handshake.  To start a handshake, the
   initiating peer needs to know”

And in #section-3.1, the opening statement when handshakes are introduced should also mention the closing component as well -- I’m happy to send a diff against the XML if that’s the more appropriate way to handle changes, it would be even nicer if there’s a markdown version instead of the XML [1].

Finally, a colleague of mine is in Beijing this week, if there are any PPSP folk there who would like to get in touch please reply to me off list. Thanks!  

--  
Dave Cottlehuber  
Sent from my PDP11  

[1]: https://github.com/miekg/pandoc2rfc/

---

From: Arno Bakker <[email-masked]>
Date: Mon, 17 Feb 2014 20:16:16 +0100

Hi Dave et al

please see inline.

On 17/02/2014 17:10, Dave Cottlehuber wrote:
> 
> 1. At the end of section
> http://tools.ietf.org/html/draft-ietf-ppsp-peer-protocol-08#section-8.17
> it’s clearly shown that the final handshake comprises 0x00000000
> channel id for *both* source & destination channels.
>

Nope. Destination channel ID is 0x00000008 in the last ASCII art (bit 28
set.) Hence, the receiver can identify which channel is being closed,
and by whom in a secure fashion, as you argue.

> 2. When handshakes are introduced, it implies they’re only used for

You can raise this in the IETF last call, or we can add a phrase about
closing when the IESG feedback comes back.

CU,
    Arno