Other comments on draft-ietf-rserpool-enrp-13

Hi,

In addition to the more major points in the other mail I do have some 
other comments also. Some may actually be classified as at least 
significant.

1. Section 1.1:
PEs are also allowed to multicast on this channel
       occasionally;

I think this sentence can be clarified. "occasionally" does not seem to 
be the right explanation here. Either remove or clarify what function 
the PE uses the channel for.

2. Section 1.1:
"All ENRP servers in an operational
       scope can send multicast messages to other servers through this
       channel."

This is an example where more explicitness could help. "other server" 
should be changed to "other ENRP servers". This is not 100% clear as 
there exist other entities that uses the channel. I think this is 
something in general to think of.

3. Section 2, second paragraph:
"The TLV parameters are also defined in [11]."

Changing the formulation to indicate that X number of parameters used in 
ENRP are defined in [11] would be better and less unclear.

4. Reference style: Since a while back there has a been a recommendation 
to switch from numeric references to labels, like [common] instead of 
[11]. The main advantages are that it avoids renumbering problems and 
makes it easier when writing RFC editor notes. It can also be easier to 
read as the references will be more self explaining.

5. Section 2.1, section 3.2.2.1, "reply_required":

I think this needs some more discussion as a security threat. When 
multicasted it can be used to introduce a DDos attack of the potential 
spoofed source of the packet. It also is a risk for congestion.

6. Rate control of multicast messages. There is need to provide some 
limit to how much messages are sent over the multicast channel.

7. The use of "receiver" in this specification. There exist several 
places (I think) like that in Section 2.1 and 2.2, where the target or 
destination of a request is called "receiver". I would propose changing 
this usage to be clearer. This is especially true for the messages that 
can be multicasted. This may also be considered for "sender" that in 
most case would be better to call the "source" of the requests.

8. Server ID and its handling in case of collision. I think one should 
describe what to do when a collision happens and what the result of such 
a collision is.

9. Section 2.3, why is "Reject" not an error message instead of a 
response message?

10. Section 5.1, how does one authenticate the multicasted request 
messages?

11. What transport protocol is used when sending the multicast messages?

12. Section 3.2.3:

    In the case where its ENRP_HANDLE_TABLE_REQUEST is rejected by the
    mentor peer, the initiating server SHOULD either wait for a few
    seconds and re-send the ENRP_HANDLE_TABLE_REQUEST to the mentor
    server, or if there is a backup mentor peer available, select another
    mentor peer server and send the ENRP_HANDLE_TABLE_REQUEST to the new
    mentor server.

Should one consider some exponential back off when trying to reach a server?

13. Section 3.8, last sentence. Why are there question marks around this 
reference. Please address.

14. Section 3.10.1: An editors note that should be resolved.

15. Section 5, Security consideration:

This section must become more readable. It is also seem to fail to 
consider security threats that is a result of the protocol instantiation 
itself rather than what the general problem space has. Like the risks 
with the multicast group used to find the servers. So, yes, I think 
there is need for a rewrite of this section.

I also think one might need to consider which solutions that will be 
mandatory independent on deployment and which needs to be implemented 
but possibly not used in certain deployments.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email protected]