Multicast Ping Protocol
RFC 6450

[Ballot discuss]
The Gen-ART Review by Suresh Krishnan on 12-Jul 2011 raised two
  concerns that deserve a response.

  * I am not sure why this spec needs to contain the options 7 and 8
    as they are not relevant to this version of the protocol. Wouldn't
    the default behavior with unknown options take care of this
    automatically?

  * It would be good if the draft specifies a default TTL (e.g. 64) in
    case the server did not include a TTL option. In this case, the
    server implementations need not bother to add the option if they
    are happy with the default (which I suspect they would be).

[Ballot comment]
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.

[Ballot comment]
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 devaited from) is required.

[Ballot comment]
I am slightly puzzled by the author's contact details. Are they
up-to-date and will the email address reach the author in AUTH48?

---

I think it would help, very early in Section 2, to say that the Server
is typically the root of a multicast tree, and the Client is typically
the leaf. You could go on to explain variations from this.

---

Section 3

  The Init message generally contains some prefix options asking the
  server for a group from one of the specified prefixes.

  For an Echo Request the client generally includes a number of
  options

These are pretty vague statements for a protocol specification!

[Ballot discuss]
The mboned charter says:
  This is not meant to be a protocol development Working Group.

Is this not a protocol? In which other WGs has it been reviewed? (The
write-up is silent)

---

idnits says...

  == You're using the IETF Trust Provisions' Section 6.b License Notice
    from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009.
    (See http://trustee.ietf.org/license-info/)

I think we need the draft to be resubmitted with the up-to-date
license notice before we can accept it for publication.

---

The Experimental ranges available here are far too large. There are 64
experimental message types and 16384 experimental option types.
Experiments are supposed to have limited scope and duration. Such large
experimental ranges will encourage code-point squatting. Please reduce
the available range to one or two messages and no more than six options.

---

Section 3.2

  Values 7 and 8 are reserved.

You need to be more careful. I suspect that you mean "reserved and must
not be allocated by any future document."  If you just say "reserved"
this may be mistaken for "available".

But anyway, the text later in 3.2 is confusing:

      Reserved, type 7

        This option code value was used by early implementations for an
        option that is now deprecated.  This option should no longer be
        used.  Clients MUST NOT use this option.  Servers MUST treat it
        as an unknown option (not process it if received, but if
        received in an Echo Request message, it MUST be echoed in the
        Echo Reply message).

You say "deprecated" but you asked for the code point to be "reserved".

This says both "should (sic) no longer be used" and MUST NOT be used by
a client. Then it goes on to say that that MUST NOT is not an error and
MUST be processed by the server. 

I suggest:

        This option code value was used by implementations of version 1
        of this protocol, and is not used in this version. Servers MUST
        treat it as an unknown option (not process it if received, but
        if received in an Echo Request message, it MUST be echoed in
        the Echo Reply message).

Similarly, I suggest:

      Reserved, type 8

        This option code value was used by implementations of version 1
        of this protocol, and is not used in this version. Servers MUST
        treat it as an unknown option (not process it if received, but
        if received in an Echo Request message, it MUST be echoed in
        the Echo Reply message).

---

Section 3.2

Client ID says...

        A server should treat
        this as opaque data, and MUST echo this option back in the
        reply if present (both Server Response and Echo Reply).
                       
But Version says...

        Client
        ID and Sequence Number options SHOULD be echoed if present

MUST != SHOULD

Similarly:
Sequence Number...

        A
        server replying to an Echo Request message MUST copy it into
        the Echo Reply (or Server Response message on error). 

The table in Section 3.4 confirms the "MUST" echo.

[Ballot comment]
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.

[Ballot discuss]
The timestamp specifies the time when the Echo
Request message is sent.  The first 4 bytes specify the number
of seconds since the Epoch (0000 UTC Jan 1, 1970).  The next 4
bytes specify the number of microseconds since the second
specified in the first 4 bytes.

It would seem to be in the best interests of the Internet if we were to minimize the number of timestamp epochs and formats that we used in our OAM protocols.  Unless there are good reasons to choose a different format, the NTP format shown in Figure 3 of RFC5905 and used in RFC 4379 (see Errata) would seem to be most appropriate.

There is a good case for writing a BCP on the subject of on the wire and in particular OAM timestamps so that there is a reference point for future occasions when the subject arrises.

[Ballot discuss]
The Gen-ART Review by Suresh Krishnan on 12-Jul 2011 raised two
  concerns that deserve a response.

  * I am not sure why this spec needs to contain the options 7 and 8
    as they are not relevant to this version of the protocol. Wouldn't
    the default behavior with unknown options take care of this
    automatically?

  * It would be good if the draft specifies a default TTL (e.g. 64) in
    case the server did not include a TTL option. In this case, the
    server implementations need not bother to add the option if they
    are happy with the default (which I suspect they would be).

[Ballot comment]
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.

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

#1) Random #s

The minute you mention random #s a reference to RFC 4086 pop in to my mind.  Please tweak the following:

Section 3.2:

Add a reference to [RFC4086] in the following sentence (Client ID):

    The value might be a randomised string that is likely
    to be unique, possibly combined with the client IP address.

Section 5:

Add a reference to [RFC4086] in the following sentence:

  A good Session ID would be a pseudo random
  byte string that is hard to predict.

Section 8:

Please add the following:

  [RFC4086] provides more information on generating
  pseudo-random numbers.

Section 11:

Add a normative reference to RFC 4086

A question:

Section 2 includes the following:

  At runtime, a client generates a client ID that is unique for the
  ping test.

But then there's no requirement in 3.2 about the ID being unique.  Shouldn't there be?

#2) Shouldn't there be something about DoS attacks in the security considerations?

#3) 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.

#4) 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.

#5) 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.

[Ballot comment]
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).

