Service Discovery Usage for REsource LOcation And Discovery (RELOAD)
draft-ietf-p2psip-service-discovery-15
Yes
(Alissa Cooper)
No Objection
(Brian Haberman)
(Joel Jaeggli)
(Martin Stiemerling)
(Pete Resnick)
(Richard Barnes)
Note: This ballot was opened for revision 14 and is now closed.
Alissa Cooper Former IESG member
Yes
Yes
(for -14)
Unknown
Spencer Dawkins Former IESG member
Yes
Yes
(2014-08-05 for -14)
Unknown
In this text appearing in 4.5. Service Lookups 1. If there is no successor of node n present in the just fetched ReDiR tree node (note: within the entire tree node and not only within the current interval) responsible for I(level,n.id), then the successor of node n must be present in a larger segment of the identifier space (i.e., further up in the ReDiR tree where each interval and tree node covers a larger range of the identifier space). Therefore, node n MUST reduce the current level by one to level=level-1 and carry out a new Fetch operation for the tree node responsible for n.id at that level. The fetched tree node is then analyzed and the next action determined by checking conditions 1-3. I'm guessing that "conditions 1-3" mean "this paragraph and the two following", but I'm guessing. If I'm guessing right, I wish that could be clearer ... perhaps it would help to label the three conditions as "Condition 1/2/3"? In this text appearing in 4.6. Removing Registrations Before leaving the RELOAD Overlay Instance, a service provider MUST remove the RedirServiceProvider records it has stored by storing exists=False values in their place, as described in [RFC6940]. Am I remembering that these records are soft state and will time out and be removed eventually anyway? If I'm remembering correctly, I'm wondering if this needs to be a MUST, or if it's just good advice.
Adrian Farrel Former IESG member
No Objection
No Objection
(2014-08-05 for -14)
Unknown
I was surprised that I could follow all of this document. Good job by the authors! I have no objection to its publication, but I note a couple of points below that I think could improve the document. I shouldn't be surprised if the Security ADs pounce on something similar to the last point. --- The scaling problem described in Section 1 is real in as much as it is clearly a problem that deteriorates in a linear fashion with the number of services. Furthermore, the problem worsens in the product of the number of services and the number of nodes making discovery requests. This is all as described in the text. What is missing, however, is an explanaiton of why this is perceived to be a problem that needs to be solved. For example, if there is only ever going to be one service provided by one server, and only five nodes requesting the service then clearly nothing sophisticated is needed. The text in this section calls out four example services which suggests to the naif reader that growth to twelve service types might not be unreasonable. No clue is given as to the size of the cohort requesting discovery, nor to the multiplicity of service-providing nodes. It might, therefore, be interesting to enhance this section with some clues about current expectations of scaling requirements and also with an observation that we usually under-estimate scaling requirements in the Internet. --- If this document uses terminology from [I-D.ietf-p2psip-concepts], don't I need to read that document to understand this one? If so, that makes it a normative reference. --- In Section 4.5 the following text was slightly confusing... The fetched tree node is then analyzed and the next action determined by checking conditions 1-3. ...because (I think) this text is embedded in condition 1 of the 3 conditions. Perhaps "...by checking the three conditions set out here" or even "...MUST determine the next action by starting to check the conditions listed here starting at condition 1." Or maybe I was just confused and the text is OK :-) --- Why are there no security considerations? You are using existing (securable) protocol mechanisms to achieve a new function. Attacks on service discovery are likely to have "interesting" effects either denying services or redirecting traffic requesting a service to a false server. That means that you have defined some new threats (including, I think, the fact that requesting service discovery reveals a certain amount of information about the requester). Surely you need to describe these threats and explain how existing security mechanisms in the protocol are adequate protection.
Barry Leiba Former IESG member
(was Discuss)
No Objection
No Objection
(2014-08-14)
Unknown
Version -15 addresses my comments, and thanks for discussing them with me.
Brian Haberman Former IESG member
No Objection
No Objection
(for -14)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(2014-08-06 for -14)
Unknown
Nice read. Thanks.
Joel Jaeggli Former IESG member
No Objection
No Objection
(for -14)
Unknown
Kathleen Moriarty Former IESG member
No Objection
No Objection
(2014-08-07 for -14)
Unknown
Please Address the concerns pointed out in the SecDir Review: http://www.ietf.org/mail-archive/web/secdir/current/msg04958.html
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -14)
Unknown
Pete Resnick Former IESG member
No Objection
No Objection
(for -14)
Unknown
Richard Barnes Former IESG member
No Objection
No Objection
(for -14)
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(2014-08-07 for -14)
Unknown
- 4.3 step 5 - this implies that anyone can rewrite the Redir information for anyone else. Is that right? If so, why is that ok? I do see section 5, but I didn't get how that really works - can you explain? (To someone who's forgotten RELOAD mostly;-) - ISTM that the first sentence of section 9 is contradicted by the 2nd paragraph of section 9. I'd say just delete the first sentence there. (As noted by others.) - WRT the secdir review, I'm not sure SHA-1 is ok for the access control policy - can you explain why it is? (If we assume SHA-1 is broken for collisions.)
Ted Lemon Former IESG member
No Objection
No Objection
(2014-08-07 for -14)
Unknown
Since RedirServiceProvider records are expiring and registrations are being refreshed periodically, there can be certain rare situations in which a service lookup may fail even if there is a valid successor present in the ReDiR tree. An example is a case in which a ReDiR tree node is fetched just after a RedirServiceProvider entry of the only successor of k present in the tree node has expired and just before a Store request that has been sent to refresh the entry reaches the peer storing the tree node. In this rather unlikely scenario, the successor that should have been present in the tree node is temporarily missing. Thus, the service lookup will fail and needs to be carried out again. Why not just require that the node registering a service update its entry in the service table at some fraction of the expiry time, rather than after it has expired or when it expires? E.g., 90%, or 50%, or something like that.