-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/19/2011 06:09 PM, Eric Rescorla wrote: > > On Feb 19, 2011, at 3:53 PM, Marc Petit-Huguenin wrote: > > 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.
OK, so the Signature extension is mandatory to use multiple Node-IDs in certificates. But the IceExtension still seems useless, as, thanks to the Signature extension, we always know the Node-Id on each side of the Attach. Also a client joining the overlay using a certificate with multiple Node-IDs, using the procedure in the second bullet of section 3.2.1 will still have problems. > >> -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) iEYEARECAAYFAk1hXTQACgkQ9RoMZyVa61fFxgCfeCH/W0/Fljeh6Z8VKQsypbim U2UAniOnZDWZkLSJnZqGiD7AAMFMwrfU =WNCK -----END PGP SIGNATURE----- _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
