Subject: [P2PSIP] WG Meeting Preview Reload

From: Cullen Jennings <[email-masked]>
Date: Thu, 22 Jul 2010 18:42:48 -0700

We've scheduled a bunch of time in Maastricht to talk about RELOAD Open Issues. This mail contains a preview of the issues we think still need some resolution:

1. Overlay Link Protocols

On May 17, 2010 Michael Chen raised a good point:

   1. In most cases, when peer A wants to Attach to peer X, peer A MUST
   decide whether to send an ICE or No-ICE while knowing nothing about X
   beyond its NodeId. It seems to me A has no choice but to send ICE
   attach.
   
   2. When connecting to a bootstrap node or any nodes with known public
   IP, there is no need to send the Attach message. Just do D/TLS directly
   to the nodes' IP and port number.

   Then what is the use case for a No-ICE Attach?

However, we have had requests from people who want to support non-ICE
environments. 

Proposed resolution: The overlay needs to specify if ICE used or not.
This is consistent with how we had intended for it to be, but the
draft is probably inconsistent. If people know of places where there
are such errors, please point them out and we'll fix them.

2. Direct Return Response

In some cases this requires the ability to modify forwarding headers.
Offline discussion with Roni leads us to believe this can be done with
current Forwarding header with no change to draft. We will reconfirm with
Roni that this this issue is closed. Will update draft to fix wording
to clarify that intermediate peers can modify forwarding options.

3. Overlay Algorithm

There was some discussion about when the finger table is needed or not needed when doing an ATTACH.  We propose to add a flag to the attach request that indicates if the
finger table should be transferred. Do we have consensus for this
change?

4. Transport Security

We still haven't resolved the question of how to handle security.

Proposal: Per our proposal last IETF, we propose have TLS as the basic
mechanism, but other mechanisms can in principle be defined. We will
add a field to the configuration that specifies the security mechanism
of the overlay. The only one defined in this document is TLS. Any
standard track document that defines new ones MUST provide at minimum:
(1) endpoint authentication (2) message integrity, and (3)
confidentiality.

5. Peer-ID Length

The current document specifies a fixed 128-bit peer-ID. Some people
have requested a longer ID.

Proposal: Stay with the rough consensus from IETF 77 of a variable
length (per-overlay) ID with a maximum possible size of 160 bits.