Subject: [P2PSIP] Technical Comments on draft-ietf-p2psip-reload-00

From: Alan Johnston <[email-masked]>
Date: Sun, 27 Jul 2008 08:24:41 -0500

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

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 28 Jul 2008 03:10:53 -0500

Just for the record, I share Alan's concern about (1) and hope I also raised 
this concern previously (because I should have).

Spencer

> 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.
>
> 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.

---

From: Alan Johnston <[email-masked]>
Date: Tue, 29 Jul 2008 10:17:17 -0500

Bruce,

Thanks for your response.  Clearly there's lots to discuss in these 
topics.  I have a comment relating to two of your responses.

Thanks,
Alan

Bruce Lowekamp wrote:
> <snip>
>> 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.
>>
>
> Since the current draft does not specify tunneling SIP over the 
> overlay, no new tokens are needed at this time.
>
>> <snip>
>> 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.
>>
>
> The current draft does not specify sending SIP messages through 
> tunnels.  Such a specification would absolutely have to address that 
> issue.
>
I am very surprised by the removal of this.  Was this just done to avoid 
dealing with the security and transport issues or was it felt that there 
was no value in it?

If we are unable to route SIP messages over the overlay, then the 
overlay is effectively not providing a last resort rendezvous 
functionality that we have with CS SIP.

So the only alternative seems to be for every peer to reserve and use 
TURN candidates every time a SIP connection is established.  Otherwise, 
in the perhaps 15% of cases where a relay is needed, the SIP connection 
will fail. 

I'm very concerned that we have not fully thought through this usage of 
TURN for both SIP and media...

---

From: Dean Willis <[email-masked]>
Date: Tue, 29 Jul 2008 17:02:04 +0100

On Jul 29, 2008, at 4:17 PM, Alan Johnston wrote:
>> tunnels.  Such a specification would absolutely have to address  
>> that issue.
>>
> I am very surprised by the removal of this.  Was this just done to  
> avoid dealing with the security and transport issues or was it felt  
> that there was no value in it?
>
> So the only alternative seems to be for every peer to reserve and  
> use TURN candidates every time a SIP connection is established.   
> Otherwise, in the perhaps 15% of cases where a relay is needed, the  
> SIP connection will fail.
> I'm very concerned that we have not fully thought through this usage  
> of TURN for both SIP and media...
>

I have to admit that I'm scratching my head and wondering about this  
one too.

--
Dean