Subject: [P2PSIP] Technical Comments on draft-bryan-p2psip-reload-03

From: Alan Johnston <[email-masked]>
Date: Tue, 11 Mar 2008 16:10:15 -0500

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-masked]
https://www.ietf.org/mailman/listinfo/p2psip

---

From: jiangxingfeng 36340 <[email-masked]>
Date: Tue, 11 Mar 2008 18:31:20 -0500

> lists - all of which need proper discussion.

Fragmentation/Reassembly may introduce new security issues. 

> 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. 
> given for requiring symmetric routing.  Clearly this needs more 

That's what semi-recursive routing mode wants to achieve. Semi-recursive routing mode tries to make the response traverse fewer hops. 

> 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

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 11 Mar 2008 23:24:08 -0400

At Tue, 11 Mar 2008 18:31:20 -0500,
> 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 = 6…

This sounds a lot smaller when you measure it in bytes==80.

-Ekr

---

From: <[email-masked]>
Date: Wed, 12 Mar 2008 17:34:35 +0200

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-masked] [mailto:[email-masked]] 
>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
>
>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.
>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.
>
>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.
>
>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.
>
>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.
>
>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.  
>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 
>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