I agree with Alan, especially about protocol layering. One of the strengths of P2PP was its simplicity and clear layering. Reload is either very complex or the document needs rewriting.
Besides after reading the reload draft I have a feeling that Reload-3 does not support clients. The draft mentions a word client in a few places but does not address issues that were discussed by the WG and documented in: http://tools.ietf.org/wg/p2psip/draft-pascual-p2psip-clients-01.txt Any P2PSIP protocol that does not support clients is useless from the mobile phone perspective. What concerns me even more is Eric's statement that a client has a DHT layer. This means that there is no difference between a client and a peer. Marcin >-----Original Message----- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >On Behalf Of ext Alan Johnston >Sent: Tuesday, March 11, 2008 11:10 PM >To: P2PSIP Mailing List >Subject: [P2PSIP] Technical Comments on draft-bryan-p2psip-reload-03 > >This draft has a number of editorial/organizational issues >which I will address in a separate email > >This email covers the following technical issues: > >1. The layering of the protocol is very confused. >2. There seems to be an inability to reuse connections between peers. >3. There is a major security flaw relating to SIPS. >4. The security considerations is missing all transport >security issues. >5. Bootstrapping is underspecified. >6. The impact of peers leaving the overlay is not discussed >with respect to symmetric response routing. >7. Destination lists are underspecified, add complexity, and >not justified for inclusion. >8. The text relating to HIP is misleading. > >Here is a discussion of each issue. > >1. Protocol Layering > >This protocol incorporates functions from multiple layers. It >borrows routing and fragmentation functions from Layer 3. It >borrows multiplexing, reliability, and congestion and flow >control from Layer 4. It also operates as a Layer 5 protocol >in the Distributed Database function (STORE/FETCH). It is >also very unclear the layer at which it interacts with SIP. >Routing information from the protocol is proposed to be >included in SIP Contact URIs suggesting it is a Layer 5 >interaction. However, in other cases it interacts as a Layer >4 transport protocol. Overall, I'd say this protocol is a >transport Layer >4 protocol and needs to be reviewed as such. It will need to >have a new transport parameter defined for SIP since it is >neither UDP nor TCP transport. Also, in order for SIPS to be >used over this new transport, proper SIP hop-by-hop >authentication and privacy must be assured (see issue #3). > >The decision to mix so many protocol layers in a single >protocol is one the P2PSIP Working Group should examine very >closely. It certainly adds to the complexity of the protocol >and the security considerations and mechanisms. It also makes >for a very complicated specification to write. A better >approach might be to break up the protocol into proper layers >and shim layers and describe each one separately. > >2. There seems to be an inability to reuse connections between peers. > >Unless I am misunderstanding, the protocol seems unable to >reuse existing connections between peers. For example, >consider two UAs who appear in each other's overlay routing >tables, are in each other's buddy lists, and then establish a >voice and video session between them. This will result in ICE >being run 5 times between them. CONNECT will be sent >3 times. Compare this to an approach that uses careful >layering such as draft-matthews-p2psip-hip-hop or >draft-camarillo-hip-bone which would result in ICE being run >exactly once. > >3. There is a major security flaw relating to SIPS. > >A UA sending a SIPS message using the TUNNEL method will >result in all SIP headers and the message body being available >in plain text to any overlay peer which receives and forwards >the TUNNEL method. > >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. > >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. > >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. > >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. > >8. The text relating to HIP is misleading. > >The text in Section 11.5 seems to imply that this protocol is >compatible with the architecture described in >draft-camarillo-hip-bone, which is essentially the same >architecture in draft-matthews-p2psip-hip-hop. >While this mechanism could be used to route HIP messages >across an overlay, these HIP-based approaches advocate >utilizing HIP signaling and HIP connections. In order to make >this protocol compliant with a HIP architecture would require >major surgery (removal of CONNECT, TUNNEL, and the entire SIP >Usage section) and proper Internet layering design. > >Thanks, >Alan >_______________________________________________ >P2PSIP mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
