p2psp team mailing list archive

[Max Mertens <max.mail@xxxxxxxxxx>]

Hi everybody,

On 12.06.2015 10:02, Vicente Gonzalez wrote:
>
>     The only difference between the server and client is that the
>     server sends UDP packets every 5 seconds, and the client every 1
>     second.
>     It is a bit surprising that e.g. RCN->PRCN connection does not
>     work but PRCN->RCN does, and sometimes one peer can see the other
>     peer connecting but cannot reply. I think that this asymmetric
>     behaviour is due to the chownat implementation (as server and
>     client are not exactly equivalent) and should not occur in a NTS
>     implementation.
>
>
> Well, according to:
>
> http://en.wikipedia.org/wiki/Network_address_translation
>
> A PRCN is more restrictive than a PRC, so, for my makes sense that
> RCN->PRCN connection does not work but PRCN->RCN does. However, it is
> possible that you are right :-)
Ok, this makes sense, if the connection is made into one direction.
However, in our case the connection is not directed, as both peers are
equally sending UDP packets to each other. So it should not make a
difference which one is RCN or PRCN.
In fact, I had a typo in the PRCN iptables rules on one machine (wrong
interface name), so this was the reason the connection could not be
established. Here is the updated table for chownat connection tests,
changed values in bold:

    Client \ server 	FCN 	RCN 	PRCN 	SYM
    FCN 	yes 	yes 	*yes* 	no
    RCN 	yes 	yes 	*yes* 	no
    PRCN 	yes 	yes 	*yes* 	no
    SYM 	(no) 	(no) 	no 	no


Now the connections involving a PRCN do work (and PRCN <-> SYM does not
work), just as expected. Note however that if one of the NATs is
symmetric, no connection can be established.

With my UDP connection test program I did the same tests, and it
resulted in this table:

    1 \ 2 	FCN 	RCN 	PRCN 	SYM
    FCN 	yes 	yes 	yes 	*yes*
    RCN 	yes 	yes 	yes 	*yes*
    PRCN 	yes 	yes 	yes 	no
    SYM 	*yes* 	*yes* 	no 	no


So with that also the connections FCN/RCN <-> SYM do work. That is
possible with this commit [1], with which a peer takes the source port
of an incoming packet (which is, in case of a symmetric NAT, different
from the port reported by the splitter) and sends all further messages
to this port.

> At this moment, the implementation of the P2PSP allows to select
> (using inheritance) the number of set of rules that a peer will
> implement (the same should happen for the splitter). This is the only
> that you should keep in mind while you will write your implementation.
> However, it is very likely that all peer, in a real scenario, will
> implement the NTS.
Ok, I will follow this inheritance principle when writing the
implementation.
> All video data is transmitted over UDP, so, you can ignore the TCP for
> now.
> No, the chunk recovery mechanism should be the responsability of a
> different set of rules.
Ok, great. So next I will adapt the code of the nts_test programm to
fully implement the NTS algorithm.

I checked if I could test NAT traversal between my home router and
university's internet, however at the university each client gets an own
global IPv4 address with all ports open, so it is a Full Cone NAT type
and a trivial example of NAT traversal.
Do you know if there are maybe some public NAT servers to test, or do
you have a NAT testing setup for P2PSP development, or is NAT simulation
with VMs and iptables enough?
Should I somewhere document the setup and iptables rules I am using, and
the resulting tables as above, to make the test reproducible (maybe as a
Readme in the repo)?

Currently I am reading through a memo/RFC about "Symmetric NAT Traversal
using STUN" [2] which divides NATs not only in FCN, (P)RCN, SYM but in 9
categories, depending on source port allocation and incoming packet
filtering. It also discusses methods to establish connections in the
"no"-cases above (PRCN <-> SYM and SYM <-> SYM) by port prediction,
which I would like to try out after implementing the NTS set of rules.

Best,
Max


[1]
https://github.com/jellysheep/p2psp/commit/31d3231011fabbb393c43c294f0e77c7c983a04d
[2] https://tools.ietf.org/id/draft-takeda-symmetric-nat-traversal-00.txt