Here are my comments on this draft.
I apologize for the repetition, but half of the technical issues I
raised back in March on the list and in Philadelphia haven't really had
any discussion. I'll also go through the other four issues as they have
been either fully or partially addressed.
There are also a few new issues as well.
Thanks,
Alan
- - - - -
Issues from March that have not been addressed:
1. The layering of the protocol
Currently, this protocol has functions from the application layer (distributed
database), transport layer (retransmissions), and internet layer
(fragmentation). Do we really need to do this? Do we have the right expertise
to tackle all these issues? Just saying that anytime an overlay is used, there
will be layer violations does not address this. If we are not clear about what
protocol layer functions we are building, we will be in big trouble in the IESG
and in the Internet in deployments. Also, there is an open issue about what
layer this interacts with SIP, and whether a new SIP transport token needs to
be defined.
2. There seems to be an inability to reuse connections between peers.
This restriction in 4.3 has no discussion or analysis. Is it for security reasons? Or simplicity? Running ICE is costly, and to design the protocol to rule out NAT mapping reuse seems strange.
3. There is still a major security flaw relating to SIPS.
I don't think I need to repeat myself on this one. If I am incorrect that a
SIPS (or any SIP message sent over TLS) sent using the Tunnel method would not
be transported confidentially over the overlay, then please let me know.
Otherwise, fixing this before WGLC would seem like a good idea.
4. The security considerations is missing all transport security issues.
This protocol has many transport functions and they need a good security
analysis.
Addressed:
5. Bootstrapping is underspecified.
The use of destination lists seems like a crutch to get this to work right -
I'd be interested in others opinions of this.
6. The impact of peers leaving the overlay is not discussed with respect
to symmetric response routing.
The discussion of this and other routing issues is good, although perhaps it
should move to an appendix in the future.
7. Destination lists are underspecified, add complexity, and not
justified for inclusion.
The description of a client connecting to an arbitrary peer in the overlay
(page 18) seems to be the main use case for this (besides fixing
bootstrapping). It would be useful to discuss the motivation for this, and
whether this use case justifies the inclusion of destination lists. Also, a
security analysis of their effects would be useful for a cost/benefit analysis.
I'm still not convinced they are a benefit to the protocol.
8. The text relating to HIP is misleading.
The current text is no longer misleading.
Additional issues:
9. Primitives with different DHTs
Since different DHTs will result in different semantics, usage, and message
contents for Join, Update, and Leave, does it make sense to reuse the same
name? Alternatively, we could define Join-Chord, Update-Chord, etc which would
always have just one format and usage, with Join-XYZ, Update-XYZ, etc defined
for new DHTs. Also, some DHTs might have a need for additional primitives.
Thoughts?
10. Symmetric Chord
Perhaps this has already been discussed, but I recall Philip Matthews proposed
a modified chord that used symmetric finger tables to minimize the number of
NAT mappings/ICE runs needed. I can see the advantage of using either
unmodified Chord, or optimizing Chord for our needs. Since we are already
making some changes to standard Chord, perhaps we should consider this.
11. Keepalives
It seems that keep alives are happening at multiple levels, which might be OK.
The Ping method provides keep alives at the DHT level while ICE keep alives are
used at the connection level. Is this correct?
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
