REsource LOcation And Discovery (RELOAD) Base Protocol
RFC 6940

Note: This ballot was opened for revision 20 and is now closed.

(Peter Saint-Andre) Discuss

Discuss (2012-01-17 for -)
[UPDATED based on -20.]

I'd like to talk about several points that I haven't seen mentioned in
other reviews.

1. Section 1.3 appears to couple issuance of certificates and assignment
of Node-IDs (in most cases):

   RELOAD's security model is based on each node having one or more
   public key certificates.  In general, these certificates will be
   assigned by a central server which also assigns Node-IDs, although
   self-signed certificates can be used in closed networks.

What is the reason for this coupling? Does it have security
implications? At the least, a forward reference to later sections
(e.g., 3.1) might help.

2. Does the use of list compression (Section 5.1.2) and private IDs
(Section 5.1.3) prevent an intermediate node from routing return messages
if its neighbor goes offline? In your example, if E has a destination
list of (D, I) but D goes offline, then E won't be able to unpack the
private ID "I" to recover the via list "(A, B, C)".

3. In Section 10.1, the format of the 'expiration' attribute is not
fully specified (e.g., are timezone offsets allowed or must the datetime
be UTC?). UPDATE: I'm sorry if my comment was unclear, but I think
it would be good to cite RFC 3339 here; when doing so, please make 
sure that you document all the details about various options, such as 
use of non-UTC time zones and fractional seconds.

4. Addressed in -20.

5. Addressed in -20.
Comment (2011-09-07 for -)
No email
send info
1. Regarding communication security, Section 1.3 states:

   Message Level:    Each RELOAD message must be signed.
   Object Level:    Stored objects must be signed by the creating peer.

Did you mean "MUST" instead of "must"?

2. In Section 3.1.1, please provide references for TLS-PSK and TLS-SRP.

3. In Section 3.2.1, please provide a reference for TURN.

4. In Section 3.2.1, forward references would help for Attach (Section
5.1.1), Ping (5.5.3), Destination List (5.3.2.2), etc.

5. Section 3.2.2 mentions "the topology plugin required to act as a
peer in the overlay"; does this assume a plugin architecture for Node
implementations? Perhaps not, because in Section 5.4 the spec talks
about a "Topology Plugin" in a more generic sense. It might be good to
clarify.

6. The description of symmetric recursive routing in Section 3.3 makes
me wonder whether messages themselves are stored at the nodes in the Via
list; if so, does that introduce possible concerns related to privacy,
security, and auditing?

7. Please expand "ICE" on first use (Section 1) and in Section 3.4.

8. Section 3.6.1 states that "the node does a DNS SRV lookup on the
overlay name to get the address of a configuration server"; a forward
reference to Section 10.2 would be appropriate here. Also, a reference
to RFC 2782 seems in order here.

9. Section 3.6.2 states that "the enrollment server's ability to
restrict attackers' access to certificates in the overlay is one of
the cornerstones of RELOAD's security"; by "access" seems to be meant
"privilege to be granted its own certificate", not "capacity to know the
certificates of other nodes".

10. Section 4.1.1 states that "only a user with a certificate for
'alice@example.org' could write to that location in the overlay". At
least a forward reference to Section 10.3 would help, which is the only
place where the user name is a define as an rfc822Name (at least in the
certificate). Furthermore, it would help to more clearly specify how
a user name prepared and compared for authorization purposes.

11. In Section 5.1, what exactly does it mean for a peer to "pass a
message up to the upper layers"?

12. Is there a reason why the end-to-end reliability mechanism in
Section 5.2.1 doesn't recommend exponential backoff on retries?

13. Section 5.3.2 states that "transaction IDs ... MUST be randomly
generated"; perhaps a reference to RFC 4086 is in order?

14. In Section 5.3.3.1, it would be good to state whether the
"error_info" text is intended to be presented to users (if so, we might
need language tagging).

15. In Section 5.3.4, what exactly is "the identity used to form the
signature"? It appears to be a Node-ID (or a hash thereof), but it would
be good to make that clear in the definition (e.g., could it also be a
Resource-ID)?

16. In Section 5.5.1.1, are "srflx", "prflx", and "relay" as defined for
Candidate Types in ICE? The "type" is said to "correspond to the
cand-type production" but it might help to point a bit more directly to
RFC 5245.

17. Section 6.4.1.3 mentions previous versions of RELOAD. Given that no
references are provided, is that mention helpful?

18. The <self-signed-permitted/> element is of type xsd:boolean; please
note that this datatype has two lexical representations, "1" or "true"
for the concept true and "0" or "false" for the concept false. You might
want to point this out to implementers. The same applies to the other
elements with a datatype of xsd:boolean (no-ice, clients-permitted,
etc.).

