Subject: Re: [P2PSIP] Multiple Node-IDs in certificate [was Re: draft-ietf-p2psip-base-12 (2)]

From: Bruce Lowekamp <[email-masked]>
Date: Fri, 4 Mar 2011 13:59:33 -0500

On Sun, Feb 27, 2011 at 9:54 PM, Marc Petit-Huguenin <[email-masked]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 02/27/2011 05:15 PM, Bruce Lowekamp wrote:
>> On Sun, Feb 20, 2011 at 1:28 PM, Marc Petit-Huguenin <[email-masked]> 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.  The only exception is initial bootstrapping (3.4).  Those
nodes don't send Update.

You're doing this because you have clients coded with the address of a
peer they should connect through?   I think it would still be better
to have them doing an attach, either by encoding the peer ID in the
same place they learn about the node from or using the ping mechanism
in 10.4, followed by an Attach.  (I think the draft is a little
unclear that any node receiving a message sent to the wildcard simply
responds to it)

Bruce

> - --
> Marc Petit-Huguenin
> Personal email: [email-masked]
> Professional email: [email-masked]
> Blog: http://blog.marc.petit-huguenin.org
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
>
> iEYEARECAAYFAk1rDlcACgkQ9RoMZyVa61dE/wCfadcwiQFAnaQuOGG6VxOphl+D
> Dk4AniSw21hHNXbDm/GM442x+nOB05Fe
> =6hrr
> -----END PGP SIGNATURE-----
>

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 04 Mar 2011 11:44:21 -0800

On 03/04/2011 10:59 AM, Bruce Lowekamp wrote:
>> an Attach.  

This is not what the second bullet of 3.2.1 says.

>> The only exception is initial bootstrapping (3.4).  Those
>> nodes don't send Update.
> 
>> peer they should connect through?   

No, I am writing an implementation that will cover 100% of the I-D.  It's in the
spec, so I am trying to implement it.  And I think that the mechanism in the
second bullet of 3.2.1 is elegant as it permits to not consider the first
connection of a new node as a special case, and so should not be removed from
the spec.

> I think it would still be better
>> in 10.4, followed by an Attach.(I think the draft is a little

Yes.  And in my opinion, a node MUST send a Ping with wildcard immediately after
any connection is established, so a client does not need to send an Attach.

- -- 
Marc Petit-Huguenin

---

From: Bruce Lowekamp <[email-masked]>
Date: Fri, 4 Mar 2011 15:38:32 -0500

> 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.

> connection of a new node as a special case, and so should not be removed from

Thanks for working on such a thorough implementation.  You are
definitely identifying numerous issues that people who did
implementations awhile ago wouldn't notice, and I appreciate your
insights into other possible solutions to some of the problems.

Thanks,
Bruce

> iEYEARECAAYFAk1xQRQACgkQ9RoMZyVa61c6dQCghEB2UkC7ygEs45PvMtx8WIup
> zVQAoKHRekHKpe8IzJnVoR21AgTsdgXI
> =JubW

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 04 Mar 2011 13:09:49 -0800

>> peer other than its responsible peer, rather than route the Attach to

"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