[Ballot discuss]
#1) Random #s

The minute you mention random #s a reference to RFC 4086 pop in to my mind.  Please tweak the following:

Section 3.2:

Add a reference to [RFC4086] in the following sentence (Client ID):

    The value might be a randomised string that is likely
    to be unique, possibly combined with the client IP address.

Section 5:

Add a reference to [RFC4086] in the following sentence:

  A good Session ID would be a pseudo random
  byte string that is hard to predict.

Section 8:

Please add the following:

  [RFC4086] provides more information on generating
  pseudo-random numbers.

Section 11:

Add a normative reference to RFC 4086

A question:

Section 2 includes the following:

  At runtime, a client generates a client ID that is unique for the
  ping test.

But then there's no requirement in 3.2 about the ID being unique.  Shouldn't there be?

#2) Shouldn't there be something about DoS attacks in the security considerations?

[Ballot comment]
#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.

[Ballot discuss]
#1) Random #s

The minute you mention random #s a reference to RFC 4086 pop in to my mind.  Please tweak the following:

Section 3.2:

Add a reference to [RFC4086] in the following sentence (Client ID):

    The value might be a randomised string that is likely
    to be unique, possibly combined with the client IP address.

Section 5:

Add a reference to [RFC4086] in the following sentence:

  A good Session ID would be a pseudo random
  byte string that is hard to predict.

Section 8:

Please add the following:

  [RFC4086] provides more information on generating
  pseudo-random numbers.

Section 11:

Add a normative reference to RFC 4086

A question:

Section Section 2 includes the following:

  At runtime, a client generates a client ID that is unique for the
  ping test.

But then there's no requirement in 3.2 about the ID being unique.  Shouldn't there be?

#2) Shouldn't there be something about DoS attacks in the security considerations?

[Ballot comment]
Section 1 should really be more to the point about what
this document's purpose is.  It specifies a way to send
packets to a unicast address which elicit responses to
both a unicast and a multicast addresses, yet never says
that so clearly until midway through section 2.

[Ballot discuss]
in section 2, there's discussion of rate limiting and
mention of a one request per second per IP address limit.
This is a bit of a heuristic, and should be described as
such.  It is not necessarily ideal for all networks and
configurations and may err on either the too conservative
or too aggressive sides depending on several variables.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Multicast Ping Protocol) to Proposed Standard


The IESG has received a request from the MBONE Deployment WG (mboned) to
consider the following document:
- 'Multicast Ping Protocol'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-07-04. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


The Multicast Ping Protocol specified in this document allows for
checking whether an endpoint can receive multicast, both Source-
Specific Multicast (SSM) and Any-Source Multicast (ASM).  It can also
be used to obtain additional multicast-related information such as
multicast tree setup time.  This protocol is based on an
implementation of tools called ssmping and asmping.



The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-mboned-ssmping/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-mboned-ssmping/


No IPR declarations have been submitted directly on this I-D.

Upon approval of this document, IANA understands that there are three
IANA Actions that must be completed.

First, a user registered port number will be assigned to "Multicast
Ping" with a short name of mcastping, and for UDP only.

Second, a new registry will be created for "Multicast Ping Message
Types." Message types are in the range 0-255. Message types 0-191
require specification (an RFC or other permanent and readily available
reference), while types 192-255 are for experimental use and are not
registered. The registry is managed through IETF Specification Required.
There are initial values to be added to the Multicast Ping Message Types
registry as follows:

Registry Name: Multicast Ping Protocol Message Types
Reference: [ RFC-to-be ]
Registration Procedures: Specification Required

Registry:
Type Name Reference
----------- ------------------------------------ -------------
65 Echo Reply [ RFC-to-be ]
73 Init [ RFC-to-be ]
81 Echo Request [ RFC-to-be ]
83 Server Response [ RFC-to-be ]
192-255 Experimental

Third, a new registry will be created for "Multicast Ping Option Types."
Option types 0-49151 require specification (an RFC or other permanent
and readily available reference), while types 49152-65535 are for
experimental use and are not registered. The registry is managed through
IETF Specification Required. There are initial values to be added to the
Multicast Ping Option Types registry as follows:

Registry Name: Multicast Ping Protocol Option Types
Reference: [ RFC-to-be ]
Registration Procedures: Specification Required

Registry:
Type Name Reference
----------- ------------------------------------ -------------
0 Version [ RFC-to-be ]
1 Client ID [ RFC-to-be ]
2 Sequence Number [ RFC-to-be ]
3 Client Timestamp [ RFC-to-be ]
4 Multicast Group [ RFC-to-be ]
5 Option Request Option [ RFC-to-be ]
6 Server Information [ RFC-to-be ]
7 Reserved [ RFC-to-be ]
8 Reserved [ RFC-to-be ]
9 TTL [ RFC-to-be ]
10 Multicast Prefix [ RFC-to-be ]
11 Session ID [ RFC-to-be ]
12 Server Timestamp [ RFC-to-be ]
49152-65535 Experimental

IANA understands that these three actions are the only ones required
upon approval of the document.