Subject: Re: [P2PSIP] draft-ietf-p2psip-base-12 (2)

From: Cullen Jennings <[email-masked]>
Date: Tue, 8 Feb 2011 16:51:04 -0700

On Jan 18, 2011, at 6:42 AM, Eric Rescorla wrote:

>> 
>> - - A.12. Section 10.3 states that "[t]he SubjectAltName field in the certificate
>> contains the following values: One or more Node-IDs...", but nowhere it is said
>> how to request multiple Node-IDs.  Is it an URL parameter of the POST request?
>> An attribute in the Certification Request object?
>> 
> 
> Good question. This is an issue that's simply not addressed in the draft., but presumably
> we'll need to do something like this, yeah. My taste would be for it to be a URL in the POSt.

It's not really defined in this draft how to have Certificates with multiple node-id. There are some arguments about if multiple node ids are useful or not - The goal here is just to make sure that option is left open if a future extension does this. A parameter on the post URL sounds like a good approach.

---

From: Bruce Lowekamp <[email-masked]>
Date: Tue, 8 Feb 2011 21:25:02 -0500

On Mon, Jan 10, 2011 at 5:44 PM, Marc Petit-Huguenin <[email-masked]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Thanks for your responses. see below for more comments.
>
> On 01/07/2011 02:24 PM, Bruce Lowekamp wrote:
>> inline
>>
>> On Mon, Nov 22, 2010 at 2:32 PM, Marc Petit-Huguenin <[email-masked]> wrote:
>> More questions, comments and nits:
>>
>
> [...]
>
>>
>> - A.10. It seems that this version of RELOAD lacks the support of virtual
>> servers (see draft-harjula-p2psip-loadbalancing-survey), more precisely a way to
>> share connections between two virtual servers on the same physical server (see
>> Frank Dabek, M. Frans Kaashoek, David Karger, Robert Morris, Ion Stoica,
>> Wide-area cooperative storage with CFS: "Use of virtual servers could
>> potentially increase the number of hops in a Chord lookup.  CFS avoids this
>> expense by allowing virtual servers on the same physical server to examine each
>> others' tables: the fact that these virtual servers can take short-cuts through
>> each others' routing table exactly compensates for the increases number of
>> servers.").  Because the certificates contains a list of Node-IDs, it is not
>> possible to know on a hop by hop basis what are the source and destination
>> NodeIds of a specific message.  Section 3 of
>> draft-rosenberg-dispatch-vipr-reload-usage seems to acknowledge that by adding a
>> PeerID Shim to exchange the source and destination peerIDs (aka Node-IDs).
>>
>> Because of this, it is probably a good idea to add in p2psip-base the
>> possibility to know the source Node-ID and destination Node-ID of a message.
>> One way to do that would have be to have the sender of a message add its own
>> Node-ID in the via_list, and the Node-ID of the destination in the
>> destination_list before sending a message (similar to what SIP is doing), but I
>> guess that it is too late for such a modification.
>>
>>
>>> I totally agree that vnodes should share routing state.  But it's not
>>> clear to me what benefit would be obtained by making that sort of a
>>> protocol change.
>>
>>> * on request routing, a message should normally have exactly one
>>> destination node-id.  The only reason to have more would be that the
>>> request sender has some particular reason to want to source-route the
>>> request.
>>> * on response sending, with recursive response you simply want to
>>> reverse the initial request routing.  If there was an advantage to
>>> "short-cutting" between v-nodes, it would have been done on the
>>> request routing.   If you're not doing recursive response routing,
>>> then this case is the same as request routing.
>
> Let's forget for now the solution I proposed.  Do you agree that Section 3 of
> draft-rosenberg-dispatch-vipr-reload-usage exposes a problem that would be worth
> been solved in p2psip-base?

I think we're merging two separate issues here:

- how do you differentiate the sender of an end-to-end-message
- how do you identify the multiple Node-IDs of an adjacent node

For the first, I think SignerIdentity is the logical place.  Using
hash_alg, certificate_hash, and Node-ID would be sufficient.

For adjacent nodes, I would rather encode it using an IceExtension in
the Attach sequence that's already flowing than use a shim approach,
particularly because it avoids issues with datagram protocols.

I have mixed feelings on whether either of these should be in the base
protocol.  I really think that SignerIdentity should handle that case.
 But I think the support for multiple NodeIDs over a connection adds a
lot of complexity and might be better as an extension.

Bruce

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 09 Feb 2011 08:44:21 -0800

> hash_alg, certificate_hash, and Node-ID would be sufficient.

I agree, with one caveat:  If the sender of the message is also an adjacent
node, and the extension described below is not implemented, then { hash_alg,
certificate_hash, Node-ID } does not permit to differentiate the sender if there
is multiple Node-IDs in the certificate.  This is because the Via is added by
the receiving node instead of the sending node.

> particularly because it avoids issues with datagram protocols.

OK.  I still think that having 1) each node adding the Via before sending
(instead of by the receiving node), 2) all nodes adding the next hop on top of
the destination_list before forwarding and 3) the receiving node dropping the
first node in the destination_list before applying the routing algorithm would
have been a better solution.

