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. _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
