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
