Subject: [P2PSIP] Review comments: draft-bryan-p2psip-reload-03.txt

From: "Willekens, Marc (EXT-Other - BE/Herentals)" <[email-masked]>
Date: Thu, 6 Mar 2008 17:28:14 +0100

Some comments and remarks to
http://www.ietf.org/internet-drafts/draft-bryan-p2psip-reload-03.txt <http://www.ietf.org/internet-drafts/draft-bryan-p2psip-reload-03.txt> 

page8: Figure
HIP transport protocol is not indicated in the picture
 
page10: Security
Information about the P2P overlay network is also obtained from the enrollment server. As soon as users have obtained the XML configuration file from the central server after authentication and authorization, the obtained file can be misued by that users or by others. What mechanisms are provided to avoid this? How is e.g. a Dos attack to the indicated bootstrap servers avoided? I hope the XML file is also stored in an encrypted way in the peer node.
 
page12: User
Can a user only be a human being or is a machine also supported? Or is this excluded on purpose?
 
page15: symmetric/asymmetric
Is it also not possible to have something in between, something as pseudo-symmetric where optimization along the return path can be used?
And why do we have to differentiate between symmetric and asymmetric? Is it not just about forward and backward routing. When the receiver knows and can address the sender directly, why should it then do the symmetric routing?
 
page15: store, fetch, remove
Somewhere in the document, it is indicated as being an "instance" of put, get, detele. But what is special about that instance? 
 
page17
... can process STORE/FETCH request. I assume a full member can also do REMOVE/FIND requests. What methods are provided for "clients"? Can they also do a STORE and REMOVE or are there actions limited to a FIND/FETCH?
 
page17, §3.2
...Looking at the peer-id "in the destination list" that represents ....
 
page29
Route List Length - > Destination List Length
 
page30
Version:  7 or a 8 bit field?
Message Length: including the "complete forwarding" header?
Peer-id lengths: Maybe better to avoid a length field for
a) security reasons: better to obtain this information from the XML file obtained from the enrollment server
b) compact forwarding header structure
 
page33, §4.1.2.2
... the first entry on the "request" via list.
 
page35
Via list: Is it not better to call this a '"From" list because its not the own node which is stored but the node where the message came from.
So, instead of Via List and Destination List, is it not better to talk about "From" and "To" list?
 
page38, §4.2
transaction id in the common header? Is this not a field of the forwarding header?
 
page38, §4.2.1
Message code: 16 bit (17 bit in the picture)/
Is it not better to make 0 and 1 reserved and starting the Request as an Even value so that responses are always odd to align it with the odd error response code 0xFFFF.
Instead of assigning different numbers in the IANA for Requests and Responses, it's also possible to define a response bit in the lower order bit of the message code field.
 
page39, §4.2.2
.....indicating the "byte" length
 
page41
Can you explain the signing of the message. Is the message content in the figure the RELOAD common header+payload part?
 
page43
Should the Reason Phrase not be definied as an optional (verbose) parameter and the error code as a mandatory parameter?
 
page43, §5
Every 3 s, request up to 5 times.
Should we go for a linear or logarithmic scale, e.g. 3s, 4.5s, 7.5s; 12s? 
 
page47, §7.1.1.2
Does the response id has a relation with the node id?.
 
page48
type identifier: leading 16 bits??? or leading 8 bits.
 
page75, §8.10
Are these keepalive message not too much burden on the p2p overlay network? Periodic messages every 30 s for the peers behind a NAT and for the peers in the public internet providing the STUN service.
 
page76, §9
What about unstructured algorithms which was part of the p2pp? Is this planned for the next version of the draft?
 
page109
Message codes: make the distinction between _Q and _A with the least significant bit in the message code.
 
page110
What exactly is taken over from the p2pp? There are already p2pp implementations and it could help them to figure out how Reload is related to it.
 
br,
Marc.
_______________________________________________
P2PSIP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2psip

---

From: jiangxingfeng 36340 <[email-masked]>
Date: Thu, 06 Mar 2008 11:44:25 -0500

>Is it also not possible to have something in between, something as pseudo-symmetric where >optimization along the return path can be used?
>And why do we have to differentiate between symmetric and asymmetric? Is it not just about >forward and backward routing. When the receiver knows and can address the sender directly, >why should it then do the symmetric routing?

It is also my concern. If the source peer is on the public Internet, the response could be easily returned. In case the source peer is behind NAT, Relaying peer proposed by SEP could be used to send the response with fewer hops. The relaying peer is like what a HIP relay does. 

page8: Figure
 
page10: Security
 
page12: User

 
page17
 
page17, §3.2
 
page29
 
page30
 
page33, §4.1.2.2
 
page35
 
