Multicast Ping Protocol
RFC 6450

Thank you for addressing my Discuss and Comments

I support Wesley's DISCUSS. The one second interval between answers of a server to a given client may be too little, just fine or too much depending on many factors, size and topology of the network included. Either some justification or some other indication of how this value is to be used (or deviated from) is required. 

I concur with Sean Turner's DISCUSS. Regarding denial of service attacks, reference to RFC 4732 would be helpful (both to formulate appropriate text and for completeness of the references).

This is an update comment based on Vincent's SECDIR review (http://www.ietf.org/mail-archive/web/secdir/current/msg02772.html).

#1) Section 3.2 (Server Info, type 6):

1.1) r/Support for this option is optional./Support for this option is OPTIONAL.

1.2) Need a normative reference to UTF-8.

#2) Section 6, If these are really recommendations shouldn't the text be tweaked to use the phrases like "It is RECOMMENDED that ..." Technically, there's no 2119 language in the section.

#3) Section 8, unless you're trying to redefine the meaning of the following: "Message types 0-191 require specification (an RFC or other permanent and readily available reference)," replace it with "Message type 0-191 are registered following the procedures for Specification Required from [RFC5226]," and add a normative reference to RFC 5226 (which is where specification required is defined). X2

#4) Section 8, I think this ought to be a MUST:

   An option specification must describe how
   the option may be used with the known message types.

#5) Section 3.2, Is there a recommendation for the Session ID format?  Maybe a 16-bit or 32-bit field should be recommended?

#6) Section 3.4, When describing the format of the "Server Response, type 83", there should be a note that a Session ID option SHOULD be included, since this is the only way for a server to communicate this option.

#7) Section 4, "Client behaviour": must -> MUST in:

   If the Server Response contained a Session ID, then it
   must also include that, with the exact same value, in the Echo
   Requests.

#8) Section 5: should -> SHOULD in:

   The server should additionally include a Session ID.

#9) Section 9 says:
        "The worst case is if the host receiving the unicast Echo Replies also
         happens to be joined to the multicast group used."

   Yes in case of an ASM session, no in case of an SSM session
   (unless the server is also the SSM source, of course). This should
   be clarified.

#10) Section 9 says:

        "...responding to at most one Echo Request per second."

   It should be clarified that this is one response per second per client.
   BTW, I'm also wondering if there should not be a global rate limitation,
   in addition to the per-client rate limitation.

#11) Section 9 says:

   Rather than saying "how spoofing can be prevented", I'd rather
   say "how spoofing can be mitigated" since spoofing is NOT
   prevented with this approach.

   Note also that an attacker that is on the path between a client
   and a server may eavesdrop the traffic, learn a valid Session ID,
   and if he can use spoofing, he can also continue generating Echo
   Requests until the Session ID validity period times out... A note
   may be added to clarify that this is by no means a definite security
   mechanism.

#12) Section 9, 2nd paragraph:

   It's clear that group management is critical with ASM, and that
   the multicast IP address range used for multicast ping SHOULD be
   disjoint from those used for data sessions. There is no clear
   recommendation though. I suggest to add some text here.

#13) Section 9 says:

        "The main concern is bandwidth."

   Is it really "the main concern"? I'm not sure. Disturbing an ASM
   data session with Echo Response traffic (when feasible) is a serious
   concern, since Echo Response traffic may be misinterpreted by the
   receivers.

This sets up a sort-of covert channel between the
client sending the Init and the MC group members 
that could be used e.g. in botnet control. (I've no
idea if that's actually happened or not.)

I don't know what might be done about that right now, but
having the server just send a hash of the client supplied 
options should work, but would be a fairly large change 
to the protocol at this stage.

I guess it might be worth noting this potential abuse
and possible solution in case the protocol is revised later.