On Feb 19, 2011, at 3:53 PM, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 02/13/2011 05:04 PM, Bruce Lowekamp wrote: >> Marc, >> >> I think there's an underlying issue here of whether it's important to >> - use the same "physical" connection between two physical nodes that >> are both acting as multiple virtual nodes for all pairs of >> connectivity between them >> AND >> - differentiate on the receipt of a message what pair of virtual nodes >> A'->B' the original sender believed the message was going between. >> >> I'm not immediately convinced that this is a useful property for the >> routing system, as if each physical node is merging the virtual nodes' >> routing tables and forwarding to the closest match, I don't think it's >> necessary for reliable routing. However, if you have a pointer to a >> description of why this would be useful, I'd be very interested in >> reading it. >> >> With that said, my current opinion is that what you want to accomplish >> can and should be accomplished through a new routing algorithm. >> However, I think we should move to incorporate the new SignerIdentity >> into the base draft and probably handle the IceExtension as a new >> draft. But both should probably get a thread of their own so they >> have more eyes. > > I spent more time on this problem(s) (the fact that the information on a > specific subject are scattered all over the I-D does not help, for sure), and > I > am now less sure that there is a need for this changes. Let's take the issues > one by one: > > 1. Connections sharing: I am still running some simulations and so far I do > not > have an definitive answer, so let forget about this for now. Hopefully it > could > be done as an extension, as you suggested. > > 2. Knowing the Node-ID of the sender of an end-to-end message, when multiple > Node-IDs are used in the certificate: > > - - If the message is a request and traversed at least one peer, then the > sender > Node-ID will be the first Node-ID in the via list.
Regrettably, this is not always true due to via list compression. If you want to know this, we should add an extension to the signature. > - - If the message is a request that was sent over a direct connection, then > the > sender Node-ID is the Node-ID associated with the connection - see (3). > > - - If the message is an answer, then the sender Node-ID is the same Node-ID > that > was used to send the matching request. An implementation had to store it for > the end-to-end retransmission, so it is retrievable from the transaction-id. I fear that this is not true as well, since you can send to a resource-id. -Ekr > 3. Knowing the Node-ID of the sender of a message on a direct connection, when > multiple Node-IDs are used in the certificate: > > - - Because direct connections are established by Attach, the Node-ID of the > sender of a message on a direct connection is also the Node-ID of the sender > of > the Attach message (request or answer) that was used to establish the direct > connection - see (2). > > Now there is one case that does not work: a client with a certificate with > multiple Node-IDs. Because a client connects directly to a bootstrap peer > (without Attach), the bootstrap node has no way to know which Node-ID to > choose > on the certificate. When the Attach to the admitting peer will be sent by the > client, the bootstrap peer will not be able to know what Node-ID to add in the > via list, and so will not be able to route back the answer. And neither a new > SignerIdentity or IceExtension can help in this case. > > So because it is not possible to join an overlay with a certificate containing > multiple Node-IDs, the only way it could work would be to join with a > certificate containing one Node-ID then after the Attach to the admitting peer > switch to a certificate with multiple Node-IDs. Was that the intent? > > > - -- > Marc Petit-Huguenin > Personal email: [email protected] > Professional email: [email protected] > Blog: http://blog.marc.petit-huguenin.org > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > > iEYEARECAAYFAk1gWAAACgkQ9RoMZyVa61fFXwCfegOrqYADs9809eM+N0y5muMA > gRUAn2x4ZThclCBYbEZ4aMMmrM4p+3PO > =gCJY > -----END PGP SIGNATURE----- > _______________________________________________ > P2PSIP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
