On Sun, Feb 20, 2011 at 1:28 PM, Marc Petit-Huguenin <[email protected]> wrote: > -----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. >
I think the IceExtension would be needed for connection sharing, so since you said you're setting that aside for now, I agree. > 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. > Assuming the Attach is using SignerIdentity, I don't see any problems with that, since the peer would know the node-id that the node is using. >> >>> -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
