-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 03/04/2011 12:38 PM, Bruce Lowekamp wrote:
> On Fri, Mar 4, 2011 at 2:44 PM, Marc Petit-Huguenin <[email protected]> wrote:
> On 03/04/2011 10:59 AM, Bruce Lowekamp wrote:
>>>> On Sun, Feb 27, 2011 at 9:54 PM, Marc Petit-Huguenin <[email protected]>
>>>> wrote:
>>>> On 02/27/2011 05:15 PM, Bruce Lowekamp wrote:
>>>>>>> On Sun, Feb 20, 2011 at 1:28 PM, Marc Petit-Huguenin <[email protected]>
>>>>>>> wrote:
>>>>
>>>> [...]
>>>>
>>>>>>>
>>>>>>> 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.
>>>>
>>>> Clients that are using the mechanism described in the last paragraph of
>>>> section
>>>> 3.2.1 do not send Attach, so a peer would have to spy on the first message
>>>> coming from the connection of this client to extract the Node-ID from the
>>>> SignerIdentity and be able to add the connection to the connection table.
>>>>
>>>>
>>>>> I believe the intention has always been that all node connections use
>>>>> an Attach.
>
> This is not what the second bullet of 3.2.1 says.
>
>
>> Marc,
>
>> I'm sorry, but can you quote the text you're referring to? I don't
>> see the word "Attach" in that bullet. You're looking at -12? I like
>> this feature too, but it's intended to allow a client to Attach to a
>> peer other than its responsible peer, rather than route the Attach to
>> its responsible peer.
"Clients may insert themselves in the overlay in two ways:
[...]
o Establish a connection with an arbitrary peer in the overlay
(perhaps based on network proximity or an inability to establish a
direct connection with the responsible peer). In this case, the
client will rely on RELOAD's Destination List feature to ensure
reachability. The client can initiate requests, and any node in
the overlay that knows the Destination List to its current
location can reach it, but the client is not directly reachable
using only its Node-ID. If the client is to receive incoming
requests from other members of the overlay, the Destination List
required to reach it must be learnable via other mechanisms, such
as being stored in the overlay by a usage."
The word "Attach" is not in this, because it is not used, which is my point.
Because there is no Attach, the peer has to spy on the first message sent by the
client to extract the Node-ID from the SignerIdentity and "label" the newly
created connection in the connection table. Having the client send a wildcard
Ping immediately after the connection permits to immediately retrieve the
Node-ID and label the connection.
Note that I am not saying that it is the right way to fix it - IMO the right way
to fix this would be to add an extension in (D)TLS to carry the selected Node-ID
in both direction (another solution - not as good as the TLS extension - is to
carry it in the FramedMessage. I currently use the initial sequence value as an
index in the SubjectAltName list, which has the advantage of been compatible
with the current version of the Wireshark dissector, that I cannot update until
I see how the SignerIdentity will be modified).
- --
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)
iEYEARECAAYFAk1xVRsACgkQ9RoMZyVa61fy+QCeI+Ph8drpZLzOYRUrmkRYWVS+
+aEAnRhriRfitVj7Fplt9R1Iuq5n8ogI
=rD51
-----END PGP SIGNATURE-----
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
