Subject: [ppsp] Quaetions on tracker and peer protocols

From: "Roni Even" <[email-masked]>
Date: Sat, 19 Oct 2013 12:29:23 +0300

Hi,

I did not follow the work on PPSP closely but I read the current tracker
peer protocol drafts and have some questions.

1.       The tracker document has xml examples but has no protocol
description. I think I saw some discussion about having a binary protocol
and looking forward to see it. This will need to be reflected  also in the
IANA section.

2.       I noticed that the peers provide addresses when connecting to the
tracker and the tracker may be a stun server but I am not sure if this will
be enough for NAT traversal. I would expect some discussion on what
addresses can be supplied. Maybe look at the p2psip base draft about the
data structures, there may be a need for more ICE address candidates. More
text should be in the peer protocol document.

3.       It is also not clear what types of transport are allowed and
supported, the only one mentioned is UDP with LEDBAT for congestion control.
There is some mention of DTLS in the security section but I think that
currently the IESG will require some mandatory secure transport or an
explanation why one is not specified.  Maybe propose DTLS over UDP/ICE for
transport. 

4.       I did not see in the requirements the need to support establishing
and using connections between peers separated by one or more NATs.

5.       In the peer protocol the HANDSHAKE message does not discuss NAT
traversal using ICE to supply more candidates. Is the PEX_REQ and PEX_RES
messages duplicating ICE?

6.       About using PEX_RES message for introducing peers; if peer B and C
are in one address domain and A and D are in other than it may happen that
peer C and D will have the same IP address, so when B sends to A in the
PEX_RES the address of C then A may send PEX_RES to D?

7.       In the peer protocol what is the data format the example in section
8.6 have the DATA as ASCII encoded. 

Thanks

Roni Even

---

From: Arno Bakker <[email-masked]>
Date: Wed, 30 Oct 2013 16:22:53 +0100

Hi Roni and all

thanks for your interesting questions, and sorry for my slow reply.
Please see inline for the peer protocol related parts.

> explanation why one is not specified.  Maybe propose DTLS over UDP/ICE for

At present only UDP with LEDBAT congestion control is allowed. Future
extensions may define the peer protocol over other transports. The peer
protocol itself is secure in the sense that integrity of the chunks
cannot be interfered with, it cannot be used for amplifications attacks
and malicious peers cannot completely halt its operation, as described
in the Security Considerations. Did you find holes in these protection
mechanisms that require DTLS by default in addition? We only have DTLS
or IPsec when a deployer wants point-to-point confidentiality.

> messages duplicating ICE?

Question is whether the candidate signaling of ICE is done purely via
the tracker protocol, or also via the peer protocol? I did notice that
we should add a paragraph to the peer protocol to ensure STUN packets
are not mistaken for PPSPP datagrams. Reserving message type 0x21 such
that the magic cookie can be recognized should be enough (see [RFC5389,
p. 11].

> PEX_RES the address of C then A may send PEX_RES to D?

PEX_REQ and PEX_RES are now (draft-08) used solely for address
gossiping, and not for NAT hole punching anymore.

> 8.6 have the DATA as ASCII encoded. 

We have replaced this formalism with the normal IETF bits-on-the-wire
specification that is hopefully less ambiguous.

Regards,
     Arno