Hello,

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like any other last call comments.


After having read the security section and several parts of the
document, I have noticed several small, easy to fix, incoherencies.
More precisely:

** 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.

** 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.

** Section 9 says:
        "The server SHOULD then only respond to Echo
         Request messages that have a valid Session ID associated with the
         source IP address of the Echo Request."
   How should the server behave if the Session ID is not valid?
   This is not clarified whereas this is a critical aspect.

** 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.

** 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.

** 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.

** Section 3.3:
   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.

** 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."

** Section 5, "Server Behaviour", says:
        "When the server receives an Echo Request message, it may first check
         that the group address and Session ID (if provided) are valid."
   This is a "MUST"!!! If the Session ID is used, the server has no
   choice but checking it during the first processing stages.

** Section 5: should -> SHOULD in:
        "The server should additionally include a Session ID."

** Section 3.2 "Defined options"
   I didn't find any information for the Session ID format.
   Is there any recommendation? Is a 16-bit or 32-bit field
   format recommended? Why?

** Section 5 says:
        "Note that the server may receive Echo Request messages with no prior
         Init message.  This may happen when the server restarts or if a
         client sends an Echo Request with no prior Init message.  The server
         may go ahead and respond if it is okay with the group used.  If the
         group is not okay, the server sends back a Server Response."

   This "may go ahead and respond" is in total contradiction with 
   the security recommendations. Using a Session ID is a "SHOULD", and
   it is allowed to ignore this recommendation only in rare circumstances.
   A few ping requests may fail if the server is restarted, sure, but
   this will only be a transitory problem, so it's not a big deal. 

   I'm also wondering if the "sends back a Server Response" strategy is
   appropriate. With this "Response", an attacker that spoofs the IP address
   of a target has a way to oblige a server to send back a UDP packet to
   the target. It's questionable.


Regards,

  Vincent