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

[Ronald Bonica <[e-mail]>]

Hi Tissa,

Comments inline.....

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

Currently, we don't send ICMP echoes to multicast groups because we may receive more responses than we can handle. Now assume that your draft becomes an RFC and you contribute the code to LINUX. At some future date, multiple OS vendors will implement your feature. At some date after that, the user community will upgrade their systems and your feature will be widely deployed. At that time, it will be safe to send an ICMP Echo to a multicast group.

But when will that be? The only way to be certain is to give it a try! Since this is the case, you might want to add some text to your draft concerning what the consequences might be if you try it too soon.


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

Please see RFC 6398 (BCP 168). Specifically, take a look at Section 4.

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

Rate limiting inbound ICMP on the host that generates the ping won't help. That host isn't the victim.

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

That much better!

               Ron

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