Subject: Re: [ppsp] Quaetions on tracker and peer protocols

From: Arno Bakker <[email-masked]>
Date: Wed, 20 Nov 2013 13:28:23 +0100

Hi Roni

Did you get my first reply? I just noticed I replied just to the mailing
list, not to you directly, sorry. I've been reading up on ICE and here
is my take on the matter.

To use ICE, a communication channel running a signalling protocol such
as SIP or P2PSIP is needed to transmit the offers and answers. For the
peer protocol, I assume this signalling protocol is a separate protocol,
so no signalling functionality is needed in the peer protocol (as it
isn't in RTP). How the combination of the peer protocol and that
signalling protocol work together can be described in the planned usage
guide draft.

Theoretically, such signalling functionality could be added to the
tracker protocol, but I leave that up to the tracker protocol designers.

In conclusion, for the peer protocol to work with ICE it seems to me
that it is sufficient if we allow STUN and TURN traffic on the same UDP
port as used by the peer protocol. STURN/TURN messages all start with
32-bits containing message type and length, followed by a 32-bit magic
cookie 0x2112A442 [RFC5389,p. 11]. A peer protocol UDP datagram starts
with a 32-bit connection ID, followed by 0 or more PPSPP messages. Each
message consists with a 1 byte message type. Hence, if we reserve
message type 0x21, a UDP datagram can be easily recognized as either
PPSPP or STUN/TURN by checking the length and the 5th byte.

Regarding your item 6 about PEX_RES and same addresses. I misunderstood
your question. The answer should be (quoting from the peer protocol
draft): "If a PEX_REQ message does not originate from a private or
link-local address [RFC1918][RFC4291], then the PEX_RES* messages sent
in reply MUST NOT contain such addresses."

Regards,
    Arno

On 30/10/2013 16:22, Arno Bakker wrote:
> Hi Roni and all
> 
> thanks for your interesting questions, and sorry for my slow reply.
> Please see inline for the peer protocol related parts.
> 
> On 19/10/2013 11:29, Roni Even wrote:
>>
>> 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. 
>>
> 
> 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.
> 
> 
>> 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?
>>
> 
> 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].
> 
> 
>> 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?
>>
> 
> PEX_REQ and PEX_RES are now (draft-08) used solely for address
> gossiping, and not for NAT hole punching anymore.
> 
> 
>> 7.       In the peer protocol what is the data format the example in section
>> 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
>