> lot of complexity and might be better as an extension.

Well, I am willing to write immediately the I-D for such extension (because my
implementation is using multiple Node-IDs per certificate), so let me know if
this is the way to go.

Thanks.

- -- 
Marc Petit-Huguenin
Personal email: [email-masked]
Professional email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org

---

From: Bruce Lowekamp <[email-masked]>
Date: Sun, 13 Feb 2011 20:04:02 -0500

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.

More comments inline

> the receiving node instead of the sending node.

Again, I think a new SignerIdentity would be sufficient for
identifying the originator of the message.  You're right that it
doesn't identify the virtual node acting in this case.

> have been a better solution.

This strikes me as a major change, but if you want to start a separate
thread on it, we could see if others feel the same way.  I think this
routing algorithm is only required if we want the property above.  No
objections to your defining a routing algorithm extension that has
this property, of course.

> implementation is using multiple Node-IDs per certificate), so let me know if

Probably best to start a separate thread, but I'd be happy to see a
draft proposing the IceExtension.

Bruce

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEARECAAYFAk1SxGMACgkQ9RoMZyVa61dG/QCcC1Kl6ELen4VzE3rJGgfl0F8R
> 5PIAoKeX3u87MSGiUpthSqnHY/Emvrhz
> =6AGB
> -----END PGP SIGNATURE-----
>

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sun, 13 Feb 2011 18:34:40 -0800

> can and should be accomplished through a new routing algorithm.

OK, fair enough.

> draft.  

OK, I'll write the I-D before the cut-off, and will implement it.

Thanks.

> But both should probably get a thread of their own so they
> have more eyes.
> 
> More comments inline
> 

- -- 
Marc Petit-Huguenin

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sat, 19 Feb 2011 15:53:37 -0800

> draft.  But both should probably get a thread of their own so they

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.

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

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

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 19 Feb 2011 18:09:11 -0800

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

> 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

> Version: GnuPG v1.4.11 (GNU/Linux)
> 
> iEYEARECAAYFAk1gWAAACgkQ9RoMZyVa61fFXwCfegOrqYADs9809eM+N0y5muMA
> gRUAn2x4ZThclCBYbEZ4aMMmrM4p+3PO
> =gCJY
> _______________________________________________
> P2PSIP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/p2psip

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sun, 20 Feb 2011 10:28:05 -0800

On 02/19/2011 06:09 PM, Eric Rescorla wrote:
> - If the message is a request and traversed at least one peer, then the sender
> - If the message is a request that was sent over a direct connection, then the
> - If the message is an answer, then the sender Node-ID is the same Node-ID that

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.

> - Because direct connections are established by Attach, the Node-ID of the

- -- 
Marc Petit-Huguenin

---

From: Bruce Lowekamp <[email-masked]>
Date: Sun, 27 Feb 2011 20:17:57 -0500

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

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

> iEYEARECAAYFAk1hXTQACgkQ9RoMZyVa61fFxgCfeCH/W0/Fljeh6Z8VKQsypbim
> U2UAniOnZDWZkLSJnZqGiD7AAMFMwrfU
> =WNCK

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sun, 27 Feb 2011 18:54:18 -0800

[...]

>> with that, since the peer would know the node-id that the node is

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.

- -- 
Marc Petit-Huguenin