Re: [MBONED] Mail regarding draft-tissa-pim-mcastoam

["Tissa Senevirathne (tsenevir)" <[e-mail]>]

Hi Ron

Thanks for the email and comments. Please see specific comments in-line.
Also I would like to highlight the motivation of this proposal, to help
appreciate the background and the need.

Please consider a scenario like below. Where network X is run by
provider. He offers Hosting services. Assume for now there is a
multicast problem. As the operator of the network he/she does not have
access to the hosting machines. What is very helpful here would be to
have standard set of tools that can be executed from R (routers) that
will allow to exercise the data plane. 

               
                             Network - X
                   +------------------------------+
 Hosting Apps      |                              |     Hosting App
  Customer Monitor |     Operated and Maintained  |    Customer Monitor
      H-------     R           by                 R ----------H
                   |       Provider               |
                   |                              |
                   +------------------------------+

See below more specific answers embedded.

-----Original Message-----
From: Ronald Bonica [mailto:[e-mail]] 
Sent: Monday, March 19, 2012 3:02 PM
To: [e-mail]; [e-mail]
Subject: Mail regarding draft-tissa-pim-mcastoam

Tissa,

Currently, any station sourcing traffic to a multicast group can send an
ICMP Echo message to that group. The ICMP Echo message elicits a
response from each receiver subscribed to the group. This may not be
desirable because the number of receivers, and therefore, the number of
responses, may be very large.

[Answer] Absolutely agree with the statement.

draft-tissa-pim-mcastoam draft attempts to remedy that problem by
appending an RFC 4884 extension to the ICMP Echo. The extension
specifies which stations should respond and which should not.

This raises the following questions:

1) Backwards compatibility - Hosts running legacy software will not
parse the new extension. They will respond to the ICMP Echo regardless
of how it was scoped by the extension. So, the sender will not be
protected from a barrage of responses.


[Answer] Agreed, however draft is provided as a forward looking
approach. Based on the progress of the draft and comments on the
usefulness of the mcast-oam tools we are planning to contribute to Linux
open source both RFC4884 extensions and extensions proposed in this
document.

2) ICMP Behavior - In your draft, the ICMP Echo elicits a response from
all receivers and intermediate routers. Currently, routers do not
respond unless they are also receivers. Are you recommending that the
router should both process the PING message (as a receiver) and forward
it (as a router)?


[Answer] We are not expecting routers to respond to ping of receiver
detection. However, as indicated in section 3.3.1 of the draft, for
messages that need to discover routers performing different roles, we
generate the message with router alert bit set, hence letting each
router in the data plane to receive a copy of the discovery OAM
messages. 

3) Security considerations - Could multicast PINGs be used as a DoS
vector? In particular, what happens if the multicast source pings a
group that has many, many receivers. The PING specifies a spoofed source
address and is scoped to 0.0.0.0/0.

In all fairness, this condition exists today. 

[Answer] Like you indicated you can do the same as of today, however, we
strongly recommend platforms implementing this feature to rate limit
receipt of such multicast ICMP packet to the CPU or even in the data
plane itself.

4) ICMP Syntax -  The ICMP Echo / Response messages are not extensible.
See RFC 4884, Section 4 for details.

[Answer] Yes as of RFC4884 it is not extensible, we are planning to use
draft-shen-traceroute-ping-ext-04, which allow to extend ICMP Echo
request messages

 
--------------------------
Ron Bonica
vcard:       www.bonica.org/ron/ronbonica.vcf