Subject: [P2PSIP] comments on draft-ietf-p2psip-base-06 in WGLC

From: Roni Even <[email-masked]>
Date: Thu, 10 Dec 2009 23:30:54 +0200

Hi, 
I read the draft and came up with the following concerns. I did not review
all other comments on the list but it looks like some of them were mentioned
by others

According to section 1 Reload is based on the concepts introduced in
ietf-p2psip-concepts. The concept draft is currently expired and I noticed
some contradictions between the two drafts. I think that the reload draft
should progress with the concept draft.
According to the concepts draft "The P2PSIP WG will not standardize how the
peer-ID and the credentials are obtained, but merely standardize at least
one acceptable format for each.  To ensure interoperability, it is expected
that at least one of these formats will be specified as
"mandatory-to-implement"."  According to RELOAD the node-id is mandated as a
128 bit value. According to the concept draft it can be as mandatory to
implement format but others should be allowed.  I also think that section
5.4.1 allows for different node-id length (see "o  The length of the
Resource-IDs and Node-IDs.  For DHTs, the hash algorithm to compute the hash
of an identifier."

In section 5.2 on symmetric recursive routing says that "An overlay may be
configured to use alternative routing algorithms, and alternative routing
algorithms may be selected on a  per-message basis." Yet I noted that in
some of the text the assumption is that symmetric recursive is the only
routing algorithm. For example in section 5.2.2 it says "When a peer sends a
response to a request, it MUST construct the destination list by reversing
the order of the entries on the via list.". This is true only for recursive
routing.  Another example is that the text allows an intermediary peer to
decide to keep a per transaction state (see section 5.1.2) which will work
for recursive routing but may break other routing algorithms.  If the text
in section 5.2 is the objective I suggest that in 5.2.2 it will say that in
the case of recursive routing this procedure must be used. I also suggest
that since 5.2.2 allows alternative algorithms on per-message basis than the
requesting peer should be allowed to prevent state keeping by intermediary
peers in order to support other routing mechanisms. The intermediary peers
do not know what routing is used and may choose wrong behavior.

I noticed that the overlay link layer MUST use TLS/DTLS. I am not sure where
the requirement to mandate TLS and DTLS is coming from, more specifically
the requirement to encrypt the signaling. One of the objectives of RELOAD is
to minimize the burden of becoming a peer and TLS with encryption does not
help that. I think that TLS or DTLS can be specified as mandatory to
implement security but optional to use based on the security level required
by the implementation which may chose different security that may be
available in other layers of the network. If there are specific security
requirements based on a specific usage than the requirements to use TLS/DTLS
should be in the usage. I looked at draft-irtf-p2prg-rtc-security and did
not see that TLS/DTLS must be used.  I see cases like when using routing
mechanisms which are not recursive that some of the paths will not need TLS.
Section 3.3 mentions that client promoting to peers may be used for routing,
in the case of passive promotion the establishment of trust relation may
bring different requirements. So I think that mandating using one solution
does not fit all.

Section 3.6.1 details the initial configuration establishment, from the text
it this paragraph and in section 3.6 above it looks like this is the only
allowed procedure, was that the meaning or is that an example. Looking at
section 10 I am not sure what a new configuration file means, is this new
values to the elements, in this case how can the configuration document
defined in section 10 be extended with new elements that may be needed for
new features.

Section 8 discusses TURN server usage. I was wondering if a peer can be a
TURN server it can also be a "supernode" or a relay peer, so why not publish
the general capability that this node is publicly reachable.

Roni Even