19. Section 10.1 does not clearly specify which elements and attributes
are required and which are optional. Is it assumed that the reader needs
to refer to the schema for this information?

20. In Section 12.3, it might be worthwhile to mention the possibility
of attacks against the central enrollment authority.

21. In Section 13.6, it's still not clear what it means for an XML
format to be binary-encoded. I think this needs to be more clearly
specified, then the registration can reference the appropriate section
of the spec.

(Gonzalo Camarillo) Yes

(Stephen Farrell) (was No Objection, Discuss) Yes

Comment (2013-02-15 for -24)
No email
send info
Thanks again for handling my gigantic discuss/comments last
time around.

I had a (not so quick:-) check of the diffs between -18 and
-24 and all seems well, but I do have one question: is the
overlay-reliability-timer in the configuration defined in 11.1
supposed to override the "15 second" timer ("Maximum Request
Lifetime") defined in section 2 and and used in various
places, if the value of the overlay-reliability-timer is more
than 15000? 

If so, then it might be worth yet another pass over this to
check that all the hard-coded time values (and there are a few
in both seconds and ms) are in whack with that configuration
element. 

If not, then it might be worth saying that these are different
and how, in 11.1 and/or section 2.

Or, maybe I didn't read enough and that's a dumb question, in
which case, sorry about that.

And lastly, since I do DTN stuff now and then I'm really
curious as to what might happen if I wanted to set the
overlay-reliability-timer to 86400000 (one day). But I don't
expect you to give an answer or do anything about that:-)

(Jari Arkko) (was Discuss) No Objection

(Ron Bonica) No Objection

(Stewart Bryant) (was Discuss) No Objection

Comment (2013-01-28 for -24)
No email
send info
This is a well written document, and is much improved over the last version that I read. I thank the editors for the work that they have done.

I understand that the example using port "6100" is an error and will be corrected in the next version to the assigned port.

I am therefore clearing with the request that the shepherding AD verifies this change.

(Ralph Droms) (was No Record, No Objection, Discuss) No Objection

(Wesley Eddy) (was Discuss) No Objection

Comment (2012-07-23 for -22)
No email
send info
- The document seems to be schizophrenic about Head of Line blocking.  The section 6.5.1.6 text on why TCP is not a desirable Overlay Link Protocol notes Head of Line blocking as the primary reason to prefer another protocol, yet the stop and wait algorithm in 6.6.3.1 for use over DTLS, says that only one message can be unacknowledged at a time, so it's unclear how this avoid Head of Line blocking issues (if at all).  It seems like you seay HoL issues are worth avoiding, and then define operation only over transports with HoL issues (TCP and the DTLS-based ones).

(Adrian Farrel) (was Discuss) No Objection

Comment (2013-02-19 for -24)
No email
send info
Thanks for addressing my Discuss and all my Comments.

(Russ Housley) (was Discuss) No Objection

(Pete Resnick) No Objection

Comment (2013-02-15 for -24)
No email
send info
Note: Gonzalo didn't reset the ballot, so I am assuming that there's no need to do a full re-review. So I checked on my comments that I had in earlier. Only two outstanding:

6.3.4 - No discussion of wildcard in this section. Does there need to be?

6.5 - Not clear to me why this document settles on ICE (or anything lower layer). Seems like it could have been abstracted out and left to a different layer. I'm kind of disappointed that all of section 6.5 (and maybe sections 6.6 and 9) is not a separate document. (I understand that this is the WG wanted to do it. Just registering my complaint, but I won't make a fuss.)

(Dan Romascanu) (was Discuss) No Objection

(Robert Sparks) (was Discuss) No Objection

Comment (2011-09-07 for -22)
No email
send info
Page 38 - Section 5.2.1 - might be worth calling out that the sending node will be doing both e2e and hopbyhop retransmissions

Page 48 - Section 5.3.3 - should note 0x8000-0xfffe are reserved

Page 82 - Section 6 - Can you find a different word than "unpartitioning" (or define it)? - it only occurs once in the document.

Page 107 - the formula at the end of 9.5 has unbalanced parentheses

Page 112 - In the implementer note in 9.7.4.3, can you point to references to get the implementer started?

(Martin Stiemerling) No Objection

(Sean Turner) No Objection

Comment (2011-09-08 for -)
No email
send info
Nothing like getting to your review after there's already 8 lengthy discusses on it.  I'll not be adding anything new (and possibly avoiding the record for total number and length of discusses) - everything I noted somebody else caught.  I'll pop some popcorn and watch p2psip-base vs IESG form the cheap seats.