page38, §4.2
 
page38, §4.2.1
 
page39, §4.2.2
 
page41
 
page43
 
page43, §5
 
page47, §7.1.1.2
 
page48
 
page75, §8.10
 
page76, §9
 
page109
 
page110
 
br,
Marc.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 06 Mar 2008 08:55:14 -0800

Marc,

Thanks for your detailed comments.

At Thu, 6 Mar 2008 17:28:14 +0100,
> HIP transport protocol is not indicated in the picture

Good point. We kinda ran out of room :)

> page10: Security Information about the P2P overlay network is also
> obtained from the enrollment server. As soon as users have obtained
> the XML configuration file from the central server after
> authentication and authorization, the obtained file can be misued by
> that users or by others. What mechanisms are provided to avoid this?
> How is e.g. a Dos attack to the indicated bootstrap servers avoided?
> I hope the XML file is also stored in an encrypted way in the peer
> node.

Well, the bootstrap peers aren't secret, so basically you don't need
the configuration document to mount a DoS attack. We don't think of this
info as secret.

> is this excluded on purpose?

I think this is just a terminological thing. We think of a machine
user as just an automatic peer.

> Is it also not possible to have something in between, something as
> pseudo-symmetric where optimization along the return path can be
> used?  And why do we have to differentiate between symmetric and
> asymmetric? Is it not just about forward and backward routing. When
> the receiver knows and can address the sender directly, why should
> it then do the symmetric routing?

There have been a lot of discussions of the different routing
modes, so I think this is a bunch of good questions we should
discuss in PHL.

> Somewhere in the document, it is indicated as being an "instance" of put, get, detele. But what is special about that instance? 

Sorry, I don't recognize the section you're talking about here.

> page17
> ... can process STORE/FETCH request. I assume a full member can also
> do REMOVE/FIND requests. What methods are provided for "clients"?
> Can they also do a STORE and REMOVE or are there actions limited to
> a FIND/FETCH?

Oh, the pain of the terrible writing in this section. Yes, it can
process all the other requests. Clients too. The only thing clients
can't do is JOIN and send UPDATE (?), because that would make them
peers.

> Route List Length - > Destination List Length

Good catches.

> Version:  7 or a 8 bit field?

Version skew. 8.

> Message Length: including the "complete forwarding" header?

That's the idea. Not saying this is the most aesthetic approach.

> b) compact forwarding header structure

peer-id lengths are fixed for any overlay. The resource and
compressed forms have to be variable length, though.

> So, instead of Via List and Destination List, is it not better to talk about "From" and "To" list?

We've had horrible fights over this terminology, so I'm happy to do whatever
the WG likes here.

> transaction id in the common header? Is this not a field of the forwarding header?

Good catch.

> Message code: 16 bit (17 bit in the picture)/

Should be 16 bits.

> Is it not better to make 0 and 1 reserved and starting the Request
> as an Even value so that responses are always odd to align it with
> the odd error response code 0xFFFF.  Instead of assigning different
> numbers in the IANA for Requests and Responses, it's also possible
> to define a response bit in the lower order bit of the message code
> field.

This was a last minute addition, so I'm not wedded to any particular
layout. I kind of feel like I could make arguments for all of them :)

> .....indicating the "byte" length

Right.

> page41
> Can you explain the signing of the message. Is the message content
> in the figure the RELOAD common header+payload part?

Just the blocks in the "message_signature_input" diagram.

> page43
> Should the Reason Phrase not be definied as an optional (verbose)
> parameter and the error code as a mandatory parameter?

The way you do optional is a zero-length phrase.

> Should we go for a linear or logarithmic scale, e.g. 3s, 4.5s, 7.5s; 12s? 

quite possibly. I'm desperately hoping someone from TSV will tell 
us what this should say.

> Does the response id has a relation with the node id?.

No, it's just random bits.

> type identifier: leading 16 bits??? or leading 8 bits.

Doh! diagram error. Thanks for catching that.

> page75, §8.10
> Are these keepalive message not too much burden on the p2p overlay
> network? Periodic messages every 30 s for the peers behind a NAT and
> for the peers in the public internet providing the STUN service.

Good question. We derived these from what we understand NATs
require. We'd be happy to loosen them if it can be demonstrated
that that's safe...

> What about unstructured algorithms which was part of the p2pp? Is this planned for the next version of the draft?

We'd prefer to focus on structured for now, since it seems more in
line with the general focus of the WG. We'd welcome another draft
that described unstructured...

> What exactly is taken over from the p2pp? There are already p2pp implementations and it could help them to figure out how Reload is related to it.

There's been a bunch of discussion of this on the list already. Look
back for messages from Bruce and Salman.

Best,
-Ekr