> 4. The security considerations is missing all transport security > issues. > The previous issue of the lack of end-to-end privacy in the > protocol is > one example of the missing discussion of all transport security > issues. > Others include the security requirements of destination lists and > via > lists - all of which need proper discussion.
Fragmentation/Reassembly may introduce new security issues. > > 5. Bootstrapping is not fully defined. > > Bootstrapping is a critical function in any P2P protocol and is > not > fully specified. It also seems that certain deficiencies in the > proposed bootstrapping mechanism are compensated for in other > areas of > the protocol, such as the requirement for symmetric response > routing. > Incorporating more elements from > draft-matthews-p2psip-bootstrap-mechanisms may solve this problem > rather than trying to patch it in other places. The current > mechanism > is not specified enough for me to offer a more complete analysis. I am also want to konw how it exactly works or which bootstrap method is applied. On the other hand, the authors say that RELOAD could be applied in the situations where all peers are behind NAT. I'd like to see more detailed text about that. > > 6. The impact of peers leaving the overlay is not discussed with > respect > to symmetric response routing. > > Others have pointed out and discussed the issues relating to > requiring > symmetric response routing. Ironically, overlay stability is the > reason > given for requiring symmetric routing. Clearly this needs more > discussion and analysis. That's what semi-recursive routing mode wants to achieve. Semi-recursive routing mode tries to make the response traverse fewer hops. > > 7. Destination lists are underspecified, add complexity, and not > justified for inclusion. > > For example, there is no text for discovering and dealing with > loops in > destination lists. There is no discussion about the security > considerations of destination lists. More justification is > needed for > inclusion in the protocol. You know, the information in the via-list and destination list is about peer-id which is often at least 128 bit long. If the message traverse 5 hops, the messge payload will be at least 128 * 5 = 640. From my point of view, it is a big size because it has not include any other payload. So the message may be fragmentated with high probability. JiangXingFeng _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
